NoSQL: ¿Qué son los datos no estructurados?

Actualmente estamos corriendo al límite de los recursos con nuestra solución basada en servidor mssql.

Ahora tenemos muchas opciones tradicionales con respecto al próximo movimiento para abordar la carga:

• comprar CPU e IO más rápidos
• dividir algunos clientes para separar el servidor
• mover db al clúster

Todos son caros en términos de licencias y hardware o tiempo. Por lo tanto, quiero agregar otra opción moviendo todo el sistema a una solución escalable que promete el motor nosql cassandra.

Sin embargo, no estoy seguro ni tengo experiencia con las bases de datos noSQL, por lo que necesito comprender la estructura de los datos "no estructurados".

En nuestra aplicación, básicamente almacenamos los datos ingresados ​​por los usuarios de varias maneras como listas de "valor-clave". Hay una tabla principal, que contiene el elemento principal (como un Pedido) y hay una tabla secundaria con los pares clave-valor que comprenden el contenido del pedido (como Order_Lines).

Business-wise, Order y OrderLines son una unidad. Pero debido al RDBMS, se almacenan en tablas y se deben unir todo el tiempo.

Durante las operaciones, a veces elegimos cargar solo la parte superior, pero la mayoría de las veces, cargamos la fila principal + algunos KVP para mostrar información útil.

Por ejemplo, en una lista general, mostramos el identificador de cabeza + algunos valores en columnas para cada fila.

ACTUALIZACIÓN: Almacenamos formularios de cualquier tipo. Entonces, básicamente almacenamos "documentos". Sin embargo, tenemos que preparar y buscar a través de estos formularios por cualquier valor, tipo, etc. El control de acceso a datos agrega otra capa de competencia en la base de datos.

Como puede suponer, la cantidad y disponibilidad de ciertos KVP varía de un objeto a otro. No existe una posibilidad válida para crear tablas individuales para cada tipo de objeto, ya que tendríamos que crear miles de tablas para las diferentes combinaciones de datos.

¿Este tipo de conjuntos de datos como "Diccionario" se almacenarían mejor en una base de datos noSQL? ¿Y tendremos beneficios de rendimiento de esto? ¿Cassandra modelaría estos head + KVP como un conjunto de datos? Al mirar la página web de cassandra y algunos tutoriales, tengo la impresión de que no hay mucha diferencia entre nuestro RDBMS y cassandra en términos de organización de datos, dejándonos con la misma gran cantidad de combinaciones si desea seleccionar 5 KVP para una lista para cada fila.

La iluminación es bienvenida, también están bien los consejos a los documentos que explican los problemas.

Hay un par de conceptos que deben distinguirse. Uno es sobre estructura y el otro sobre esquema.

Los datos estructurados son aquellos en los que la aplicación conoce de antemano el significado de cada byte que recibe. Un buen ejemplo son las mediciones de un sensor. Por el contrario, una transmisión de Twitter no está estructurada. El esquema trata sobre qué parte de la estructura se comunica al DBMS y cómo se le pide que haga cumplir esto. Controla cuánto analiza el DBMS los datos que almacena. Un DBMS requerido por el esquema, como SQL Server, puede almacenar datos no analizados (varbinary) o datos analizados opcionalmente (xml) y datos totalmente analizados (columnas).

Los DBMS NoSQL se encuentran en un espectro desde el no análisis (almacenes de valores clave) hacia arriba. Cassandra ofrece una funcionalidad bastante rica a este respecto. Donde difieren notablemente de las tiendas relacionales es en la uniformidad de los datos. Una vez que se define una tabla, solo los datos que coinciden con esa definición pueden mantenerse allí. Sin embargo, en Cassandra, incluso si se definen columnas y familias, no es necesario que ninguna de las dos filas de la misma tabla se parezca entre sí. Al diseñador de la aplicación le corresponde decidir cuánto va en una sola fila (también denominado documento) y qué se mantiene por separado, vinculado por punteros. En efecto, cuánta denormalización desea.

La ventaja es que puede recuperar un conjunto completo de datos con una sola lectura secuencial. Esto es rapido. Una desventaja es que usted, el programador de aplicaciones, ahora es el único responsable de todas las preocupaciones de integridad de datos y compatibilidad con versiones anteriores, para siempre, de cada bit de código que alguna vez toque este almacén de datos. Eso puede ser difícil de acertar. Además, está bloqueado en un punto de vista sobre los datos. Si ingresa sus filas por número de pedido, ¿cómo informa sobre la venta de un producto, región o cliente en particular?

A pesar de la corriente principal de las bases de datos noSQL, en mi humilde opinión, la decisión de adoptar dicha tecnología debe tomarse de acuerdo con los logros necesarios de acuerdo con la información almacenada, no solo atendiendo al rendimiento que tiene actualmente. Esto significa que quizás su mejor opción es apegarse a la base de datos SQL y mejorar su HW.

Pero además leí algo en su pregunta que me hizo pensar. No hay mucho sobre el estado actual de su base de datos, pero su oración "básicamente almacenamos los datos ingresados ​​por los usuarios de varias maneras como listas de" valores clave " me hace pensar si el problema no sería un modelo de datos deficiente en lugar de La falta de recursos físicos. He gestionado tablas realmente grandes (+10 mil millones de filas) con un rendimiento increíble en bases de datos SQL "tradicionales".

No digo que esté mal, simplemente, ya que, por supuesto, no puedo evaluarlo en el modelo de datos correcto con tan poca información sobre su solución actual, sino solo pensar en volver a visitar su modelo de datos como una opción adicional junto con el resto ya que usted puede encontrar alguna pista rascando allí.

Por lo general, las listas de valores clave están bien como una compensación cuando no puede implementar el modelo en su estado final porque no conoce las diferentes claves que tendrá que enfrentar o cuando necesitará los valores de uno de los posibles claves para un determinado elemento. Pero cuando se implementa, generalmente me gusta repensar tales decisiones después de un tiempo cuando ha reunido suficiente cantidad de información para identificar el caso de uso común y decidir si la decisión del modelo de datos es la mejor. Si sabe que tendrá un cierto número de teclas, intente hacer un punto de referencia con un diseño de una tabla regular de la manera tradicional

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... y sumando los índices correspondientes. Pruébelo y mida los planes de ejecución con ambos enfoques. Puede sorprenderse especialmente si reúne más de una clave a la vez, ya que, entre otras ventajas, el tamaño del bloque de datos debería reducirse y, por lo tanto, el rendimiento mejoraría.

Espero que esto ayude, o al menos amplíe las posibilidades y abra una nueva línea para la investigación.