51–56 of 56 posts
HyperDex Warp does lightweight multi-key transactions: http://hyperdex.org/warp/
Misleading title: Abadi specifically called out particular NoSQL DB's, he wasn't generalizing to all NoSQL DB's. MarkLogic ( http://www.marklogic.com ) is an Enterprise Database used by many large organizations as a system of record for information traditionally stored in RDBMS or Mainframe. Joe Hellerstein gave a wonderful keynote at ACM SoCC last year that is a great read for all who are interested in this subject:…
Misleading title: Abadi specifically called out particular NoSQL DB's, he wasn't generalizing to all NoSQL DB's. MarkLogic ( http://www.marklogic.com ) is an Enterprise Database used by many large organizations as a system of record for information traditionally stored in RDBMS or Mainframe. Joe Hellerstein gave a wonderful keynote at ACM SoCC last year that is a great read for all who are interested in this subject:…
Do you have info or can you point to anything where I can learn about MarkLogic without all the marketing speak on the site? It's really hard to get any info about how the software actually looks like and works and compares to other options out there...
The closest we have to a "comparison" is http://www.marklogic.com/what-is-marklogic/features/ those pages do actually end drilling down to documentation.
Simply choose the most suitable solution, not the most hyped one. A mistake would be to sacrifise transactions via using some "general NoSQL database". Today, for real, you can have a single node capable of millions RPS on real-world scenarios with ACID transactions of arbitrary complexity, choosing solution like http://starcounter.io/. Please, please don't just take yet another no-transactions DB, which is no-transactions even on a single machine, having 4 db nodes on 4 cores completely separate as if they've been 4 different machine. Then you observe bad performance and start to scale things up, paying more and more for the cloud. Not the best idea to spend time and money.
And, if you DO really need distributed transactions, then it mostly means they'd be driven by a logic of your subject domain. E.g., you might have one department in Sweden, one in the USA, then you need to manage distributed accounts in the right way, where "right" is up to your banking policy. However, if you need to scale reads, there is just no problem of doing so within "no-distributed-ACID" solution. The same time, if you need to scale writes, doing distributed transactions isn't a good idea either, as you've seen from the topic starter article.
So, right tool for the right job.
Outside of the brackets I keep a topic of fighting with latency via distributed transactions. I mean those things around caching, CDN and async replication. Distributed transaction isn't a remedy there at all, since it doesn't patch speed of light by any means.
On the .NET stack, RavenDB[0] supports transactions on multiple items[1]. RavenDB is a nice middle ground: eventual consistency for queries for speed, but ACID for create, update, and load (one or more items by ID). It uses transactions throughout, so a failure in the midst of 10 writes will rollback all of them, as one would expect in a traditional relational database. [0]: http://ravendb.net/ [1]: http://ravendb.ne…
How can one possibly be eventually consistent for reads and ACID for updates? Unless you are saying the datasets available for fast queries cannot be updated consistently...Or are you just saying, you can read from replicas but maintain a single master...
Complex queries are eventually consistent.
Hope this helps. I'm @judahgabriel if you have more questions.
On the .NET stack, RavenDB[0] supports transactions on multiple items[1]. RavenDB is a nice middle ground: eventual consistency for queries for speed, but ACID for create, update, and load (one or more items by ID). It uses transactions throughout, so a failure in the midst of 10 writes will rollback all of them, as one would expect in a traditional relational database. [0]: http://ravendb.net/ [1]: http://ravendb.ne…
It does indeed look nice, however the pricing looks worse than MS SQL in the long run (for the enterprise version).
For commercial enterprise, Raven is effectively $788/core/year [0]. Quite reasonable, IMO.
Contrast this with MS SQL Server Enterprise, which appears to be $14,000/core one-time cost [1].
(Disclaimer: I'm a part-time employee for RavenDB. But I loved and used Raven on my own projects before becoming an employee.)
[0]: http://ravendb.net/buy [1]: http://www.microsoft.com/en-us/server-cloud/products/sql-ser...