¿Busca una solución de base de datos distribuida/escalable donde todos los nodos sean de lectura/escritura? ¿No es MongoDB?

Question

Estoy buscando implementar una base de datos que pueda ser ampliamente distribuida geográficamente y de tal manera que cada nodo pueda leerse/escribirse con consistencia eventual a todos los otros nodos. ¿Dónde debería estar mirando?

Pensé que MongoDB parecía una buena opción por otros motivos hasta que llegué a esta preocupación. Aparentemente, todos los nodos MongoDB son legibles, pero solo se puede escribir un maestro. ¿Hay alguna forma de evitar esto? No puedo permitir que un solo punto falle al escribir en la base de datos.

Answer 1

Acabo de terminar mi revisión de varias bases de datos similares. Terminé con Mongo por diferentes razones. Riak y Cassandra son ambas implementaciones del Dynamo de Amazon, que cada una de ellas podría hacer un buen trabajo. En el Riak site, tienen buenas comparaciones de Riak y algunas otras bases de datos. Para su pregunta específica, creo que tanto Riak como Cassandra manejan las escrituras en cualquier nodo con un reloj vectorial para las confirmaciones de Riak, y una marca de tiempo para que Cassandra maneje los conflictos.

Aparte de eso, usted tiene algunas otras opciones que pueden tener sentido:

• HBase puede hacer muy grande, puede hacer escrituras simultáneas en varios nodos. Su diseño es bueno para muchos atributos en cada documento/registro.
• CouchDB tiene buena compatibilidad con conflictos de escritura múltiple pero con un espacio de documentos más simple.
• leí un buen argumento para sin esquema MySQL here, con un guiño a la aún verde Drizzle

No estoy seguro de que es una respuesta completa. Mi búsqueda tomó varias semanas y aproximadamente 50 páginas de notas, pero si las escrituras grandes, distribuidas y seguras son los criterios más importantes, eso debería motivarlo.

Answer 2

Si su preocupación es acerca de un único punto de falla: MongoDB usa los conjuntos de duplicación para distribuir las lecturas y la fragmentación para distribuir escrituras. Para lograr lo que está buscando, puede fragmentar su sistema con cada fragmento como conjunto de réplicas. Si su primario en un fragmento muere, se elige automáticamente un nuevo primario y, por lo tanto, no existe un único punto de falla. Nota: MongoDB no soporta la replicación multi-master

Answer 3

Soy un fan de couchdb

Lo siento, se cortó antes de que pudiera ampliar esto.

1) En primer lugar sofá se distribuye fácilmente geográficamente - hablas con él a través de http, que es ideal para proyectos distribuidos.

2) Couch ha construido en la replicación.

Mejor aún, es posible que bigcouch es aún más conveniente ya que está diseñado específicamente con el clúster en cuenta.

Pasé varias semanas evaluando a Mongo/Cassandra/Couch y otros y decidí que, en general, para una amplia gama de aplicaciones, Couch es muy adecuado.

Supongo que también deberías consultar Amazon Simple DB. Cuando se trata de bases de datos distribuidas finalmente consistentes, sin duda cabe la factura. Lo he usado en una serie de proyectos durante un par de años y hace lo que dice en la lata.Mi única preocupación es que básicamente estás poniendo todos tus datos en la caja negra de un tercero ... pero ciertamente funciona, escala y cumple todos tus requisitos.

Espero que eso ayude a aclarar las cosas un poco.

Answer 4

Depende de cómo quiera distribuir sus escrituras.

Sharding: Si está buscando distribuir escrituras en una tecla, MongoDB tiene una excelente característica de auto-sharding. Para la redundancia, crearía múltiples pares de réplica (maestro-esclavo) y luego asignaría a cada uno de ellos un rango clave a través de un servicio central (mongos). Las lecturas se distribuirán estáticamente por rango clave.

Multi-Master:

1. Si eres sistema es lo suficientemente pequeño (GB, no TB), CouchDB tiene uno de los esquemas de combinación de replicación-más sofisticados y está construido para una rápida y fiable en recuperarse el evento de falla del nodo. Con CouchDB, cada nodo tiene una copia completa de los datos, y todos los nodos en un clúster pueden escribirse y leerse.

2. Si extrae millones de filas por hora, Cassandra utiliza un esquema de replicación basado en pares que le permitirá escalar las escrituras mucho más allá de CouchDB si está dispuesto a dar un poco en el rendimiento de lectura.

3. HBase también escala las escrituras y lecturas, pero se adapta mejor a una función de escritura por lotes (carga de archivos de registro), ya que se encuentra en HDFS y las escrituras deben estar cerca del tamaño de bloque mínimo (64 MB, 128 MB ...) antes de que una escritura se pueda enviar al disco.

Espero que esto ayude.

Answer 5

Se puede utilizar un producto como CloudTran para manejar transacciones distribuidas muy rápido a través de bases de datos comunes como MySQL, Oracle, SQL Server, etc.

Answer 6

Este es uno de los objetivos de diseño de NuoDB, y el producto hace esto hoy .

Usted puede leer (query), escribir (INSERT, UPDATE, DELETE), o hacer cualquier otra cosa transaccional a través de múltiples centros de datos, como si la base de datos está en un solo lugar. NuoDB es realmente consistente, no siempre consistente. Garantiza las transacciones ACID utilizando mensajería asincrónica optimista y versiones distribuidas. Y NuoDB tiene un gran soporte para SQL estándar.