Armazenando centenas de milhões de registros

Armazenando centenas de milhões de registros

Minha empresa adquirirá um conjunto de dados composto por aproximadamente 200-300 milhões de registros. O material de origem é csv e tem cerca de 150 GB descompactado. Precisaríamos realizar um carregamento inicial dos dados e depois atualizar aproximadamente 1% dos registros diariamente. Adoraríamos poder manter o histórico de cada registro também.

Atualmente usamos MySQL e parece que algumas pessoas estão usando MySQL e PostgreSQL para bancos de dados desse tamanho, mas não vejo muitas informações concretas sobre suas experiências.

Definitivamente poderíamos escapar sem normalizar os dados e posso imaginar a distribuição das informações por vários servidores. Que tal o MongoDB ou algum outro armazenamento de dados não tradicional?

Alguém tem alguma opinião sobre a viabilidade desse tipo de empreendimento? Agradeço qualquer ajuda que você possa dar.

Responder1

Minha experiência em conjuntos de dados desse tamanho é limitada ao MSSQL, mas ele definitivamente pode lidar com dados desse tamanho.

Minha primeira preocupação é o tamanho dos dados. 300 milhões de registros a 150 GB equivalem a cerca de 500 KB por linha - e isso é uma grande linha. Uma briga muito, muito grande. Se você puder normalizar para a terceira forma normal, isso poderá ajudar drasticamente (assumindo que haja dados que possam ser normalizados). Se você não vai normalizar (e apenas ter uma tabela única e enorme), então um mecanismo que suporte ISAM será mais rápido que um RDBMS, então MySQL no modo ISAM é a escolha óbvia em vez de MSSQL (desculpe, eu não não tenho nenhuma experiência com Postgre ou Mongo)

Dito isto, o MSSQL pode lidar com uma tabela desse tamanho sem problemas. Ele pode particionar os dados para que diferentes partes residam em discos diferentes, para que você possa manter 1% dos dados atualizados em um disco rápido e manter o restante em um disco mais lento se o orçamento for uma preocupação. Se o seu SGBD preferido suportar isso, então pode ser uma boa opção.

Apenas para referência, certa vez gerenciei um banco de dados que tinha cerca de 200 milhões de linhas em uma única tabela (mas a tabela tinha apenas 20 Gb de tamanho) e com alguma indexação inteligente os tempos de consulta ainda eram medidos em milissegundos. Isso foi normalizado para a terceira forma normal, então havia muitos LOJs para recuperar dados associados também.

Responder2

A maioria dos bancos de dados pode gerenciar facilmente o armazenamento de grandes quantidades; isso realmente depende do que você deseja fazer com os dados depois de carregá-los. É transacional, por isso será consultado e atualizado com frequência? Ou é mais para gerar relatórios apenas com novas informações que chegam todos os dias do sistema transacional?

informação relacionada