Como gerenciar milhões de usuários?

Estou prestes a lançar algo realmente grande. Preciso preparar meu servidor e banco de dados.

Gostaria de agrupar cada conjunto de 100.000 usuários em tabelas de usuários separadas, mas não sei como associar um usuário tentando fazer logon na tabela de usuário apropriada.

Por exemplo, como eu saberia que o usuário jay@mail.comestá relacionado à tabela de usuários nº 36?

Seria o mesmo ter 10 milhões de usuários em uma tabela de usuários ou 100 de 100.000?

Como o Facebook? Não acredito que eles teriam uma tabela de usuário global com 950 milhões de entradas.

Você não terá um bilhão de usuários amanhã e o MySQL pode lidar com vários milhões de linhas sem nenhum problema. Eu tenho 5 milhões de usuários na minha tabela de usuários e confie em mim, não está nem no meu radar de coisas para me preocupar.

Não se preocupe com o sharding até precisar fazê-lo. Você está tentando otimizar prematuramente um problema que pode ou não existir e, no processo, você prejudicará gravemente a taxa em que poderá inovar. Seja rápido no lançamento e encontre os problemas que surgirem. Você não pode prever com antecedência quais serão seus desafios de dimensionamento.

Quando e se você atingir essa escala, terá bastante dinheiro e recursos para enfrentar esse tipo de problema.

Não tenho certeza se consultores externos seriam o melhor suporte para sua empresa se você deseja lidar com conjuntos de dados muito grandes e precisa começar do zero. Por favor, não me interpretem mal, mas se alguém estragar um projeto com tantos clientes, isso terá um impacto de PR na sua empresa.

Em relação às tuplas de 10 milhões em uma tabela, se você tiver uma boa indexação, tudo ficará bem. Precisamos armazenar várias tuplas de 100M em uma tabela aqui (itens vendidos) que funcionem bem em um grande oráculo 11g

Aqui está uma publicação de 2010 com um mapa do facebooks db design: Facebook database design

Você pode ler a documentação do mysql sobre tipos de partição como este: Documentação do MySQL: Particionando

O MySQL suporta estes tipos:

Particionamento RANGE . Esse tipo de particionamento atribui linhas a partições com base nos valores das colunas que estão dentro de um determinado intervalo. Consulte a Seção 18.2.1, “Particionamento de intervalos”.

LISTA particionamento. Semelhante ao particionamento por RANGE, exceto que a partição é selecionada com base em colunas correspondentes a um de um conjunto de valores discretos. Consulte a Seção 18.2.2, “Particionando na lista”.

Particionamento HASH . Com esse tipo de particionamento, uma partição é selecionada com base no valor retornado por uma expressão definida pelo usuário que opera nos valores da coluna nas linhas a serem inseridas na tabela. A função pode consistir em qualquer expressão válida no MySQL que produz um valor inteiro não negativo. Uma extensão para esse tipo, LINEAR HASH, também está disponível. Consulte a Seção 18.2.3, “Particionamento HASH”.

Particionamento de chaves . Esse tipo de particionamento é semelhante ao particionamento pelo HASH, exceto que apenas uma ou mais colunas a serem avaliadas são fornecidas, e o servidor MySQL fornece sua própria função de hash. Essas colunas podem conter valores diferentes de números inteiros, pois a função de hash fornecida pelo MySQL garante um resultado inteiro, independentemente do tipo de dados da coluna. Uma extensão para esse tipo, LINEAR KEY, também está disponível. Consulte a Seção 18.2.4, “Particionamento de chaves”.

Primeiro de tudo, não separe os usuários em tabelas separadas. Isso tornará as coisas complexas e sem sentido. Bancos de dados como MySQL e outros podem funcionar com bancos de dados de milhões de registros na mesma tabela sem nenhum problema (com as PRIMARY KEYS configuradas). Use o campo-chave exclusivo AUTO_INCREMENT AND PRIMARY do banco de dados para cada usuário (na tabela principal do usuário), para que cada registro seja exclusivo (UID). Em outras tabelas, você está fazendo referência usando esse ID exclusivo. Em seguida, verifique se em todas as tabelas definidas como PRIMARY KEY, isso acelerará o processamento das informações no servidor de banco de dados. Você pode aprender com o Drupal CMS como está armazenando as informações do usuário. Testado em mais de 10 anos por milhões de usuários e empresas muito grandes (usadas por grandes empresas de mídia, governo e até os maiores bancos do mundo). Em www.drupal. org, você encontrará mais de 1,6 milhão de páginas (nós) armazenadas na mesma tabela e possui mais de um milhão de visitantes únicos por mês, e o site funciona sem falhas. Tudo se resume à otimização e configuração adequadas.

Após 10 milhões de registros, se você não estiver satisfeito com o desempenho (após a otimização adequada e as alterações na configuração do banco de dados), poderá decidir se realmente deseja separar os usuários por tabelas diferentes. Assim, você pode realmente estender a funcionalidade adicionando uma nova tabela que possui informações sobre onde os registros dos usuários são mantidos: UID e table_name. Então, em qualquer outra tabela solicite essas informações, esta tabela procurará a tabela correta. Mas eu realmente recomendo que você tenha uma tabela grande para os usuários, a menos que você tenha mais de 10 a 100 milhões de registros. Mas isso não melhorará muito o desempenho (os bancos de dados são projetados para lidar com grandes dados). É melhor manter as informações simples. Normalmente, as empresas apenas decidem por outro servidor de banco de dados (mestre e escravos) e outro, então eles ' está trabalhando em conjunto com a funcionalidade de balanceamento de carga. Se você tiver esses 10 milhões de usuários, poderá pagar por outro servidor db, certo?

Veja o exemplo do useresquema da tabela no arquivo user.install .

Como as outras respostas sugerem, não é uma boa ideia dividir os usuários em várias tabelas. A maioria dos bancos de dados com índices no ID do usuário pode lidar com milhões de linhas. No entanto, a latência por consulta pode aumentar dependendo do número total de entradas no índice. Desde que o conjunto de dados seja pequeno, você pode gerenciar com uma única tabela em bancos de dados normais.

Vou tentar lançar uma idéia diferente também para sua consideração futura se você crescer muito além de um milhão de registros. Com um número tão grande de clientes, você não deseja nenhum tempo de inatividade, etc. Portanto, existem vários bancos de dados nosql que você pode querer olhar. Eles farão o sharding para você, em vez de você gerenciar o sharding a partir do aplicativo. Eles também fornecerão redundância de dados e, portanto, mais tempo de atividade. O Facebook e todos usam muito o memcache etc. para o cache. Mas não tenho certeza do que eles usam para sua loja permanente.

Uma coisa importante que você deve observar é que você não pode fazer associações, etc., com os bancos de dados nosql. Portanto, planeje seu caso de uso e decida. Se junções e transações com vários registros são uma necessidade para você, os bancos de dados nosql não são para você.

por que não dividir com base no intervalo alfabético? Se você tiver milhões de usuários, crie uma tabela separada para cada letra ou par de letras (tabela 'a' para usuários com nome de usuário começando com 'a'). Inicialmente, haverá muita sobrecarga, mas como você espera um grande banco de dados e deseja distinguir qual tabela deve ser usada para um usuário específico - acho que a ordem alfabética é a escolha óbvia e mais fácil.