Voy a guardar una gran cantidad de datos financieros en mi base de datos, como precios de acciones y obligaciones, etc. ¿Necesito migrar a Big Data y NoSQL o seguir con SQL solamente?

Answer 1

Ciertamente, puede almacenar sus datos en algún tipo de base de datos que no sea SQL, pero el software RDBMS principal que está basado en SQL ciertamente puede manejar una base de datos donde solo cambian cientos de miles de filas a la vez, especialmente si se leen la mayoría de las consultas -solo y se puede realizar sin preocuparse por las transacciones de actualización que se ejecutan actualmente

A menos que haya algún otro requisito que no haya mencionado, como hacer un análisis de big data en la base de datos como si fuera un almacén de datos, y al mismo tiempo usarlo en tiempo real como un Almacén de datos operativos, o algo así forzar el motor de concurrencia de la base de datos, tanto Oracle como SQL Server deberían poder administrar sus datos de manera adecuada y más fácilmente, sin siquiera sudar. Ni siquiera apostaría contra PostgreSQL. Esta cantidad de información NO es Big Data.

Answer 2

Otros han dado buenos consejos, por lo que tomaré una táctica diferente: piense detenidamente cómo accederá y procesará sus datos; Es posible que ni siquiera necesite un DBMS.

---

Actualmente estoy trabajando en un proyecto que toma datos de precios de valores al final del día y calcula varios valores derivados e indicadores de tendencias a partir de ellos. Actualmente maneja más de medio millón de registros de precios (OHLCVV), generando 350 nuevos valores para cada registro desde cero todos los días.

Mi especificación original requería un backend DB de PostgreSQL, pero luego me di cuenta de que cuando básicamente estoy leyendo toda la serie de datos en el mismo orden en que se recibió (por fecha) y escribiendo nuevos datos en ese mismo orden, cualquier DB SQL fue exageración grave En una broma, le dije a mi socio comercial que usaría … archivos CSV .

Toda la operación ahora se ejecuta en mi MacBook Air. Lee, calcula y escribe más de 200 millones de valores de coma flotante en más de 50,000 archivos CSV … en un minuto plano . Es lo suficientemente rápido que abandoné los planes para admitir cálculos incrementales sobre datos nuevos: la complejidad adicional no justificaba el ahorro de tiempo con solo volver a procesar todo el conjunto de datos después de agregar los datos nuevos a los archivos CSV apropiados.

Más importante aún, cuando mi socio comercial quiere verificar mis cifras, simplemente copio los archivos CSV en una unidad flash y literalmente se los lanzo para importarlos a Excel … mientras ambos estamos sentados en un tren rumbo a casa. También escribo mis pruebas de código como simples guiones AWK; CSV y AWK son un matrimonio hecho en el cielo.

Answer 3

A menos que esas filas tengan un tamaño de megabytes, entonces todavía está en el rango donde su conjunto de datos podría caber racionalmente en la RAM.

100k filas * 10kB / fila = 1GB

Entonces, si toma 800k filas, compra un servidor con 16GB de RAM y todo encaja. En ese ámbito, casi no importa lo que uses.

SQL tiene la mayoría de las características en el paquete más conocido. Entonces no está claro que necesites algo más.

Answer 4

Para el análisis de big data, se pueden utilizar bases de datos noSQL Si solo desea buscar algo en estos datos, puede usar los índices de Solr, pero para las agregaciones, MongoDB puede usarse porque Solr no tiene capacidades de agregación. Sin embargo, varios cientos de miles de filas no son un gran dato, por lo que puede usar SQL, pero puede no funcionar como sistemas NoSQL. Este rendimiento depende de sus consultas. En ese caso, creo que MongoDB es una buena opción.

Answer 5

Si no necesita Mapreduce o algo así, un RDBMS funcionará. No obtendrá inconsistencias si diseña su modelo de base de datos correctamente. No creo que tenga problemas de rendimiento con solo cientos de miles de filas.

Answer 6

Los “varios cientos de miles de filas” no parecen necesitar hadoop. No estoy seguro de si los datos son principalmente de valor clave o formato json, pero parece que puede optimizar con un valor de clave db, si se trata principalmente de precios de acciones y artículos como ese.

Answer 7

Una cosa más que quiero señalar aparte de las de las respuestas:
Es posible que desee agregar más atributos en la entrada y / o anidarlos. Para todo esto, debe optar por NoSQL preferiblemente. Mientras que entre mongo y hadoop, creo que deberías ir a mongoDB.

Answer 8

Estoy de acuerdo con otros respondedores: MongoDB es el camino a seguir, ya que solo necesita leer los datos y no procesarlos.
Si se le permite elegir entre bases de datos NoSQL, le sugiero que busque en la tienda de valores clave como Redis / Memcached ya que las velocidades de lectura son más rápidas en estos.