database - data - curl couchdb

Cuándo utilizar CouchDB vs RDBMS (7)

Estoy mirando CouchDB, que tiene una serie de características atractivas sobre las bases de datos relacionales, que incluyen:

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

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

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

Corrígeme si estoy equivocado. 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.

CouchDB es una de las varias ''tiendas de claves / valores'' disponibles, otras incluyen antiguas como BDB , webs como Persevere , MongoDB y CouchDB, nuevas superrápidas como memcached (sólo RAM) y Tokyo Cabinet , y grandes tiendas como Hadoop y BigTable de Google (MongoDB también dice estar en este espacio).

Ciertamente hay espacio para los almacenes clave / valor y los 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 tus necesidades.

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.

Las dos fuentes más importantes de dificultad en las listas de correo de Usuarios de Couch y Dev que tienen las personas son:

Uniones complejas de datos.
Mapa de varios pasos / Reducir.

Los Couch Views son casi islas para ellos mismos. 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 los otros en 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, por lo que no podría perder nada haciendo lo mismo en CouchDB.

Respuesta corta: creo que eventualmente CouchDB será capaz de manejar cualquier tipo de problema que desee lanzar. 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.

Hasta que alguien dé una respuesta más profunda, aquí hay algunos pros y contras para CouchDB

Pros:

no es necesario que ajuste sus datos en una de esas molestas 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:

necesita crear vistas para todas y cada una de las consultas, es decir, las consultas tipo ad-hoc (como concatenar WHERE dinámico y SORT en SQL) no están disponibles.
usted tendrá datos redundantes, o terminará implementando la lógica de unión y clasificación usted mismo en el "lado del cliente" (por ejemplo, ordenando una relación de muchos a muchos en múltiples campos)

Pros o contras:

crear sus vistas no es tan sencillo como en SQL, es más como resolver un rompecabezas. Depende de tu tipo si esto es un pro o un engaño :)

Recientemente asistí a la conferencia NoSQL en Londres y creo que ahora tengo una mejor idea de cómo responder la pregunta original. También escribí una publicación de blog , y hay algunas otras buenas .

Puntos clave:

Hemos acumulado probablemente 30 años de conocimiento sobre la administración de bases de datos relacionales, por lo que no deberíamos reemplazarlos sin una consideración cuidadosa; los almacenes de datos no relacionales son menos maduros que los relacionales, por lo que son intrínsecamente más riesgosos de 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
Podría utilizar un enfoque híbrido, por ejemplo, una combinación de RDBMS y una tienda de datos gráficos para un sitio de software social.
Los almacenes de datos de documentos (por ejemplo, CouchDB y MongoDB) son probablemente los más cercanos 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 hacer uniones de tablas y (algunos podrían argumentar) es una mejora en el objeto tradicional. mapeo relacional que la mayoría de las aplicaciones utilizan 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 apoyar el agrupamiento
Las bases de datos relacionales son probablemente adecuadas para el 90% de los casos

En resumen, el consenso parece ser "proceder con cautela".

Sam tienes que tomar otra aproximación con CouchDB y en general con una base de datos basada en mapas o documentos. 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.

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.