¿Por qué debería usar una base de datos basada en documentos en lugar de una base de datos relacional?

188

¿Por qué debería usar una base de datos basada en documentos como CouchDB en lugar de usar una base de datos relacional? ¿Hay algún tipo típico de aplicaciones o dominios donde la base de datos basada en documentos es más adecuada que la base de datos relacional?

Bartosz Blimke
fuente
Quizás una base de datos orientada a documentos podría ser similar en algunos aspectos a una base de datos "entidad-atributo-valor" (EAV).
ChrisW

Respuestas:

167

Probablemente no deberías :-)

La segunda respuesta más obvia es que debe usarla si sus datos no son relacionales. Esto generalmente se manifiesta al no tener una manera fácil de describir sus datos como un conjunto de columnas. Un buen ejemplo es una base de datos donde realmente almacena documentos en papel, por ejemplo, escaneando el correo de la oficina. Los datos son el PDF escaneado y tiene algunos metadatos que siempre existen (escaneado, escaneado por, tipo de documento) y muchos campos de metadatos posibles que existen en algún momento (número de cliente, número de proveedor, número de pedido, mantener en el archivo hasta, Texto completo OCR, etc.). Por lo general, no sabe de antemano qué campos de metadatos agregará en los próximos dos años. Cosas como CouchDB funcionan mucho mejor para ese tipo de datos que las bases de datos relacionales.

También me encanta el hecho de que no necesito ninguna biblioteca cliente para CouchDB, excepto un cliente HTTP, que actualmente se incluye en casi todos los lenguajes de programación.

La respuesta probablemente menos obvia: si no siente dolor al usar un RDBMS, quédese con él. Si siempre tiene que trabajar alrededor de su RDBMS para hacer su trabajo, una base de datos orientada a documentos podría valer la pena.

Para obtener una lista más elaborada, consulte esta publicación de Richard Jones .

max
fuente
1
Nunca he visto ningún esquema de base de datos en dos años parecido al esquema original con el que comenzamos ... así que todo igual (que no es ...), siempre debe usar una base de datos sin esquema = una orientada a documentos; que creo que es un nombre bastante engañosa ...
ᆼ ᆺ ᆼ
3
@ int3 Si no puede describir sus datos como un conjunto de columnas, ¿cómo se supone que debe escribir consultas inteligentes sobre dichos datos?
Clay Smith
46

CouchDB (de su sitio web )

  • Un servidor de bases de datos de documentos, accesible a través de una API RESTful JSON. En general, las bases de datos relacionales no se acceden simplemente a través de los servicios REST, sino que requieren una API SQL mucho más compleja. A menudo, estas API (JDBC, ODBC, etc.) son bastante complejas. REST es bastante simple.

  • Ad-hoc y sin esquema con un espacio de direcciones plano. Las bases de datos relacionales tienen un esquema complejo y fijo. Define tablas, columnas, índices, secuencias, vistas y otras cosas. Couch no requiere este nivel de planificación avanzada compleja, costosa y frágil.

  • Distribuido, con replicación incremental robusta con detección y gestión de conflictos bidireccionales. Algunos productos comerciales de SQL ofrecen esto. Debido a la API SQL y los esquemas fijos, esto es complejo, difícil y costoso. Para Couch, parece simple y económico.

  • Consultable e indexable, con un motor de informes orientado a tablas que utiliza Javascript como lenguaje de consulta. También lo hace SQL y las bases de datos relacionales. Nada nuevo aquí.

Entonces. ¿Por qué CouchDB?

  • REST es más simple que JDBC u ODBC.
  • Ningún esquema es más simple que el esquema.
  • Distribuido de una manera que parece simple y económica.
S.Lott
fuente
12
Si bien soy un gran admirador de las bases de datos NoSQL, la primera afirmación (REST es más simple que JDBC) es muy dudosa.
ᆼ ᆺ ᆼ
2
El protocolo REST me parece bastante simple, ya que es solo HTTP: sin estado, pocos métodos, etc., etc. Quizás JDBC es (bajo el capó) simple; no parece ser más simple, basado simplemente en ser con estado.
S.Lott
55
@ S.Lott ¿No debería ser la respuesta más "genérica" ​​en lugar de orientada únicamente a CouchDb?
Pacerier
¿"planificación avanzada frágil" frente a qué? En mi experiencia, la alternativa es la no planificación, lo que conduce a estructuras de datos de espagueti que se modifican por capricho.
Tejay Cardon
26

Para almacenar y servir estúpidamente datos de otros servidores.

En las últimas semanas he estado jugando con una aplicación Lifestream que sondea mis feeds (delicious, flickr, github, twitter ...) y los almacena en couchdb. La belleza de couchdb es que me permite mantener los datos originales en su estructura original sin sobrecarga. Agregué un campo de 'clase' a cada documento, almacenando el servidor de origen, y escribí una clase de representación de JavaScript para cada origen.

En general, cada vez que su servidor se comunica con otro servidor, un almacenamiento sin esquema es mejor ya que no tiene control sobre el esquema. Como beneficio adicional, couchdb utiliza los protocolos nativos de servidores y clientes: JSON para la representación y HTTP REST para el transporte.

daonb
fuente
¿Por qué no simplemente almacenarlos en un archivo o un archivo por feed?
j_random_hacker
66
porque couchdb también te permite crear vistas interesantes usando map / reduce. Por ejemplo, puedo crear una vista basada en la fuente de datos, o puedo calcular los totales para cada fuente.
daonb
44
Ese es un punto brillante ... si está consumiendo datos y no tiene control sobre el esquema de datos entrantes, use un almacén de documentos.
Joshua Robinson
1
Este es el primer argumento realmente convincente que escuché sobre el valor de las bases de datos NoSQL
Caleb McNevin el
20

El desarrollo rápido de aplicaciones viene a la mente.

Cuando evoluciono constantemente mi esquema, me siento constantemente frustrado por tener que mantener el esquema en MySQL / SQLite. Si bien aún no he hecho demasiado con CouchDB, me gusta lo simple que es desarrollar el esquema durante el proceso RAD.

Un caso en el que es posible que no desee utilizar una base de datos no relacional es cuando tiene muchas relaciones de muchos a muchos; Todavía tengo que entender cómo crear buenas funciones de MapReduce en torno a este tipo de relaciones, especialmente si necesita tener metadatos en la relación de unión. No estoy seguro, pero no creo que las funciones de CouchDB Map puedan llamar a sus propias consultas en la base de datos, ya que eso podría causar infinitos bucles.

pixelcort
fuente
1
Excelente punto Los almacenes de datos de documentos (y otros esquemas sin esquema) son excelentes para el desarrollo rápido de las primeras etapas. Sin embargo, por las mismas razones, son excelentes para la creación de prototipos en etapas tempranas, son problemáticos para aplicaciones de producción robustas.
Tejay Cardon
6

Utilice una base de datos basada en documentos cuando no necesite almacenar datos en tablas con campos de tamaño uniforme para cada registro. En cambio, debe almacenar cada registro como un documento que tiene ciertas características. Cualquier cantidad de campos de cualquier longitud se puede agregar dinámicamente a un documento en cualquier momento sin la necesidad de "modificar la tabla" primero. Los campos basados ​​en documentos también pueden contener múltiples datos.

smdelfin
fuente
1

Para elaborar sobre smdelfin: flexibilidad. Puede almacenar datos en cualquier estructura (sin estructurar y todos) y cada documento podría ser completamente diferente. CouchDB específicamente es útil porque con sus índices de "vista", puede filtrar documentos específicos y consultar solo esa vista cuando desee esos subconjuntos de su base de datos.

Mi mayor punto ganador de bases de datos de documentos que almacenan datos en formato JSON: este es el formato nativo para JavaScript. Por lo tanto, las aplicaciones web de JavaScript funcionan increíblemente bien con CouchDB. Recientemente hice una aplicación web que utiliza CouchDB y es rápida como un cohete mientras que también puede manejar una estructura de datos en constante variación.

MitchB
fuente
0

Las bases de datos basadas en documentos tienen una gran ventaja sobre las bases de datos relacionales, ya que no requieren definir un esquema por adelantado antes de poder ingresar ningún dato.

Además, debe usar una base de datos de documentos si sus datos no son relacionales y no pueden almacenarse en una tabla, sino que son un conjunto de imágenes o, por ejemplo, artículos de periódicos.

Otra ventaja es la facilidad de usar bases de datos basadas en documentos en el desarrollo web. Para obtener más información sobre los modelos de base de datos NoSQL, consulte esta fuente: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

evidrascu
fuente