Caso de uso: uma medição cria um determinado número de imagens. Para cada imagem precisamos armazenar um pequeno conjunto de indicadores de qualidade (floats, doubles) junto com um inteiro de imagem [1 ...N], um timestamp e um ou dois valores de chave estrangeira. Isso deve ser plotado em "tempo real" em um aplicativo da Web (PHP) para que os usuários avaliem.
Cada cliente da Web pesquisa o banco de dados a cada 5 segundos. Armazenamento + recuperação de cada conjunto de indicadores de qualidade deve, idealmente, levar < 2s (aproximadamente). Na pior das hipóteses, pode haver cerca de 30 clientes web simultâneos pesquisando e cerca de 10 medições podem ser gravadas simultaneamente, levando a rajadas de gravação de aprox. 1000 conjuntos de indicadores de qualidade por segundo.
Em uma linguagem de programação, esse tipo de dado provavelmente seria armazenado em arrays ou listas. Como não tenho conhecimento de nada parecido no mundo MariaDB/MySQL estou apenas usando uma tabela normal do InnoDB com uma coluna para cada um dos valores citados acima. Isso já tem mais de 90 milhões de linhas e deve crescer mais rapidamente nos próximos meses.
O InnoDB em geral é o melhor mecanismo de armazenamento para isso ou devo considerar outros? É uma prática recomendada arquivar os dados depois de um tempo, talvez depois que todas as imagens das medições forem processadas? Isso ajudaria a habilitar a compactação ou isso teria impactos muito negativos no desempenho?
Com apenas MySQL/MariaDB, eu empregaria:
FOREIGN KEYSpor causa da sobrecarga extra. (Em vez disso, eu depuraria o SQL.)AUTO_INCREMENTse alguma outra coluna for exclusiva.SPATIALé uma abordagem; aqui está outro: http://mysql.rjweb.org/doc.php/latlngSeu último parágrafo joga na pia da cozinha de perguntas (Toku, MyRocks, arquivo, compressão, tabela de histórico). Estou surpreso que a postagem não tenha sido morta por ser "muito ampla". Por favor, explique como são seus dados e consultas; caso contrário, tudo o que podemos fazer é jogar uma pia de cozinha cheia de soluções.
Você diz "tempo real", mas precisa de "milhares/seg". Você pode permitir um atraso de 1 minuto em tempo real? 1 segundo? Você não pode obter 1ms; 1s será difícil de alcançar. Quanto tempo dura uma explosão? O que é uma explosão por minuto? 1 K/s provavelmente será derramado nos próximos segundos. 6K/minuto não é muito problema.
Quantos clientes estão armazenando dados? Algumas soluções funcionam bem com um único cliente; soluções diferentes são necessárias para vários clientes.
Tenha em mente que os benchmarks são ajustados para mostrar uma coisa e raramente correspondem à vida real.
Existem algumas grandes questões lá que provavelmente precisam de um exame mais detalhado do que pode ser alcançado aqui, pois há tantas dependências (perceba que você sabe disso!). Há vários conjuntos de slides de apresentações nas páginas Percona Live e Percona Live Europe sobre séries temporais que podem ajudá-lo a avançar mais. Por exemplo, sobre como usar o ClickHouse do Yandex
https://www.percona.com/live/17/program/schedule/time-series
https://www.percona.com/live/e17/program-open-source-databases
Você também pode achar algumas das postagens do blog interessantes. Este analisa TokuDB versus InnoDB para um benchmark de série temporal.
https://www.percona.com/blog/2013/09/05/tokudb-vs-innodb-timeseries-insert-benchmark/
Considerando que este analisa MongoDB e TokuMX https://www.percona.com/blog/2015/05/26/storing-time-series-data-with-mongodb-and-tokumx/
Espero que estes ajudem.