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.

— thst
fuente

Respuestas:

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?

— Michael Green
fuente

En nuestro caso, los datos que almacenamos son básicamente datos de formularios. El usuario define el formulario en tiempo de ejecución y puede modificarlo en cualquier momento que desee. Se puede construir un formulario a partir de miles de campos. Esto puede suceder si se capturan datos de tipo lista. Si supiéramos los datos por adelantado, en tiempo de diseño de db, lo normalizaríamos. Su comentario sobre la vista de los datos me hace pensar: si los formularios se escriben como documento, ¿cómo se crea una vista de ellos para una lista u ordena los datos por un campo en la vida real? Mapa-reducir los datos, recordar y preparar la lista en código?

— 2015

Históricamente todo fue del lado del cliente: recuperó sus documentos e hizo lo que tenía que hacer. CQL tiene cláusulas con las que cualquier desarrollador de SQL estaría familiarizado. Map Reduce es la arquitectura de referencia para grandes conjuntos de datos. Y parece que Cassandra 3.0 tendrá Vistas Materializadas .

— Michael Green

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.

— LironCareto
fuente

Agradezco su respuesta, pero de hecho, la situación es tal, que realmente no conocemos la estructura de los datos. Almacenamos datos de formularios y no conocemos la estructura del modelo del formulario. Por supuesto, lo sabemos en la aplicación, pero es dinámico y se puede cambiar en cualquier momento.

— 2015

Entendido. No sé qué tan desafiante es esto, pero como idea intentarlo, ¿funcionaría crear una tabla que contenga el conjunto de claves comunes referenciadas en la tabla llena por el usuario por un FK que realiza, tal vez un INTEGER? Tal vez sea un poco mejor rendimiento que indexar una columna varchar que, si está cambiando muy dinámicamente, supongo que no será corta. Y también reduciría el tamaño del índice.

— LironCareto

Esto nos aleja de la pregunta, pero hemos discutido ciertas limitaciones en las posibilidades del usuario. Por ejemplo, reduzca los campos máximos de la tabla de aplicaciones a 10 campos vall varchar db. Esta es una desnormalización del esquema para seleccionar básicamente el conjunto de datos del encabezado y los 10 valores de la columna de la aplicación de una vez o con un máximo de unión en la tabla db adicional. Al cambiar los valores relevantes, también tendríamos que modificar esta fila db en el código. Esto parece factible y reduce la cantidad de uniones en hasta 10 para que un seleccionado muestre la tabla de aplicaciones. Sin embargo, cambiar la definición de la columna de la aplicación del usuario es muy costoso.

— 2015

Está bien, no te preocupes. Creo que entiendo su punto de vista, y su enfoque me considera una buena compensación entre la mejora del rendimiento y la viabilidad. Es importante tener estadísticas de uso, obviamente, para determinar esos campos. ¿Lo has comparado? Al menos le puede dar algo de tiempo hasta que encuentre una solución (¿mejor? ¿Definitiva?) O tal vez descubra que puede ejecutar esto durante mucho tiempo.

— LironCareto