As someone who has done databases for a long time, I have very little respect for NoSQL, but that is mostly because everyone keeps trumpeting it as a killer of traditional databases. There are scenarios where NoSQL systems are an ideal fit. However, NONE of those scenarios require data to be very reliably stored in a guaranteed and predictable way.
If you don't get your tweets or your friends facebook posts as soon as they are posted, no one will really care. But for something as truly important as health insurance coverage? Are you f__king kidding me? And that's just from a reliability standpoint. Nevermind the fact that NoSQL is currently at the wild west stage where nobody is compatible with anybody else, there is nothing resembling a standard set of APIs between products, making it very difficult to develop expertise.
I certainly get where you're coming from with this, but a couple of points to address your concerns:
MarkLogic has been around since 2001, with features needed for enterprise deployments (ACID, HA/DR, security) baked in from the start; it's not just the new hawtness.
NoSQL systems aren't just for lots of data, they are for data with lots of variety. In those cases, a schemaless approach allows for much more rapid application development. And yes, many of those scenarios do require reliable storage. MarkLogic does ACID transactions. The MarkLogic customer page shows some of the customers who have found this helpful.
Regarding interoperability, MarkLogic has a REST API and a Java API, in addition to the ability to work with XQuery. Custom HTTP service endpoints can be built to fit into an existing environment. It still requires some learning -- a document store is different from relational, so that's unavoidable -- but with a little training developers can use a lot of their current skills.
It's actually really fast. The XML is indexed on ingest and many queries are answered just from the indexes.
Why would anyone design such a product? Why would anyone buy such a product?
Because for many kinds of data, once I became familiar with MarkLogic I found I could build complex applications more rapidly than I could with relational technologies. It scales out, it's schema agnostic, and it's ACID compliant. It has HA/DR features and a robust security model. Customers buy it because it solves their problems.
For anyone interested in learning a bit about MarkLogic, the Enterprise NoSQL page is a good place to start.
Disclaimer: MarkLogic employee.
Slashdot Mirror
As someone who has done databases for a long time, I have very little respect for NoSQL, but that is mostly because everyone keeps trumpeting it as a killer of traditional databases. There are scenarios where NoSQL systems are an ideal fit. However, NONE of those scenarios require data to be very reliably stored in a guaranteed and predictable way.
If you don't get your tweets or your friends facebook posts as soon as they are posted, no one will really care. But for something as truly important as health insurance coverage? Are you f__king kidding me? And that's just from a reliability standpoint. Nevermind the fact that NoSQL is currently at the wild west stage where nobody is compatible with anybody else, there is nothing resembling a standard set of APIs between products, making it very difficult to develop expertise.
I certainly get where you're coming from with this, but a couple of points to address your concerns:
MarkLogic has been around since 2001, with features needed for enterprise deployments (ACID, HA/DR, security) baked in from the start; it's not just the new hawtness.
NoSQL systems aren't just for lots of data, they are for data with lots of variety. In those cases, a schemaless approach allows for much more rapid application development. And yes, many of those scenarios do require reliable storage. MarkLogic does ACID transactions. The MarkLogic customer page shows some of the customers who have found this helpful.
Regarding interoperability, MarkLogic has a REST API and a Java API, in addition to the ability to work with XQuery. Custom HTTP service endpoints can be built to fit into an existing environment. It still requires some learning -- a document store is different from relational, so that's unavoidable -- but with a little training developers can use a lot of their current skills.
MarkLogic has scheduled backups. You can also do a backup through the Admin UI, which is mentioned pretty early in the Administrator's Guide.
Why would anyone design such a product? Why would anyone buy such a product?
Because for many kinds of data, once I became familiar with MarkLogic I found I could build complex applications more rapidly than I could with relational technologies. It scales out, it's schema agnostic, and it's ACID compliant. It has HA/DR features and a robust security model. Customers buy it because it solves their problems. For anyone interested in learning a bit about MarkLogic, the Enterprise NoSQL page is a good place to start. Disclaimer: MarkLogic employee.
MarkLogic is ACID compliant. http://www.marklogic.com/blog/can-you-pass-the-acid-test/