Sistema de armazenamento altamente simultâneo

Imagine que seu requisito é que você tenha 3 tabelas enormes (dados estruturados) com, digamos, 30 bilhões de linhas em cada (tamanho total de 4 TB) e seus muitos usuários simultâneos (que são threads de sistemas paralelos em máquinas de LAN remotas) precisarão ler uma parte de os dados através de suas consultas SELELCT WHERE GROUPBY e altamente simultâneos, digamos 10.000 leituras simultâneas ao mesmo tempo e também os usuários precisam inserir (sem atualização) dados nessas tabelas altamente simultâneos, como 2000 gravadores simultâneos (em toda a rede LAN do datacenter) . Os usuários gostariam de ler e inserir o mais rápido possível neste armazenamento, onde cada leitura e gravação ocorrerá de 1 a 1 segundo.

Quais tecnologias você recomenda para atender a esse requisito? Existe algum armazenamento de dados ou armazenamento de valores-chave que possa fazer isso? Nuvem NÃO é uma opção.

Alguns esclarecimentos:

Os usuários NÃO precisam ver os dados imediatamente e a consistência eventual é aceitável. Os dados são acessados ​​por qualquer driver que o armazenamento possa fornecer e os usuários são novamente apenas threads executados em máquinas remotas do data center. As consultas são principalmente como SELECT WHERE GROUPBY.

Os dados estão em formato de tabela e cada linha tem cerca de 60 bytes.

Nenhuma opção de nuvem em que não posso usar o DynamoDB ou soluções semelhantes. Eu tenho que poder hospedá-lo internamente no data center.

Todos os dados das tabelas podem ser lidos o tempo todo e o padrão de uso é imprevisível. Não há associação ou consulta super longa. Não é necessário DR, mas é necessário um HA razoável, mas não precisa ser sofisticado. Todo leitor está obtendo um lote de linhas com base na cláusula where e nas linhas realmente não estão relacionadas. Provavelmente, podemos ter um comprimento fixo para cada linha, mas espero que a camada de armazenamento se preocupe com isso.

Além disso, minha maior preocupação são todas as gravações simultâneas que estão acontecendo com leituras simultâneas.

Suas idéias sobre isso são muito apreciadas.

E mais, tenho três dessas tabelas com cada 30 bilhões de linhas segurando diferentes tipos de objetos

Se a consistência eventual for aceitável e todas as suas consultas forem agregadas, talvez um sistema OLAP de baixa latência possa funcionar para você. Sua exigência parece um pouco com uma plataforma de negociação algorítmica. Esse tipo de arquitetura é frequentemente usado em sistemas de pregões que exigem a execução de cálculos de análises estatísticas agregadas em dados atualizados.

Se você puder particionar seus dados por data e as linhas antigas não forem atualizadas, poderá criar um sistema OLAP híbrido usando um servidor OLAP convencional, como o Microsoft Analysis Services, apoiado por uma plataforma RDBMS comum. Deve ser possível fazer isso com ~ 4 TB de dados e o SQL Server e o SSAS farão clusters de disco compartilhado. Sistemas OLAP similares (por exemplo, Oracle / Hyperion Essbase) estão disponíveis em outros fornecedores.

Os servidores OLAP funcionam persistindo os dados em um armazenamento nativo, juntamente com os agregados. A maioria suportará dados particionados. Além disso, a maioria também funcionará no modo ROLAP, onde eles emitem consultas no banco de dados subjacente. O importante a ser observado é que a estratégia de armazenamento pode ser gerenciada por partição e você pode alternar uma partição de uma para outra programaticamente,

Nesse modelo, os dados históricos são armazenados em partições MOLAP com agregados dos dados também persistidos. Se uma consulta puder ser satisfeita a partir dos agregados, o servidor os usará. Os agregados podem ser ajustados para se adequar às consultas, e os agregados corretos reduzirão drasticamente a quantidade de computação necessária para resolver a consulta. Consultas agregadas muito responsivas são possíveis com esse tipo de sistema.

Os dados em tempo real podem ser implementados mantendo uma pequena partição principal - para o mês, dia ou mesmo hora atual, se necessário. O servidor OLAP emitirá consultas no banco de dados; se essa partição for pequena o suficiente, o DBMS poderá responder rapidamente. Um processo regular cria novas partições principais e converte períodos históricos fechados em MOLAP. Partições mais antigas podem ser mescladas, permitindo que os dados históricos sejam gerenciados em qualquer granulação desejada.

Os clientes que estão gravando no banco de dados simplesmente escrevem diretamente o RDBMS subjacente. Se os dados históricos permanecerem estáticos, eles serão gravados apenas na partição principal. 4 TB é um volume prático para usar SSDs, se você precisar de desempenho extra no DBMS. Até os principais fornecedores têm ofertas baseadas em SSD, com unidades SLC mais rápidas como opção.