Con la reciente presencia de bases de datos NoSQL, ¿por qué usaría una base de datos SQL?

Question

Después de desarrollar software durante aproximadamente 5 años, he gastado probablemente al menos un 20% y tal vez hasta un 40% de ese tiempo simplemente haciendo que un RDBMS pueda guardar y recuperar gráficos de objetos complejos. Muchas veces esto resultó en soluciones de codificación menos que óptimas para hacer algo más fácil de hacer desde el lado de la base de datos. Esto finalmente terminó después de una cantidad muy importante de tiempo dedicado al aprendizaje de NHibernate y los patrones de gestión de sesiones que forman parte de él. Con NHibernate, finalmente pude evitar la gran mayoría del tiempo perdido al 100% de escribir CRUD por milésima vez y utilizar la generación de mi base de datos desde mi modelo de dominio.

Sin embargo, todo este trabajo aún resulta en un modelo defectuoso donde mi base de datos es simplemente el mejor intento de SQL para imitar mi objeto real. Con las bases de datos de documentos, este ya no es el caso, ya que el objeto se convierte en el documento en sí mismo en lugar de simplemente emular el objeto a través de tablas y columnas.

En este punto, realmente me estoy empezando a preguntar por qué volvería a necesitar SQL.

¿Qué se puede hacer realmente sustancialmente mejor con SQL que una base de datos de documentos?

Sé que esto es algo así como una comparación de manzanas a naranjas, especialmente cuando se tienen en cuenta los diversos tipos de bases de datos NoSQL que tienen conjuntos de características muy diferentes pero basándonos en este argumento basamos en la noción de bases de datos NoSQL. inherentemente consultar objetos correctamente y no en las limitaciones de un almacén de valores clave. También omita el aspecto de informes ya que, en general, se debe manejar en una base de datos OLAP a menos que su respuesta incluya una razón específica por la que no usaría una base de datos OLAP para ello.

Answer 1

Mi pregunta clave era dónde una base de datos SQL realmente eclipsaría una base de datos de documentos y de todas las respuestas realmente no parece haber mucho.

Dado que las bases de datos NoSQL vienen en tantas variaciones de tipos de bases de datos como relacionales que coinciden con todas o algunas partes de ACID, dependiendo de la base de datos que utilice, en este punto son básicamente equitativas para resolver problemas.

Después de esto, las diferencias clave serían las herramientas y la madurez que las bases de datos SQL tienen un mayor alcance para ser el jugador establecido, pero así es para todas las nuevas tecnologías.

Answer 2

modelado de datos relacional es una solución formal, matemático para representar datos complejos sin redundancia y sin permitir anomalías. Puede diseñar un diseño de base de datos óptimo a partir de las relaciones de datos. Este es el proceso de relacional database normalization.

El modelado de datos no relacionales no tiene una forma formal de definir la mejor estructura de base de datos a partir de los datos. Puede diseñar una base de datos en función de su uso anticipado; es decir, sus consultas determinan la mejor organización de datos, no los datos en sí.

En las bases de datos no relacionales, nunca puede estar seguro de que los datos se ajusten a una determinada estructura de documentos. Podría tener documentos sobrantes en la base de datos de una revisión anterior. Por lo tanto, su código de aplicación debería ser capaz de "descubrir" la estructura de cada documento, realizar conversiones si es necesario y esperar que las referencias entre las colecciones de datos se cumplan.

En las bases de datos relacionales, puede confiar en que la integridad de los datos sea una parte integral del modelo. Si diseñas para la normalización y configuras las restricciones correctamente, sabes que nunca tendrás huérfanos ni anomalías de datos.

Las bases de datos no relacionales le dan un tipo de eficiencia, ya que está diseñando la base de datos. Las bases de datos relacionales le dan otro tipo de eficiencia, ya que es usando la base de datos.

Dicho esto, el tipo específico de problema con el que ha estado trabajando - gráficos de objetos - es difícil de lograr de manera eficiente con SQL simple. Pero creo que descubrirá que no es mucho más fácil con las bases de datos NoSQL.

---

Re tu comentario: Por supuesto, consistency no es una prioridad para cada aplicación. Eso no hace que el valor de la consistencia sea "insustancial" para las aplicaciones donde es importante.

Ha preguntado por qué usaría bases de datos relacionales; las usaría cuando los beneficios de las bases de datos relacionales se ajustaran a las prioridades de su proyecto.

No maneje un clavo con un destornillador, y no gire un tornillo con un martillo. Hay una herramienta adecuada para resolver cada tipo de problema.

Answer 3

Cuando investigué bases de datos no SQL, descubrí que no proporcionaban ACID ni proporcionaban características relacionales (no eran bases de datos relacionales). Desde I como la consistencia de los datos, y generalmente he querido algún tipo de función relacional, no he seleccionado ninguna base de datos SQL.

Sin embargo, no utilizo las herramientas ORM, tiendo a escribir SQL.

Answer 4

En Amazon trabajé con un montón de código. La mayor parte del código que trabajé fue código que nadie entendía realmente. Estaba plagado de manejo de casos especiales que no se entendía bien porque era una acumulación de parches rápidos durante un largo período de tiempo. Si querías entender completamente el efecto de un cambio que estabas haciendo, no tenías suerte. En esencia, se vio obligado a agregar a la acreción.

También trabajé con una gran cantidad de datos. La estructura de las tablas en SQL hizo una excelente documentación a largo plazo para los datos. La base de datos era relativamente fácil de trabajar directamente, y la estructura de los datos tenía sentido. Había personas cuyo trabajo era administrar la estructura y la integridad de los datos.

Me temo que una base de datos NoSQL, con su falta de estructura bien documentada, adquirirá lentamente todas las cualidades malvadas del código que trabajé. Terminaría lleno de datos de estructuras antiguas que ya nadie entendía, y se convertiría en un vasto mosaico de basura en su mayor parte inútil.

Veo los principales beneficios de las bases de datos SQL como la documentación forzada que requiere el mantenimiento de la estructura de la base de datos y las reglas de coherencia. Esos beneficios no tienen una medida fácil a corto plazo, como la velocidad de una consulta o la coherencia transaccional. Son beneficios a largo plazo que afectan la utilidad de sus datos durante un período prolongado de tiempo.

Como segundo punto relacionado, me resulta más útil, al utilizar ORM y similares, mapear mis datos y luego decidir cómo se traducirán en objetos en la aplicación que estoy escribiendo. Los datos y sus relaciones representan una estructura de archivo a largo plazo que puede ser utilizada para una variedad de propósitos.

La estructura de las relaciones de objeto en la aplicación están ahí para los propósitos de esa aplicación. Un conjunto dado de datos representados en tablas SQL y restricciones de relación tendrá muchos posibles modelos de objetos que lo representen en una aplicación, y cada uno de esos modelos de objetos reflejará los objetivos de esa aplicación en particular. Pero los datos y su estructura existen independientemente de cualquier uso efímero dado que pueda hacerse de ellos.

Veo los argumentos que las personas hacen acerca de 'informar' como argumentos que las diferentes aplicaciones pueden ver útilmente el mismo conjunto de datos de maneras muy diferentes.

Personalmente, creo que SQL es un buen modelo para usar directamente para datos de archivo, datos modificados con poca frecuencia o datos con requisitos de consistencia extremadamente altos.Y creo que seguiré usando el álgebra relacional para definir la estructura general de mis datos, incluso si la estoy almacenando en una base de datos NoSQL. Y no cambiaré la estructura de los datos en la base de datos NoSQL sin primero modificar la estructura relacional que la describe. Esto me permitirá mapear mis bases de datos NoSQL a SQL, de modo que aún puedo usar SQL para almacenamiento y almacenamiento a largo plazo y me obligo a mantener las estructuras de datos en una forma bien documentada.

Hacer las cosas de esta manera también me ayudará cuando tenga que extraer datos de la base de datos NoSQL para utilizarlos en aplicaciones que no se previeron cuando se creó la base de datos.

Por supuesto, hay algunos datos cuya estructura naturalmente se adapta a NoSQL y donde la generación de un esquema relacional sería inútil. Por ejemplo, almacenamiento de documentos reales, almacenamiento de imágenes u otros medios u otras grandes cantidades de datos que no tienen una estructura que pueda ser útil para representar. Sin embargo, esta distinción es muy engañosa. Las imágenes y las películas tienen estructura para ellas, pero generalmente no es la estructura que necesita almacenar en una base de datos. Una publicación de blog también puede tener estructura si tiene un sistema diseñado para intentar leerla y comprenderla, y esa puede ser una estructura de la que desea mantener un registro.

Answer 5

depende de lo que está tratando de hacer. cuando necesite realizar búsquedas en diferentes campos de sus objetos, SQL es bueno. si no necesita realizar una búsqueda y tiene estructuras de árbol polimórfico muy complejas, SQL es horrible.

he trabajado en la aplicación que permitía a los usuarios crear páginas web uniendo pequeños fragmentos y la serialización original usaba tablas SQL de clave/valor. todos los fragmentos tenían propiedades que fueron almacenadas (fragmento, propiedad, valor). tan esquemático pero aún así un montón de trabajo pesado. probablemente lo peor de ambos mundos porque realmente no se obtiene mucha validación de datos de la base de datos, es muy difícil mirar las tablas y entender lo que está pasando y todavía hay mucho trabajo para escribirlo en el DB y léelo de nuevo.

También hicimos una aplicación similar pero aprendimos nuestra lección y tomamos clases simples de Java y las codificamos usando JSON. el usuario simplemente edita su página al frente en una interfaz de usuario enriquecida. hace clic en guardar y toda la página se envía de vuelta al servidor como un objeto json. el servidor realiza la validación en el objeto para asegurarse de que todas las restricciones sean correctas, lo que siempre debería ser cierto a menos que un usuario haya sido manipulado o haya un error en el código. luego el objeto se escribe en una fila codificando para volver a json.

esto nos funciona bien porque nunca queremos tratar con parte del objeto. siempre tratamos con todo el objeto, por lo que JSON no solo es más fácil sino que es más rápido que hacer las más de 40 consultas en cada lectura que tendríamos que hacer si se normalizara correctamente.

Answer 6

La herramienta es mucho mejor para SQL. NoSql tiene una reputación de errores. Pero incluso suponiendo que esas dos diferencias se igualen ...

Tengo la experiencia opuesta a la tuya al modelar objetos complejos en SQL. Decir que las tablas y columnas son, en el mejor de los casos, una "emulación" de tus objetos, es un poco semántico. Cualquier serialización de sus objetos también sería una emulación: mientras que una base de datos de documentos o xml o lo que sea puede parecer una mejor emulación que las tablas/columnas, tiende a ser una tecnología menos poderosa. Los ORM han ayudado inmensamente a cerrar la brecha entre RBDMS y los lenguajes orientados a objetos.

Desde que se formalizó la teoría relacional, SQL ha sido el rey. Los db jerárquicos (que son las bases de datos de documentos) se pierden, los dbs relacionales se ganan. Me preguntaría, dada la historia, ¿su problema es tan diferente de la mayoría de los problemas en los últimos 30 años que necesita volver a la forma jerárquica?

Los dbs de NoSql están ahora a la orden de los problemas que requieren escalado horizontal (que ahora SQL no funciona bien).¿Tu problema lo requiere?

Answer 7

Mi forma de ver la pregunta es la opuesta: ¿Por qué alguna vez necesitaría ningún SQL?

SQL me proporciona modelado relacional, transacciones, desencadenadores, claves, restricciones, esquemas dinámicos que se pueden modificar en un abrir y cerrar de ojos SIN TOGO garantizar integridad de datos, consultas complejas y rápidas sobre datos que se representan en su estado más puro y limpio formar.

Su problema es que está intentando colocar clavijas cuadradas en agujeros redondos: objetos y rdbms no funcionan bien juntos, porque el RDBMS está diseñado para manejar muchas de sus lógicas get/set más complejas, y hacer cumplir la consistencia , que es exactamente lo que espera de su capa de objeto.

Protip: suelta los objetos, no son la herramienta adecuada para el trabajo.

Answer 8

Es importante recordar que relational sigue siendo (y seguirá siendo durante algún tiempo) la plataforma elegida para: procesamiento de transacciones, gestión de datos maestros, datos de referencia, almacenamiento de datos (en MPP), BI (aunque invertido la base de datos de columna es sobresaliente en el rendimiento de la consulta). Dado el estado actual de NOSQL, es casi absurdo que pueda reemplazar relacional para los usos anteriores.

Answer 9

Existen variantes de bases de datos no solo SQL, cada una tiene sus pros y sus contras.

están basados ​​en documentos o en objetos, basados ​​en columnas (fila ancha), basados ​​en valores clave y basados ​​en gráficos, y eso es solo lo que se me ocurre en este momento. Cada uno de esos tipos de base de datos tiene sus puntos débiles y sus fortalezas (en comparación con otros y con RDBMS).

La verdadera pregunta que debe hacerse al tomar una decisión para qué tipo de BD elegir es cómo va a utilizar los datos.

en la mayoría de los casos comunes, al menos hasta cierto nivel de complejidad de objetos, y para datos no grandes, los RDBMS se preocupan menos por cómo se usan los datos y más acerca de los mismos. En RDBMS, solo necesita conocer su estructura de datos y sus relaciones internas y, una vez que se da cuenta, simplemente lo coloca en un esquema de formulario normal y si coloca las claves e índices correctos obtiene el rendimiento de patadas en la mayoría de las consultas. En una base de datos NoSQL es más crucial.

por ejemplo, si está manteniendo documentos de pedido, y desea consultar el pedido con el máximo beneficio obtenido en un rango de fechas, afaik si no es un experto (como no soy tal) terminará tener una consulta O (n), mientras que en RDBMS tomará menos y sin duda será más eficiente, incluso si usted es un experto MongoDB.

En conclusión, si sabe de antemano cómo se usarán sus datos, y sabe que un documento db sería eficaz para su caso de uso, entonces sí, tome ese documento DB, pero si no está seguro de cómo su se usarán datos, entonces RDBMS generalmente sería una decisión más inteligente.

Y por-supuesto que existe la bigdata argumant es necesario tomar en cuenta, según los RDBMS dont escalar (no puedo agregar fácilmente nodos para soportar más tráfico), y obtiene menos eficiente cuando se trata de datos de gran tamaño (puede empezar a retraso en GB o PB).

Además, tenga en cuenta que los RDBMS son mucho más antiguos y se han desarrollado ampliamente a lo largo de los años que los documentos DB que hacen RDBMS contienen más optimizaciones y herramientas que cualquiera de las alternativas NoSQL.