Ok, então esta será uma questão especulativa, principalmente orientada para o design e bastante longa. Eu pegaria um cuppa' covfefe , se eu fosse você.
Prefácio: Então, eu tenho pesquisado bancos de dados e queria um banco de dados (motor) realmente rápido ( como realmente muito ) com os seguintes itens obrigatórios ,
- Conformidade com ACID
- In-Memory-ish para IO extremamente rápido.
- Persistente ( bem... duh )
- Escalável como em cluster/master-slave/etc
- Alta Disponibilidade (HA)
- Substituição do MySQL Drop-In
- Código aberto
- Deve ser executado no servidor commodity (IYKWIM)
Então, a julgar pela minha lista otimista de requisitos, você já pularia para ....ummm
Tudo bem, tudo bem, piadas à parte, eu sei que se innodb_buffer_pool_sizefor ajustado corretamente, vai ficar sem memória na maioria das vezes, mas eu digo
Não está na memória yo!
Mas você diria Ei, seu pessoal de 2k18 já deve ter criado cerca de 100% em BDs de memória, certo? Umm... na verdade eles têm, mas cada um tem suas próprias vantagens.
VoltDB Community Edition Tudo parece bem até que você perceba que não é uma substituição fácil. Ele precisa de alguns procedimentos armazenados - comandos ish em java que exigem que você reescreva todo o seu aplicativo ou pelo menos o db layer/driver/etc do seu aplicativo php. Então? EMPECILHO!!!
MemSQL , Bem, isso parece um forte concorrente para o nosso concurso " Best OpenSource In-Mem Scalable SQL Acid DB de todos os tempos ". Apenas para, o memSQL Boss ser como...
Escusado será dizer que o memSQL precisa de pelo menos 4 núcleos e 8 GB de RAM no mínimo, e o recomendado é bastante insano em 4 núcleos e 32 GB por núcleo !!!! Além disso, a versão da comunidade do memSQL ( que, aliás, não é totalmente OpenSource!, é apenas gratuita ) não suporta alta disponibilidade, pois é um recurso pago. Também é NoSQL. Então? EMPECILHO!!!
- Todos os outros dbs NoSQLish, como membase, Redis, Memcached, etc, são praticamente descartados.
Então agora a minha ideia genial!!!
Eu queria saber se poderíamos executar um cluster XtraDB/Galera com todas as instâncias sendo executadas em um RAMDisc com instantâneos regulares?
Ele recebe todas as caixas de seleção marcadas.
Apenas me ouça, Primeiro me dirigindo ao elefante na sala, Nós sabemos que rodar mysql Dbs completo de RAMDiscs é bem umm... ousado, colocado da maneira mais educada possível. Então, o que acontece se o servidor travar/desligar/etc, perdermos um nó. Enquanto todo o nosso DB Cluster como um todo ainda está vivo e chutando a**. Tudo o que temos que implementar é inicializar o banco de dados a partir do último instantâneo e sincronizar de volta com o cluster no qual os clusters são muito bons, inerentemente!
OK, espreitadelas, não sejam salgados comigo, se virem uma falha na minha implementação, oriente-me.
OK, 3 nós Galera, com:
Notas:
(Editado para abordar comentários de @RickJames, além de um pouco mais sobre NDB Cluster e melhorias gerais.)
Existem vários problemas com o seu plano:
Se você deseja persistência, obviamente não pode usar um disco RAM para os arquivos de dados.
Se você planeja usar um disco de RAM para todos os arquivos de banco de dados (arquivos de dados de tabela, arquivos de log, arquivos temporários, ...), parece que você precisará de mais do que o dobro da quantidade de RAM exigida por um sistema de memória. único sistema de banco de dados, já que você está armazenando as próprias tabelas e seus arquivos de dados (que normalmente seriam persistidos no disco) na RAM.
Como você vai garantir que o disco RAM seja grande o suficiente para todos os casos de uso possíveis? Por exemplo, tabelas temporárias internas em disco podem ser criadas quando uma consulta é muito grande para ser tratada na memória. Portanto, se você usar um disco RAM como armazenamento em disco, corre o risco de ficar sem "disco", o que provavelmente terá algum efeito prejudicial. (E isso me leva a pensar que existem boas razões para o MemSQL ter requisitos de RAM tão grandes ...)
Talvez haja uma maneira de configurar seu disco de armazenamento / RAM para que parte do armazenamento fique no disco RAM (a parte que é usada primeiro / preferida) e a outra parte fique no disco real?
Dito isso, há casos em que o InnoDB criará tabelas temporárias no disco, mesmo que a consulta possa ter sido tratada na memória. Veja 8.4.4 Uso de Tabela Temporária Interna no MySQL para detalhes. Estes são casos em que um disco RAM talvez possa ter sido útil. Aqui está uma entrada de blog (de 2012) sobre como colocar o MySQL tmpdir em RAM-disk .
No entanto, qualquer RAM usada para o tmpdir em uma solução de disco RAM é uma RAM que poderia ter sido usada para o pool de buffers InnoDB muito importante. Portanto, certifique-se de ter um pool de buffers grande o suficiente para seu conjunto de trabalho de dados antes de considerar o uso de qualquer RAM em um disco RAM.
Supondo que você coloque os arquivos de dados das tabelas no disco RAM e planeje fazer um instantâneo, você também precisará tomar medidas para garantir que esteja obtendo um backup consistente pontual. Esses tipos de etapas tornarão o disco RAM mais lento.
Então, alternativamente, em vez de usar um disco RAM, você pode usar o Galera como está, mas tome todas as precauções possíveis para evitar a criação de tabelas temporárias internas no disco. Obviamente, você também deve usar SSD em vez de discos giratórios.
Outra tecnologia a ser considerada pode ser o MySQL NDB Cluster :
O NDB Cluster realmente é bastante rápido, com 200 milhões de QPS (NoSQL) relatados em fevereiro de 2015, consulte MySQL Cluster Benchmarks . O que me preocupa é que eles ainda estão usando esses benchmarks agora em 2018, como se nenhum progresso tivesse sido feito desde 2015. Também tenho a sensação de que, por qualquer motivo, a popularidade do NDB Cluster está diminuindo em comparação com o Galera e outras soluções . (Veja, por exemplo, as estatísticas das várias tags aqui no DBA.SE.)