voldemort vs. couchdb

Question

Estoy tratando de decidir si usaré voldemort o couchdb para un próximo proyecto de atención médica. Quiero un sistema de almacenamiento que tenga alta disponibilidad, tolerancia a fallas y que pueda escalar para las enormes cantidades de datos que se arrojen sobre él.

¿Cuáles son los pros/contras de cada uno?

Gracias

Answer 1

Es memcacheDB una opción? Escuché que Digg manejó los problemas de HA.

Answer 2

Project Voldemort se ve bien, pero hasta ahora no lo he investigado a fondo.

En su estado actual CouchDB podría no ser lo correcto para "grandes cantidades de datos". La distribución de datos entre nodos y consultas de enrutamiento en consecuencia está en la hoja de ruta, pero no se ha implementado hasta el momento. Las configuraciones de producción más grandes conocidas de CouchDB usan "tablas" ("bases de datos" en couch-speak) de aproximadamente 200G.

HA no es compatible de forma nativa con CouchDB pero puede compilarse fácilmente: todos los nodos CouchDB están replicando los nodos de la base de datos entre sí en una configuración de múltiples maestros. Ponemos dos Varnish proxies delante de las máquinas CouchDB y las cajas de barniz se vuelven redundantes con CARP. El diseño de CouchDBs "build from the Web" hace que estas cosas sean muy fáciles.

El problema más acuciante en our setup es el hecho de que todavía hay problemas con la replicación de archivos adjuntos grandes (MB múltiples) a los documentos de CouchDB.

Le sugiero que también compruebe la ruta RDBMS tradicional. There are huge issues con talento disponible fuera del enfoque de RDBMS y hay ofertas disponibles muy capaces de Oracle & Co.

Answer 3

no saber lo suficiente de su pregunta, me gustaría decir, sin embargo, Proyecto Voldemort o tablas hash distribuidas (DHTS) como CouchDB en general son una solución a su problema de HA.

Esas DHT son muy buenas para la alta disponibilidad pero más difíciles de escribir que para las bases de datos relacionales tradicionales (RDBMS) con respecto a la coherencia.

Son bastante buenos para almacenar información del tipo de documento, que puede encajar muy bien con su proyecto de atención médica pero dificulta el desarrollo de los datos.

• La mayor limitación de la mayoría de las tiendas es que no son transaccionalmente segura (Ver Scalaris para una tienda transaccionalmente seguro) y es necesario para garantizar la coherencia de datos por sí mismo - la mayoría del uso leer consistencia temporal mediante la fusión de conflicto datos). Los RDBMS son mucho más fáciles de usar para la consistencia de los datos (ACID)
• Unir datos es mucho más difícil también. En RDBM puede consultar fácilmente datos en varias tablas, necesita escribir código en CouchDB para agregar datos. Para otras tiendas Hadoop puede ser una buena opción para agregar información.

leer sobre BASE y la PAC teorema sobre la consistencia frente a la disponibilidad.

Ver

• http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
• http://queue.acm.org/detail.cfm?id=1394128