Quais são os prós e contras desses mecanismos MySQL para OLTP - XtraDB, PBXT ou TokuDB?

Question

Estou trabalhando em um site social com uma divisão aproximada de leitura / gravação de 90/10. Tentando decidir sobre um mecanismo MySQL. Os que me interessam são:

1. XtraDB
2. PBXT
3. TokuDB

Quais são os prós e contras deles para o meu caso de uso?

Algumas perguntas específicas:

• O PBXT usa uma estrutura baseada em log que evita gravações duplas. Parece muito elegante, mas o benchmark que vi não mostra nenhuma / muita vantagem sobre o XtraDB. Você tem alguma experiência com o PBXT / XtraDB que pode compartilhar?

• O TokuDB soa MUITO interessante. Mas todos os benchmarks que eu vi são sobre inserções em massa single-threaded - inserindo 100M linhas, por exemplo. isso não é muito relevante para o OLTP. E quanto ao seu desempenho com um grande número de threads simultâneos escrevendo e lendo ao mesmo tempo em execução em vários núcleos? Alguém já tentou isso?

Answer 1

Re: PBXT vs XtraDB (InnoDB)

Fiz essa pergunta diretamente a Paul McCullagh. Você pode ler a resposta dele aqui:

link

Parafraseando: o PBXT é um mecanismo de OLTP genérico, portanto, ele se sobrepõe consideravelmente ao InnoDB. A maioria dos 'casos de uso melhor' diretos ainda não são conhecidos.

Re: TokuDB vs XtraDB (InnoDB)

Acho que isso é um pouco diferente. Embora o TokuDB tenha algumas propriedades que podem ser boas para o OLTP, ele realmente brilha:

a) Quando você está lidando com tantos dados, suas inserções diminuem a velocidade de seus índices não mais se encaixam na memória (um problema 'clássico' de B-Tree para o qual o TokuDB não sofre).

b) Quando você precisa ter muitos índices ad hoc nos dados.

Vadim fala sobre isso aqui: link

-

A partir de sua descrição, vou talvez supor que o XtraDB e o PBXT são as escolhas mais óbvias. Ambos irão funcionar. Em favor do XtraDB é que já existe há mais tempo.

(Disclaimer: Eu trabalho para Percona, autores do XtraDB).