usar - ¿Existen ventajas REALES para NoSQL sobre RDBMS para datos estructurados en una máquina?
sql y nosql ventajas y desventajas (3)
Almacenamiento sin esquema (o sin esquema). Capacidad para modificar el almacenamiento (básicamente, agregar nuevos campos a los registros) sin tener que modificar el esquema de almacenamiento ''declarado''. Los RDBMS requieren la declaración explícita de dichos ''campos'' y requieren modificaciones explícitas al esquema antes de que se guarde un nuevo ''campo''. Un motor de almacenamiento libre de esquemas permite cambios rápidos en la aplicación, solo modifique el código de la aplicación para guardar los campos adicionales, o cambie el nombre de los campos, o elimine los campos y listo.
La gente tradicional de RDBMS considera que el esquema libre es una desventaja porque argumentan que a largo plazo uno necesita consultar el almacenamiento y manejar los registros heterogéneos (algunos tienen algunos campos, otros tienen otros campos) hace que sea difícil de manejar. Pero para una puesta en marcha, el esquema libre es abrumadoramente atractivo, ya que la iteración rápida y el tiempo de comercialización es todo lo que importa (y con frecuencia, con razón).
Así que me he esforzado por averiguar si NoSQL realmente está aportando tanto valor fuera de la fragmentación automática y el manejo de datos NO ESTRUCTURADOS.
Suponiendo que pueda ajustar mis datos ESTRUCTURADOS en una sola máquina O que tenga una característica efectiva de ''sharding automático'' para SQL, ¿qué ventajas ofrece cualquier opción NoSQL? He determinado lo siguiente:
Basado en documentos (MongoDB, Couchbase, etc.) : fuera de sus capacidades de "autocomprobación", me cuesta entender dónde está el beneficio. Los objetos vinculados son bastante similares a las uniones de SQL, mientras que los objetos incrustados aumentan significativamente el tamaño del documento y provocan un desafío con respecto a la replicación (un comentario podría pertenecer tanto a una publicación Y un usuario, y por lo tanto los datos serían redundantes). Además, la pérdida de ACID y las transacciones son una gran desventaja.
Basado en valores-clave (Redis, Memcached, etc.) : sirve un caso de uso diferente, ideal para el almacenamiento en caché pero no para consultas complejas
Columnar (Cassandra, HBase, etc.) - Parece que la gran ventaja aquí es más sobre cómo se almacenan los datos en el disco, y sobre todo es útil para agregaciones en lugar de uso general
Gráfico (Neo4j, OrientDB, etc.) : el uso más intrigante, tanto de bordes como de nodos, constituye una interesante propuesta de valor, pero en su mayoría es útil para datos relacionales altamente complejos en lugar de un uso general.
Puedo ver las ventajas de Key-value, Columnar y Graph DBs para casos de uso específicos (almacenamiento en caché, mapeo de relaciones de redes sociales, agregaciones), pero no veo ninguna razón para usar algo como MongoDB para datos STRUCTURED fuera de él. capacidades de fragmentación.
Si SQL tiene una capacidad similar de ''auto-sharding'', ¿sería SQL una obviedad para los datos estructurados? Me parece que lo sería, pero me gustaría la opinión de las comunidades ...
NOTA: Esto se refiere a una aplicación CRUD típica, como una red social, un sitio de comercio electrónico, CMS, etc.
Nos pidió que asumiéramos que los datos pueden caber en una sola máquina, O que su base de datos tiene una función efectiva de fragmentación automática.
Suponiendo que sus datos de SQL tienen una función de fragmentación automática, eso significa que está hablando de ejecutar un clúster. Siempre que esté ejecutando un grupo de máquinas, debe preocuparse por la tolerancia a fallas.
Por ejemplo, supongamos que está utilizando el enfoque más simple de fragmentar sus datos por función de la aplicación y está almacenando todos los datos de su cuenta de usuario en el servidor A y su catálogo de productos en el servidor B.
¿Es aceptable para su empresa si el servidor A falla y ninguno de sus usuarios puede iniciar sesión?
¿Es aceptable para su empresa si el servidor B falla y nadie puede comprar cosas?
De lo contrario, debe preocuparse por la configuración de la replicación de datos y la conmutación por error de alta disponibilidad. Es factible, pero no agradable o fácil para las bases de datos SQL. Otros tipos de estrategias de fragmentación (clave, servicio de búsqueda, etc.) tienen los mismos desafíos.
Muchas bases de datos NoSQL manejarán automáticamente la replicación y los failovers. Algunos lo harán fuera de la caja, con muy poca configuración. Eso es un gran beneficio desde un punto de vista operativo.
Revelación completa : soy ingeniero en FoundationDB, una base de datos NoSQL que maneja automatically fragmentación, la replicación y la conmutación por error con muy poca configuración. También tiene una capa SQL para que no tenga que renunciar a datos estructurados.
Si está comenzando en un solo servidor, entonces muchas ventajas de NoSQL salen por la ventana. Las mayores ventajas del NoSQL más popular son la alta disponibilidad con menos tiempo de inactividad. Los requisitos de consistencia eventuales también pueden llevar a mejoras en el rendimiento. Realmente depende de tus necesidades.
Basado en documentos : si sus datos encajan bien en un puñado de pequeños grupos de datos, entonces una base de datos orientada a documentos. Por ejemplo, en un sitio de clasificados tenemos Usuarios, Cuentas y Listados como los datos centrales. El grueso de las operaciones de búsqueda y visualización son solo contra los listados. Con la base de datos heredada, tenemos que hacer casi 40 operaciones de unión para obtener los datos de una sola lista. Con NoSQL es una sola consulta. Con NoSQL también podemos crear índices contra datos anidados, nuevamente con resultados consultados sin uniones. En este caso, en realidad estamos duplicando datos de SQL a MongoDB para fines de búsqueda y visualización (hay otras razones), con una estrategia de migración a largo plazo en la que se está trabajando ahora. ElasticSearch, RethinkDB y otros también son excelentes bases de datos. RethinkDB en realidad adopta un enfoque muy conservador de los datos, y la indexación inmediata de ElasticSearch es insuperable.
Almacén de valor clave: el almacenamiento en caché es un excelente caso de uso aquí, cuando está ejecutando un sitio web de volumen medio a alto donde la mayoría de los datos se leen, una buena estrategia de almacenamiento en caché por sí sola puede hacer que 4-5 veces los usuarios sean manejados por un solo servidor.
Columnar : Cassandra, en particular, se puede usar para distribuir cantidades significativas de carga, incluso para búsquedas de un solo valor. El escalado de Cassandra es muy lineal al número de servidores en uso. Ideal para grandes escenarios de lectura y escritura. Esto me parece menos valioso para las búsquedas en vivo, pero muy bueno cuando tienes una carga MUY alta y necesitas distribuir. Se necesita mucha más planificación y puede que no se ajuste a sus necesidades. Puede modificar la configuración para satisfacer sus necesidades de CAP, e incluso manejar la distribución a múltiples centros de datos en el cuadro. NOTA: La mayoría de las aplicaciones NO necesitan enfáticamente este nivel de uso. ElasticSearch puede encajar mejor en la mayoría de los escenarios que consideraría HBase / Hadoop o Cassandra para.
Gráfico : no estoy tan familiarizado con las bases de datos de gráficos, así que no puedo comentar aquí.
Dado que luego comenta en MongoDB específicamente vs SQL ... incluso si ambos son auto-shard. PostgreSQL, en particular, ha avanzado mucho en términos de obtener datos no estructurados utilizables (tipos JSON / JSONB) sin mencionar el poder que puede obtener de algo como PLV8, es probablemente el más adecuado para manejar los tipos de cargas que puede lanzar. Un almacén de documentos con las ventajas de NoSQL. En el caso de que se caiga es que la replicación, la fragmentación y la conmutación por error se basan en soluciones que no están realmente en la caja.
Para cargas pequeñas a medianas, la fragmentación realmente no es el mejor enfoque. La mayoría de los escenarios se leen en su mayoría, por lo que tener un conjunto de réplicas donde tenga nodos de lectura adicionales suele ser mejor cuando tiene 3-5 servidores. MongoDB es excelente en este escenario, el nodo maestro se elige automáticamente y el failover es bastante rápido. La única rareza que he visto es cuando Azure cayó a finales de 2014, y solo uno de los servidores apareció primero, los otros dos fueron casi 40 minutos más tarde. Con la replicación, cualquier solicitud de lectura puede ser manejada en su totalidad por un solo servidor. Sus estructuras de datos se vuelven más simples y sus posibilidades de pérdida de datos se reducen.
De nuevo, en mi ejemplo anterior, para un sitio de clasificados de tamaño mediano, la gran mayoría de los datos pertenece a una única colección ... se busca en ella y se muestra desde esa colección. Con este caso de uso, un almacén de documentos funciona mucho mejor que los datos estructurados / normalizados. La forma en que se almacenan los objetos está mucho más cerca de su representación en la aplicación. Hay menos de una desconexión cognitiva y simplemente funciona.
El hecho es que las operaciones SQL JOIN eliminan el rendimiento, especialmente cuando se agregan datos en esas uniones. Para una sola consulta para un solo usuario está bien, incluso con una docena de ellos. Cuando llegas a docenas de uniones con miles de usuarios simultáneos, comienza a desmoronarse. En este punto tienes varias opciones ...
Almacenamiento en caché: el almacenamiento en caché siempre es un gran enfoque, y cuanto menos a menudo cambien sus datos, mejor será el enfoque. Esto puede ser cualquier cosa, desde un conjunto de instancias de memcache / redis hasta el uso de algo como MongoDB, RethinkDB o ElasticSearch para mantener registros compuestos. El desafío aquí se reduce a actualizar o invalidar sus datos en caché.
Migración : la migración de sus datos a un almacén de datos que mejor represente sus necesidades también puede ser una buena idea. Si necesita manejar escrituras masivas o escenarios de lectura muy masivos, ninguna base de datos SQL puede mantenerse al día. NUNCA podría manejar los gustos de Facebook o Twitter en SQL.
Algo intermedio : la necesidad de escalar depende de lo que esté haciendo y de dónde se encuentren sus puntos débiles en cuanto a cuál será la mejor solución para una situación determinada. Muchos desarrolladores y administradores temen que los datos se dividan en varios lugares, pero a menudo esta es la mejor respuesta. ¿Es necesario que sus datos analíticos estén en el mismo lugar que sus datos operativos centrales? Para el caso, ¿sus inicios de sesión deben estar estrechamente acoplados? ¿Estás haciendo muchas consultas correlacionadas? Realmente depende.
Opiniones personales por delante
Para mí, me gusta la red de seguridad que proporciona SQL. Tenerlo como el almacén central de datos principales es mi primera opción. Tiendo a tratar los RDBMS como almacenamiento estúpido, no me gusta estar atado a una plataforma determinada. Siento que muchas personas intentan sobre normalizar sus datos. A menudo, agregaré un campo XML o JSON a una tabla para que se puedan almacenar datos adicionales sin ampliar el esquema, especialmente si es poco probable que alguna vez se consulte ... Tendré propiedades en mis objetos en el código de la aplicación que almacenar en esos campos. Un buen ejemplo puede ser un pago ... si actualmente está usando un sistema o varios sistemas (uno para CC junto con Paypal, Google, Amazon, etc.), entonces los detalles de la transacción realmente no afectan sus registros, ¿por qué crear? 5+ tablas para almacenar estos datos detallados.
Cuando los datos se ajustan de forma natural a un almacén de documentos, digo que, si la gran mayoría de sus consultas son para algo que se adapta mejor a un solo registro o colección, desaparezca. Tener esto como un espejo para sus datos primarios es genial.
Para datos pesados de escritura, quiere que se jueguen múltiples sistemas ... Depende en gran medida de sus necesidades aquí ... ¿Necesita un rendimiento rápido de consultas en caliente? Ir con ElasticSearch. ¿Necesitas una escala horizontal masiva absoluta, HBase o Cassandra.
La clave aquí es no tener miedo de mezclarlo ... realmente no hay una talla única para todos. Dejando de lado, creo que si PostgreSQL encuentra una solución válida (para la versión de código abierto), incluso para la replicación y la conmutación por error automatizada, están en una posición mucho mejor que la mayoría en ese momento.
Realmente no me involucré, pero creo que debería mencionar que hay varias soluciones SaaS y otros proveedores que ofrecen sistemas SQL híbridos. Puede desarrollarse contra MySQL / MariaDB localmente e implementarlo en un sistema con SQL sobre un clúster de almacenamiento distribuido. Todavía siento que HBase o ElasticSearch son mejores para el registro y los datos analíticos, pero el SQL en las mejores soluciones también es convincente.