"Agora - como você resolveria o problema descrito?"
Com arquivos planos simples.
Aqui está o porquê
Você tem 2.000.000 entidades. Partição baseada no número da entidade:
level1= entity/10000
level2= (entity/100)%100
level3= entity%100
Cada arquivo de dados é
level1/level2/level3/batch_of_data Você pode ler todos os arquivos em uma determinada parte do diretório para retornar amostras para processamento.
Se alguém quiser um banco de dados relacional, carregue arquivos para um determinado entity_id em um banco de dados para uso.
Editar Nos números do dia.
-
Odate_id/entity_idregra de exclusividade é não algo que deve ser tratado. É (a) imposto trivialmente aos nomes dos arquivos e (b) irrelevante para consulta.
-
Odate_id"rollover" não significa nada -- não há consulta, então não há necessidade de renomear nada. Odate_iddeve simplesmente crescer sem limites a partir da data da época. Se você deseja limpar dados antigos, exclua os arquivos antigos.
Como nenhuma consulta depende de
date_id , nada precisa ser feito com ele. Pode ser o nome do arquivo para tudo o que importa. Para incluir o
date_id no conjunto de resultados, escreva-o no arquivo com os outros quatro atributos que estão em cada linha do arquivo. Editar ao abrir/fechar
Para escrever, você deve deixar o(s) arquivo(s) aberto(s). Você faz limpezas periódicas (ou fecha/reabre) para garantir que as coisas realmente vão para o disco.
Você tem duas opções para a arquitetura do seu escritor.
-
Tenha um único processo de "gravador" que consolide os dados das várias fontes. Isso é útil se as consultas forem relativamente frequentes. Você paga para mesclar os dados no momento da gravação.
-
Tenha vários arquivos abertos simultaneamente para gravação. Ao consultar, mescle esses arquivos em um único resultado. Isso é útil porque as consultas são relativamente raras. Você paga para mesclar os dados no momento da consulta.
