Cuando usar CouchDB vs RDBMS

Question

Estoy buscando en CouchDB, que tiene una serie de atractivas características más de las bases de datos relacionales, incluyendo:

• intuitiva REST/HTTP interfaz
• fácil replicación
• datos almacenados como documentos , en lugar de tablas normalizadas

Agradezco que este no sea un producto maduro, por lo que debe adoptarse con precaución, pero me pregunto si realmente es un reemplazo viable para una R DBMS (a pesar de que la página de introducción dice lo contrario - http://couchdb.apache.org/docs/intro.html).

1. ¿En qué circunstancias sería CouchDB una mejor opción de base de datos que un RDBMS (por ejemplo, MySQL), p. en términos de escalabilidad, diseño + tiempo de desarrollo, confiabilidad y mantenimiento.
2. ¿Todavía hay casos en los que un RDBMS sigue siendo claramente la opción correcta?
3. ¿Es esta una opción de uno u otro, o es una solución híbrida con más probabilidades de surgir como una mejor práctica?

Answer 1

Hasta que alguien da una respuesta más detallada, aquí están algunas ventajas y desventajas para CouchDB

Pros:

• que no es necesario para adaptarse a sus datos en uno de esos molestos formas normales de orden superior
• puede cambiar el "esquema" de sus datos en cualquier momento
• sus datos serán indexados exactamente para sus consultas, por lo que obtendrá resultados en tiempo constante.

Contras:

• es necesario crear vistas para cada consulta, es decir, ad-hoc como consultas (como la concatenación dinámica donde y de los años en un SQL ORDENAR) consultas no están disponibles.
• hay que colocar los datos redundantes, o el resultado final será la implementación de unirse y ordenar la lógica sí mismo en "el lado del cliente" (por ejemplo, clasificación una relación de muchos a muchos en múltiples campos)

Profesionales o Contras :

• creando sus vistas no son tan sencillas como en SQL, es más como resolver un acertijo. Depende de su tipo si esto es un pro o un engaño :)

Answer 2

Si está trabajando con datos tabulares donde solo hay una jerarquía de datos poco profunda, entonces un sistema RDBMS es probablemente su mejor opción. Este es el uso principal de los sistemas RDBMS, y la documentación y el soporte de herramientas es muy bueno.

Para obtener más datos anidados como xml, una base de datos de documentos debe proporcionar un acceso más rápido a sus datos. Además, el modelo de almacenamiento se asemeja más al de los datos, por lo que la recuperación debería ser más directa.

Answer 3

CouchDB es uno de varios 'clave/valor tiendas' disponibles, otros incluyen oldies como BDB, los orientados a la Web como Persevere, MongoDB y CouchDB, nuevo súper rápido como memcached (RAM-solamente) y Tokyo Cabinet, y enorme tiendas como Hadoop y BigTable de Google (MongoDB también dice estar en este espacio).

Sin duda hay espacio para almacenes de clave/valor y DB relacionales. Tradicionalmente, la mayoría de los RDB se consideran una capa por encima de la clave/valor. Por ejemplo, MySQL solía usar BDB como un back-end opcional para tablas. En resumen, las claves/valores no saben nada sobre los campos y las relaciones, que son los cimientos de SQL.

Las tiendas clave/de valor suelen ser más fáciles de escalar, lo que las convierte en una opción atractiva cuando crecen explosivamente, como lo hizo Twitter. Por supuesto, eso significa que cualquier relación entre los valores almacenados debe ser administrada en su código, en lugar de simplemente declararse en SQL. El enfoque de CouchDB es almacenar grandes 'documentos' en la parte de valor, haciéndolos (en su mayoría) autónomos, para que pueda obtener la mayoría de los datos necesarios en una sola consulta. Muchos casos de uso se ajustan a esta idea, otros no.

El tema actual que veo es que después de "¡Rails no escala!" susto, ahora muchas personas se están dando cuenta de que no se trata de su marco web; pero sobre caché inteligente, para evitar golpear la base de datos, e incluso la aplicación web cuando sea posible. La estrella en ascenso está memcached.

Como siempre, todo depende de sus necesidades.

Answer 4

Esta es una pregunta difícil de responder. Así que trataré de resaltar las áreas en las que CouchDB podría funcionar en su contra.

Los dos mayores fuentes de dificultad en los usuarios sofá y listas de correo Dev que tienen las personas son:

• complejo se une de datos.
• Mapa de varios pasos/Reducir.

Las vistas de los sofás son prácticamente islas en sí mismas. Si necesita agregar/fusionar/intersecar un conjunto de vistas, tiene que hacerlo en la capa de aplicación por ahora. Hay algunos trucos que puedes hacer con colación de vistas y claves complejas para ayudar con las uniones, pero estos solo van muy lejos para algunos tipos de datos. Esto puede o no ser habitable para diferentes aplicaciones. Dicho esto, muchas veces este problema puede reducirse o eliminarse estructurando sus datos de manera diferente.

Los comentarios de otras personas sobre esta pregunta demuestran algunos de los diferentes tipos de datos que se adaptan bien a CouchDB.

Otra cosa a tener en cuenta es que muchas veces los datos que podría necesitar combinar/fusionar/intersectar serían datos que realizaría sin conexión en una base de datos RDBMS de todos modos para que no pierda nada haciendo el lo mismo en CouchDB.

Respuesta corta: creo que eventualmente CouchDB será capaz de manejar cualquier tipo de problema que quiera lanzar en él. Pero el nivel de comodidad que tiene al usarlo puede diferir de desarrollador a desarrollador. Es algo subjetivo, creo. Me gusta usar un lenguaje completo para consultar mis datos y mantener más lógica en la capa de aplicación. Su experiencia puede ser diferente.

Answer 5

Corrígeme si me equivoco. Couchdb es inútil para los casos en que necesita validar la exclusividad de los documentos en múltiples campos.Por ejemplo, es imposible aplicar una regla de validación como "se requiere que el inicio de sesión y el correo electrónico sean únicos" y mantener los datos en estado de consistencia. Puede verificarlo antes de guardar el documento, pero alguien puede presionar antes que usted y los datos se vuelven inconsistentes.

Answer 6

Sam usted tiene que tomar otra approch con CouchDB y en general con el mapa o documento base de datos basada. No puede definir una restricción, como única, pero puede consultar datos para verificar si ese correo electrónico se usa y si también se usa ese inicio de sesión. Ese es el enfoque correcto, tienes que cambiar de opinión.

Answer 7

poco asistí a la conferencia NoSQL en Londres y creo que tengo una idea mejor ahora cómo responder a la pregunta original. También escribí un blog post, y hay un par de otros goodones.

puntos clave:

• hemos acumulado probablemente 30 años conocimiento de adminstering bases de datos relacionales, por lo que no deben sustituir a ellos sin una cuidadosa consideración; los almacenes de datos no relacionales son menos maduros que los relacionales, y por eso son intrínsecamente más riesgosos para adoptar
• Existen diferentes tipos de almacenamiento de datos no relacionales; algunas son tiendas clave-valor, algunas son tiendas de documentos, algunas son bases de datos de gráficos
• Puede utilizar un enfoque híbrido, p. una combinación de datos del gráfico RDBMS y almacenar para un sitio de software social
• almacenes de datos de documentos (por ejemplo, CouchDB y MongoDB) son probablemente el más cercano a las bases de datos relacionales y proporcionan una estructura de datos JSON con todos los campos presentados jerárquicamente lo que evita tener que ver tabla se une, y (algunos podrían argumentar) es una mejora en el mapeo tradicional relacional de objetos que la mayoría de las aplicaciones usan actualmente
• Las bases de datos no relacionales admiten la replicación (incluido el maestro maestro); las bases de datos relacionales también admiten la replicación, pero puede no ser tan completa como la opción no relacional
• Los sitios muy grandes como Twitter, Digg y Facebook usan Cassandra, que se construye desde cero para admitir clustering
• Las bases de datos relacionales probablemente adecuado para el 90% de los casos

En resumen, el consenso parece ser "proceder con precaución".