Imagine que su requisito es que tiene 3 tablas enormes (datos estructurados) con, digamos, 30 mil millones de filas en cada una (tamaño total de 4 TB) y sus muchos usuarios concurrentes (que son hilos de sistema operativo paralelos en máquinas LAN remotas) necesitarán leer una parte de los datos a través de sus consultas SELELCT WHERE GROUPBY y altamente concurrentes, digamos 10,000 lecturas concurrentes al mismo tiempo y también los usuarios necesitan insertar (sin actualizar) datos en estas tablas altamente concurrentes también como 2000 escritores concurrentes (en toda la red LAN del centro de datos) . Los usuarios desearían leer e insertar lo más rápido posible de este almacenamiento donde cada lectura y escritura se realizará en un rango de ms a 1 segundo.
¿Qué tecnologías recomienda para satisfacer tal requisito? ¿Hay algún almacenamiento de datos o almacén de valores clave que pueda hacer esto? La nube NO es una opción.
Algunas aclaraciones:
Los usuarios NO tienen que ver los datos de inmediato y la consistencia eventual es aceptable. Se accede a los datos a través de cualquier controlador que pueda proporcionar el almacenamiento y los usuarios nuevamente son solo hilos que se ejecutan en máquinas remotas del centro de datos. Las consultas son principalmente como SELECCIONAR DONDE GROUPBY.
Los datos están en formato tabular y cada fila tiene aproximadamente 60 bytes.
No hay opción de nube donde no puedo usar DynamoDB o soluciones similares. Tengo que poder alojarlo internamente en el centro de datos.
Todos los datos de las tablas se pueden leer todo el tiempo y el patrón de uso es impredecible. No hay unión o consulta super larga. No se requiere DR, pero se requiere un HA razonable, pero no tiene que ser elegante. Todos los lectores obtienen lotes de filas según su cláusula where y las filas no están realmente relacionadas. Probablemente podamos tener una longitud fija para cada fila, pero espero que la capa de almacenamiento se preocupe por eso.
Además, mi mayor preocupación son todas esas escrituras concurrentes que ocurren con lecturas concurrentes.
Sus ideas sobre esto son muy apreciadas.
Y más, tengo tres de esas tablas con cada 30 mil millones de filas que contienen diferentes tipos de objetos
Respuestas:
Si la consistencia eventual es aceptable y todas sus consultas son agregados, entonces quizás un sistema OLAP de baja latencia podría funcionar para usted. Su requisito suena un poco como una plataforma de negociación algorítmica. Este tipo de arquitectura a menudo se usa en sistemas de piso de operaciones que tienen el requisito de llevar a cabo cálculos de análisis estadísticos agregados en datos actualizados.
Si puede dividir sus datos por fecha y las filas antiguas no se actualizan, puede construir un sistema OLAP híbrido utilizando un servidor OLAP convencional como los servicios de análisis de Microsoft respaldados por una plataforma RDBMS ordinaria. Debería ser posible hacer frente a ~ 4 TB de datos y tanto SQL Server como SSAS harán clústeres de disco compartido. Sistemas OLAP similares (por ejemplo, Oracle / Hyperion Essbase) están disponibles en otros proveedores.
Los servidores OLAP funcionan mediante la persistencia de datos en una tienda nativa, junto con los agregados. La mayoría admitirá datos particionados. Además, la mayoría también funcionará en modo ROLAP, donde emiten consultas contra la base de datos subyacente. Lo importante a tener en cuenta es que la estrategia de almacenamiento se puede administrar por partición, y puede cambiar una partición de una a otra mediante programación,
En este modelo, los datos históricos se almacenan en particiones MOLAP con agregados de datos también persistentes. Si se puede satisfacer una consulta de los agregados, el servidor los usará. Los agregados se pueden ajustar para adaptarse a las consultas, y los agregados correctos reducirán drásticamente la cantidad de cómputo necesario para resolver la consulta. Son posibles consultas agregadas muy receptivas con este tipo de sistema.
Los datos en tiempo real se pueden implementar manteniendo una pequeña partición inicial, para el mes, día o incluso hora actuales si es necesario. El servidor OLAP emitirá consultas en la base de datos; Si esta partición es lo suficientemente pequeña, el DBMS podrá responder rápidamente. Un proceso regular crea nuevas particiones líderes y convierte períodos históricos cerrados a MOLAP. Las particiones más antiguas se pueden fusionar, lo que permite que los datos históricos se administren en cualquier grano deseado.
Los clientes que escriben en la base de datos simplemente escriben directamente el RDBMS subyacente. Si los datos históricos permanecen estáticos, solo se escribirán en la partición principal. 4TB es un volumen práctico para usar SSD si necesita un rendimiento adicional de DBMS. Incluso los proveedores convencionales tienen ofertas basadas en SSD con unidades SLC más rápidas como opción.
fuente