Base de datos de documentos versus base de datos relacional: ¿cómo elegir?

Soy un tipo de SQL, pero sé que no solo hay bases de datos SQL, principalmente bases de datos de documentos. Como con la mayoría de las tecnologías, hay ventajas y desventajas para cada tecnología.

He leído algunos artículos, pero eran demasiado teóricos. Lo que me gustaría son dos casos reales:

cuando un cambio de base de datos relacional a documento dio una mejora
cuando un cambio de documento a base de datos relacional dio una mejora

La mejora es cualquier cosa que hace mejores programas: menos tiempo de desarrollo, escalabilidad, rendimiento, todo lo relacionado con la programación. Hay una advertencia para 2.: historias como "recurrir a la base de datos relacional porque todo el mundo sabe SQL" no es bueno

nosql relational-database

— Johan Buret
fuente

Enfoque equivocado. No se trata de "rendimiento" o "escalabilidad". Se trata de qué modelo se ajusta al problema que está tratando de resolver. Es posible que desee actualizar su pregunta para permitir la idea de que tal vez la base de datos relacional no sea adecuada para numerosos tipos de problemas.

— S.Lott

@ S.Lott, la elección es a menudo una cuestión de rendimiento. considere que cualquier base de datos relacional puede usarse como una base de datos de documento simple; solo el rendimiento sería una característica distintiva.

— edA-qa mort-ora-y

He reformulado mi pregunta para que no se cargue de ninguna manera.

— Johan Buret

@ edA-qa mort-ora-y: "cualquier base de datos relacional puede usarse como una base de datos de documento simple". Eso debe ser falso o la gente no habría inventado una alternativa. "solo el rendimiento sería una característica distintiva". Solo es cierto si supone que el modelo relacional hace todo igualmente bien. Si hiciera todo, no habría alternativa. Todavía. Tenemos alternativas Hay muchos problemas (como las jerarquías) que no se ajustan perfectamente al modelo relacional y requieren trucos ingeniosos. O un modelo de datos alternativo.

— S.Lott

"leer algunos artículos"? Proporcione algunos enlaces o títulos o referencias o citas. No sabemos qué significa "demasiado teórico" para usted.

— S.Lott

Respuestas:

La razón principal para elegir una base de datos NoSQL en los últimos años ha sido Disponibilidad . Para compañías como Amazon, Google y Facebook, una hora de tiempo de inactividad no es aceptable. Para lograr una alta disponibilidad, debe reducir el punto único de falla, lo que significa que debe usar un sistema distribuido con varias computadoras en caso de que una computadora falle, el servicio aún está disponible.

Las bases de datos tradicionales de Relatione no son muy buenas en una configuración distribuida de varios maestros. Es por eso que NoSQL ha sido tan popular últimamente. Entonces, si necesita alta disponibilidad, puede elegir una base de datos NoSQL como Riak, Cassandra, HBase, S3 o BigTable.

Hay una buena publicación de blog sobre Dynamo de Amazon que es una buena introducción a las bases de datos NoSQL distribuidas.

Ahora, el término NoSQL es muy amplio, por lo que hay muchas bases de datos NoSQL que no están distribuidas. Pero resuelven otros problemas. Por ejemplo, Neo4j : una base de datos de gráficos es buena para un tipo de consultas para las que los RDBMS tradicionales no están optimizados. O como en su caso, una base de datos de documentos, donde no tiene que cambiar el esquema si desea agregar algunos campos para algunos documentos. En otras palabras, una base de datos de documentos es buena cuando la mayoría de las publicaciones (documentos) tienen campos diferentes, por lo que no se puede usar una tabla relacional con columnas predefinidas.

Sin embargo, la mayoría de las bases de datos NoSQL no son tan flexibles como las bases de datos RDBMS tradicionales, por lo que es una buena opción usar una base de datos RDBMS tradicional hasta que ya no pueda resolver sus problemas.

— Jonas
fuente

+1, de acuerdo, la flexibilidad es un gran precio a pagar si no es necesario.

— maple_shaft

Tengo un enfoque simple para determinar la base de datos que mejor se ajusta a los datos.

Solo me pregunto: suponiendo que no tuviera una base de datos, preferiría guardar la mayoría y los datos importantes como documento o los almacenaría en una hoja de cálculo.

Cuando la respuesta es "Hoja de cálculo", esta es una señal clara de que un modelo relacional y un RDBMS tradicional se adaptan mejor a las tareas la mayoría de las veces. Si los datos son realmente simples, como solo pares de valores clave o tablas simples y la integridad referencial no es un tema, entonces una base de datos NoSQL probablemente sea la más adecuada para la tarea y podría aumentar mucho el rendimiento.

Además, cuando no puede encontrar una estructura común, una base de datos NoSQL es la más adecuada para la tarea.

Cuando los datos son más parecidos a los documentos, por ejemplo, datos textuales estructurados jerárquicamente sin relaciones claras, inmediatamente pienso en una base de datos XML, que le permite almacenar fácilmente documentos estructurados jerárquicamente. Sin embargo, a veces es mejor usar un software de administración de documentos.

Entonces, para dar una respuesta concreta y simple a ambas preguntas: depende de los datos.

cuando un cambio de base de datos relacional a documento dio una mejora

Cuando necesita conservar datos textuales estructurados jerárquicamente, una base de datos Xml puede ser una gran mejora en términos de mantenimiento y probablemente también de escalabilidad.

cuando un cambio de documento a base de datos relacional dio una mejora

Bueno, por ejemplo, cuando los datos están principalmente en forma de tabla con relaciones claras y necesita garantizar la integridad.

— Halcón
fuente

+1 para la hoja de cálculo vs analogía de documentos - gran ayuda - gracias.

— HDave

Tuvimos que renunciar al modelo relacional porque los datos que estábamos obteniendo no tenían un esquema simple, obvio, fijo y estático.

Los usuarios, y las historias de los usuarios, no tenían un esquema fijo y estático.

Intentamos imponer un esquema RDBMS fijo y estático, pero fue un error.

Cada entrega de datos de terceros (de clientes y proveedores) fue similar, pero no idéntica. Intentamos asignarlo a un esquema relacional fijo, pero la variabilidad era demasiado grande. O tuvimos que agregar campos con cada archivo (varios cada semana) o tuvimos que alejarnos del esquema relacional fijo y estático.

Si consideramos cada registro como un "documento" con un subconjunto común de elementos y una colección única (así como mal definida) de elementos de datos adicionales, nos sentimos mucho más felices.

La colección mal definida de elementos de datos es lo que los usuarios realmente necesitan para sus casos de uso.

El esquema fijo y estático del modelo relacional no se ajustaba a nuestros casos de uso.

— S.Lott
fuente

He visto que otros proyectos no cumplen con los requisitos debido exactamente a los requisitos que usted ha descrito. Para esto estaban destinadas las bases de datos de documentos.

— maple_shaft