Extrema Sharding: Um banco de dados SQLite Per User

Question

Eu estou trabalhando em uma aplicação web que está em algum lugar entre um serviço de e-mail e uma rede social. Eu sinto que tem o potencial de crescer muito grande no futuro, por isso estou preocupado com a escalabilidade.

Em vez de usar um centralizado MySQL / InnoDB banco de dados e, em seguida, dividindo-o quando essa hora chegar, eu decidi criar um banco de dados SQLite separado para cada usuário ativo:. Um usuário ativo por 'caco'

Dessa forma, o backup do banco de dados seria tão fácil como copiar de cada usuário pequena arquivo de banco de dados para um local remoto uma vez por dia.

Scaling up será tão fácil como adicionar discos rígidos extras para armazenar os novos arquivos.

Quando o aplicativo cresce além de um único servidor que pode ligar os servidores juntos no nível do sistema de arquivos usando GlusterFS e executar o aplicativo inalterada, ou equipamento de um sistema de proxy SQLite simples que permitirá que cada servidor para manipular arquivos SQLite em servidores adjacentes.

problemas de simultaneidade será mínimo porque cada solicitação HTTP só vai tocar um ou dois bancos de dados arquivos de uma vez, fora dos milhares, e SQLite apenas blocos em lê qualquer maneira.

Eu estou apostando que esta abordagem permitirá que meu aplicativo para dimensionar graciosamente e lotes de apoio de fresco e única apresenta. Estou apostando errado? Estou faltando alguma coisa?

Atualizar eu decidi ir com uma solução menos radical, que está funcionando bem até agora. Eu estou usando um número fixo de cacos - 256 bases de dados SQLite, para ser preciso. Cada utilizador é atribuído e ligado a um fragmento aleatório por uma função hash simples.

A maioria dos recursos do meu aplicativo requer acesso a apenas um ou dois pedaços por solicitação, mas não há um em especial que requer a execução de uma consulta simples em 10 a 100 fragmentos diferentes de 256, dependendo do usuário. Testes indicam que levaria cerca de 0,02 segundos, ou menos, se todos os dados são armazenados em cache na RAM. Eu acho que eu posso viver com isso!

Update 2.0 I portado o aplicativo para MySQL / InnoDB e foi capaz de obter sobre o mesmo desempenho para pedidos regulares, mas para que um pedido que requer curta caco, InnoDB é 4-5 vezes mais rápido . Por esta razão, e outra razão, eu estou soltando essa arquitetura, mas espero que alguém em algum lugar encontra um uso para ele ... obrigado.

Answer 1

O local onde este irá falhar é se você tem que fazer o que é chamado "pé caco" - que é descobrir todos os dados através de um monte de diferentes usuários. Esse tipo particular de "consulta" terá que ser feito por meio de programação, pedindo a cada um dos bancos de dados SQLite, por sua vez - e muito provavelmente será o aspecto mais lento do seu site. É um problema comum em qualquer sistema onde os dados foram "Sharded" em bases de dados separadas.

Se todo o dos dados é auto-suficiente para o usuário, então isso deve escalar muito bem - a chave para tornar este um projeto eficaz é saber como os dados são provavelmente vai ser usado e se os dados de uma pessoa estará interagindo com dados de outro (no seu contexto).

Você também pode precisar tomar cuidado com os recursos do sistema de arquivos - SQLite é grande, impressionante, rápido, etc - mas você começa alguns cache e escrever benefícios ao usar um "banco de dados padrão" (ou seja, MySQL, PostgreSQL, etc), porque de como eles são projetados. Em seu projeto proposto, você estará perdendo um pouco disso.

Answer 2

Parece-me que um pesadelo de manutenção. O que acontece quando o esquema muda em todos os bancos de dados?

Answer 3

Um possível problema é que ter uma base de dados para cada usuário vai usar o espaço em disco e memória RAM muito ineficiente, e como a base de usuários cresce a vantagem de usar um motor de banco de dados leve e rápido será perdido completamente.

Uma possível solução para este problema é criar " minishards ", que consiste de talvez 1.024 bancos de dados SQLite abrigando até 100 usuários a cada . Este será mais eficiente do que o DB por abordagem usuário, porque os dados são embalados de forma mais eficiente. E mais leve do que a abordagem do servidor de banco de dados InnoDB, porque nós estamos usando SQLite.

A concorrência também vai ser muito bom, mas as consultas serão menos elegante (yuckiness shard_id). O que você acha?

Answer 4

http://freshmeat.net/projects/sphivedb

SPHiveDB é um servidor para banco de dados SQLite. Ele usa JSON-RPC sobre HTTP para expor uma interface de rede para usar banco de dados SQLite. Ele suporta combinando vários bancos de dados SQLite em um arquivo. Ele também suporta o uso de vários arquivos. Ele é projetado para o esquema de extrema fragmentação -. Um banco de dados SQLite por usuário

Answer 5

Se você está criando um banco de dados separado para cada usuário, parece que você não está configurando relações ... então por que usar um banco de dados relacional em tudo?

Answer 6

Eu estou considerando essa mesma arquitetura que eu basicamente queria usar os bancos de dados SqlLite lado do servidor como backup e sincronização de cópia para os clientes. Minha idéia para consulta através de todos os dados é usar Sphinx por pesquisa de texto completo e executar tarefas do Hadoop de lixeiras planas de todos os dados para Scribe e, em seguida, expor os resultados como webservies. Este post me dá alguma pausa para pensar no entanto, então eu espero que as pessoas vão continuar a responder com a sua opinião.

Answer 7

Se os seus dados é tão fácil de caco, porque não basta usar um motor de banco de dados padrão, e se você escala grande o suficiente para que a DB se torna o gargalo, estilhaço o banco de dados, com diferentes usuários em diferentes instâncias? O efeito é o mesmo, mas você não está usando um grande número de pequenos bancos de dados pequenos.

Na realidade, você provavelmente tem pelo menos alguns dados compartilhados que não pertence a qualquer único usuário, e você provavelmente frequentemente precisam acessar os dados por mais de um usuário. Isso causará problemas com qualquer um dos sistemas, no entanto.

Answer 8

Ter um banco de dados por usuário seria torná-la realmente fácil para restaurar dados de usuários individuais, é claro, mas como @ John disse, alterações de esquema exigiria algum trabalho.

Não o suficiente para torná-lo difícil, mas o suficiente para torná-lo não trivial.