Los datos en nuestro DBMS relacional se están volviendo grandes, ¿es el momento de pasar a NoSQL?

Creamos una aplicación de red social para fines de eLearning. Es un proyecto experimental que estamos investigando en nuestro laboratorio. Se ha utilizado en algunos estudios de casos durante un tiempo y los datos en nuestro DBMS relacional (SQL Server 2008) se están volviendo grandes. Ahora son unos pocos gigabytes y las tablas están muy conectadas entre sí. El rendimiento sigue siendo bueno, pero ¿cuándo debemos considerar otras opciones? ¿Es cuestión de rendimiento?

Unos pocos gigabytes no son muy " grandes ". Es más como el tamaño normal de una base de datos empresarial. Siempre que supere PK al unir tablas, debería funcionar realmente bien, incluso en el futuro (siempre que no obtenga TB de datos al día).

La mayoría de los profesionales que trabajan en un entorno de Big Data consideran > ~ 5 TB como el comienzo del término Big Data. Pero aun así, no siempre es la mejor manera de instalar la siguiente mejor base de datos nosql. Siempre debe pensar en la tarea que desea archivar con los datos (agregado, lectura, búsqueda, mina, ...) para encontrar las mejores herramientas para su problema.

es decir, si realiza muchas búsquedas en su base de datos, probablemente sería mejor ejecutar una instancia / clúster solr y desnormalizar sus datos de un DBMS como Postgres o su SQL Server de vez en cuando y colocarlos en solr en lugar de simplemente mover los datos de sql a nosql en términos de persistencia y rendimiento.

Para responder a esta pregunta, debe responder qué tipo de compromiso puede pagar. RDBMs implementa ACID . Esto es costoso en términos de recursos. No hay soluciones NoSQL que sean ACID. Vea el teorema CAP para profundizar en estas ideas.

Por lo tanto, debe comprender cada compromiso dado por cada solución y elegir el que sea más apropiado para su problema.

Big Data en realidad no se trata tanto de "cuán grande es".

Primero, unos pocos gigabytes no son grandes en absoluto, no son casi nada. Así que no te molestes, creo que tu sistema continuará funcionando eficientemente durante algún tiempo.

Entonces tienes que pensar en cómo usas tus datos.

• Enfoque de SQL: todos los datos son valiosos, están bien recopilados y seleccionados, y el objetivo es almacenar datos valiosos y bien estructurados. Esto puede ser costoso, todo es entrelazado y es bueno para un sistema bien estructurado y datos funcionales.
• Enfoque de Big Data: en Big Data básicamente almacena casi todo, independientemente del valor que tenga, y luego realiza un proceso de análisis activo. Las cosas no están vinculadas, se copian. Por ejemplo, digamos que tengo una entrada de blog. En Big Data no habrá un enlace a su autor, pero el autor estará incrustado dentro de la entrada del blog. Mucho más escalable, pero requiere un enfoque diferente y más complejo.

Si su aplicación utiliza datos de almacenamiento "funcionales", le sugiero que permanezca en SQL. Si está almacenando datos para buscarlos más tarde o para hacer informes, y si esta cantidad de datos puede aumentar rápidamente, sugeriré datos grandes. En mi opinión, los grandes datos son útiles cuando se trata de datos reales que deben recopilarse y analizarse continuamente.

Publiqué una respuesta bastante detallada en stackoverflow sobre cuándo es apropiado usar una base de datos relacional vs documento (o NoSQL), aquí:

Motivaciones para usar la base de datos relacional / ORM o la base de datos de documentos / ODM

Resumen:

• para cosas pequeñas, vaya con las herramientas con las que esté familiarizado

• unos pocos gigabytes son definitivamente cosas pequeñas: no se hace grande hasta que es demasiado grande para caber en un solo clúster MySQL con un número razonable de nodos (16-32), lo que significa tal vez datos de 8-16TB y unos pocos millones de transacciones por segundo (o una base de datos más convencional basada en disco duro con hasta 100 de datos de TB y algunos miles de transacciones por segundo).

• Si está atascado con otra base de datos (no con MySQL Cluster), aproveche al máximo el rendimiento agregando hardware FusionIO.

• Una vez que tenga datos más grandes que unos pocos TB y más rápido que miles de transacciones por segundo, es un buen momento para considerar pasar al fragmentación lógica en el código de la aplicación primero y luego a NoSQL.

• Cassandra :)

¿Es el momento de pasar a NoSQL dependerá de 2 cosas:

1. La naturaleza / estructura de sus datos.
2. Tu desempeño actual

Las bases de datos SQL se destacan cuando los datos están bien estructurados (por ejemplo, cuando se pueden modelar como una tabla, una hoja de cálculo de Excel o un conjunto de filas con un número fijo de columnas). También es bueno cuando necesita hacer muchas uniones de mesa (lo que parece ser que usted hace).

Las bases de datos NoSQL se destacan cuando los datos no están estructurados más allá de los pares clave-valor.

En cuanto al rendimiento, debe hacerse una pregunta: ¿su solución SQL actual es lenta ?

Si no, vaya con el principio " IIABDFI ".