Qual melhor forma de trabalhar com banco de dados gigante?

Kevin969
(usa Ubuntu)

Enviado em 12/04/2016 - 15:53h

Boa tarde,

Na empresa onde estou, estou criando um sistema do zero. Mas estou com um problema, o banco vai receber bilhões de registros, pois temos vários clientes e eles utilizam o sistema o dia todo a todo momento. Qual seria a melhor forma de encarar isto? Registrar todos os clientes no mesmo banco e facilitar alterações na estrutura do banco ou criar uma nova database para cada cliente utilizar ela e otimizar a velocidade e tornar mais fácil validar os dados que estão na mesma?

Buckminster
(usa Debian)

Enviado em 12/04/2016 - 16:36h

Porque não usa o PostgreSQL?

Ele se comporta melhor com bilhões de dados.

E quanto à estrutura de dados, digo por experiência, as operações no PostgreSQL tem melhor desempenho quando feitas em menos tabelas. Por exemplo, uma consulta em uma única tabela com 50 campos é muito mais rápida do que uma consulta feita em 5 tabelas com 10 campos.
É lógico que nisso tudo aí entra o poder de processamento da tua máquina.

Veja aqui os limites do PostgreSQL:

http://www.postgresql.org/about/

Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited

Tamanho Máximo do Banco de Dados Ilimitado
Tamanho máximo de uma Tabela 32 TB
Tamanho Máximo de uma Linha 1.6 TB
Tamanho Máximo de um Campo 1 GB
Máximo de Linhas por Tabela Ilimitado
Máximo de Colunas por Tabela 250–1600 dependendo do tipo de coluna
Máximo de Índices por Tabela Ilimitado

Veja que uma tabela com 250 colunas (não sendo várias do tipo blob) é fichinha para o Postgres.

https://www.postgresql.org.br/sobre

O MySQL tem melhor desempenho quando trabalha com bancos não muito grandes.
Acredito que no teu caso, em sendo bilhões de dados mesmo, o PostgreSQL seria a melhor escolha (ou o Oracle, se tiver como pagar).

textmode
(usa Slackware)

Enviado em 12/04/2016 - 16:56h

Pense também em backup/restore. Se tudo estiver numa única tabela e um cliente
precisa fazer restore, será que a operação vai parar (ou atrasar) todos os
clientes? Além do mais, criar mais índices para clientes mais ativos e por
vezes, "desativar" tabelas de clientes que deixaram de existir, ajuda?

Eu recomendaria uma tabela para cada cliente, cada um com suas otimizações
e regras de backup distintas.

Buckminster
(usa Debian)

Enviado em 12/04/2016 - 16:58h

Bem lembrado.

Quantas colunas terá cada tabela se for uma tabela para cada cliente?

alastori
(usa Outra)

Enviado em 13/04/2016 - 10:31h

Olá! Sua pergunta não tem uma resposta simples, pois há diversas formas de fazer isso. O assunto que você pode querer se aprofundar é "escalabilidade".
Há diversas arquiteturas de referência que você pode seguir, tudo vai depender dos seus requisitos. Dê uma olhada neste artigo: http://www.infoq.com/news/2013/03/MySQL-Reference-Architectures
Para escolher a melhor opção de arquitetura, você deve começar estimando sua carga de dados com certo nível de detalhamento. Por exemplo:
- qual o volume de escritas na base por segundo em horários de pico;
- qual o volume de leituras na base por segundo em horários de pico;
- qual o volume de conexões simultâneas com o banco;
- os dados crescerão infinitamente ou haverá rotinas de consolidação/arquivamento.

Como base de comparação, é comum ver servidores commodity com 3000 Transações por Segundo e bases de 2-3TB.

Se seu sistema for maior que isso é melhor pensar em estratégias de escalabilidade horizontal. Isso vai envolver separar leituras de escritas (read-write split), separar módulos da aplicação em bases distintas (particionamento lógico) ou mesmo fragmentar os seus dados em servidores diferentes (data sharding).

Uma forma de separar na aplicação as leituras das escritas, já que você está no início do projeto, é implementar no design da aplicação o pattern CQRS (Command Query Responsibility Segregation) http://martinfowler.com/bliki/CQRS.html .

Enfim, há muitas possibilidades... Boa sorte!