Looking for a distributed / scalable database solution where all nodes are read / written? Not MongoDB?

Question

I am looking for a database implementation that can be geographically widespread and such that each node can be read / written with possible consistency with all other nodes. Where should I look?

I thought MongoDB seemed like a good option for other reasons, until I came up with this problem. Apparently all MongoDB nodes are readable, but only the wizard is writable? Is there any way around this? I cannot resolve a single point failure to write to the database.

Answer 1

I just finished reviewing a few of these databases. I ended up with Mongo for various reasons. Riak and Kassandra are both incarnations of the Amazon Dynamo, and each of them can handle this. On the Riak website , they have good comparisons of Riak and several other databases. For your specific question, I think that both Riak and Cassandra process entries on any node with a vector clock for fixing Riak and a timestamp for Cassandra for handling conflicts.

Other than that, you have several other options that may make sense:

• HBase can do very large, can perform simultaneous recording on different nodes. This design is good for many attributes on every document / record.
• CouchDB has good support for multiple-letter conflicts, but with a simpler document space.
• I read a good argument for no MySQL schema here , with a nod to the green Drizzle

I am not sure the full answer. My search took several weeks and about 50 pages of notes, but if large, distributed and safe records are great criteria that should promote you.

Answer 2

If your problem is with one point of failure: MongoDB uses replicas to distribute readings and fragments to distribute records. To achieve what you are looking for, you can outline your system, each fragment will be a set of replicas. If your main shard dies, a new primary element is automatically selected and, therefore, is not the only point of failure. Note. MongoDB does not support multi-master replication.

Answer 3

I'm a couchdb fan

Sorry, I was cut off before I could expand this.

1) At first, the sofa is easily geographically distributed - you talk to him via http, which is great for distributed projects.

2) Couch has built-in replication.

Even better, you may find that bigcouch is even more suitable, as it is specifically designed for clustering.

I spent several weeks evaluating Mongo / Cassandra / Couch et al. And decided that in balance for a wide range of applications, Couch is well suited.

I suppose you should also look at Amazon Simple DB . When it comes to ultimately distributed sequential databases, it certainly fits the bill. I use it in several projects for a couple of years, and he does what he says in tin. My only concern is that you basically put all your data in a third-party black box ... but it certainly works, scales and ticks all your fields.

Hope this makes life a little easier.

Answer 4

Depends on how you want to distribute your posts.

Sharding: If you want to distribute entries on a key, MongoDB has an excellent auto-scaling feature. For redundancy, you will create several pairs of replicas (master-slave), and then assign each of them a range of keys through the central service (mongos). Reads will be distributed statically over a range of keys.

Multimaster:

• If your system is small enough (GB, not TB), CouchDB has one of the most sophisticated merge replication schemes and is built for fast and reliable recovery in the event of a node failure. With CouchDB, each node has a full copy of the data, and all nodes in the cluster can be both readable and readable.

• If you occupy millions of lines per hour, Cassandra uses a peer-to-peer network-based replication scheme that allows you to make large-scale writes far beyond CouchDB if you want to give a little idea of ​​read performance.

• HBase also scales recordings and reads, but is better suited for a packet-oriented recording function (download log files), since it sits on HDFS and the recordings should be close to the minimum block size (64 MB, 128MB ...) before recording can be written to disk.

Hope this helps.

Answer 5

You can use a product like CloudTran to handle very fast distributed transactions in shared databases such as MySQL, Oracle, SQL Server, etc.

Answer 6

This is one of the design goals of NuoDB, and the product does it today.

You can read (QUERY), write (INSERT, UPDATE, DELETE) or do something else transactionally through several data centers, as if the database was in one place. NuoDB is really consistent, but not ultimately consistent. It guarantees ACID transactions using optimistic asynchronous messages and distributed version control. And NuoDB has rich support for standard SQL.