Sistema de almacenamiento altamente concurrente


12

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


define la nube porque lo que la mayoría de las personas, dicen el 99% de la población general y el 100% de las personas de marketing llaman nube, es solo un clúster que alguien más mantiene.

Es decir, no puedo usar DynamoDB o alguna tecnología que solo esté disponible en una nube pública como Amazon o Azure, etc.
iCode

Respuestas:


6

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.


Gracias por su respuesta. Estás en lo correcto. Mi problema es similar a la plataforma de negociación algorítmica pero también diferente. Hemos probado la ruta RDBMS y no pudo escalar. Necesito un almacenamiento que pueda escalar y no tenga la complejidad de los sistemas OLAP ya que nuestro tamaño de datos está creciendo y una vez que obtengamos más TB en tres tablas, RDBMS creará muchos bloqueos y problemas similares. Espero que una opción nosql pueda satisfacer tales requisitos. ¿Alguna idea sobre eso?
iCode

@MDotnet Su expectativa / requerimiento de una solución simple para un usuario concurrente de 12k, un problema de 4TB puede ser poco realista. Usted menciona que miró los enfoques RDBMS y no se ajustó; 1) puede agregar los detalles de esto a su Q 2) Esta respuesta aboga por un enfoque híbrido ROLAP / MOLAP, no una base de datos relacional pura.
Mark Storey-Smith

No soy un DBA y creo que "conducir por votos positivos" es malo para la mayoría de los sitios especializados, pero no me importa, esta respuesta es demasiado buena para un solo voto positivo. +1
psr
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.