web-dev-qa-db-fra.com

Quelle est la solution optimale pour stocker des séries chronologiques en temps réel dans MariaDB / MySQL?

Cas d'utilisation: une mesure crée un nombre donné d'images. Pour chaque image, nous devons stocker un petit ensemble d'indicateurs de qualité (flottants, doubles) avec un entier d'image [1 ... N], un horodatage et une ou deux valeurs de clé étrangère. Cela devrait ensuite être tracé en "temps réel" dans une application Web (PHP) pour que les utilisateurs l'évaluent.

Chaque client Web interroge la base de données toutes les 5 secondes. Le stockage + la récupération de chaque ensemble d'indicateurs de qualité devrait idéalement prendre moins de 2 secondes (environ). Dans le pire des cas, il peut y avoir ~ 30 interrogations simultanées de clients Web et environ 10 mesures peuvent être écrites simultanément, conduisant à des rafales d'écriture d'env. 1000 ensembles d'indicateurs de qualité par seconde.

Dans un langage de programmation, ce type de données serait probablement stocké dans des tableaux ou des listes. Comme je ne suis pas au courant de quelque chose de similaire dans le monde MariaDB/MySQL, j'utilise simplement une table InnoDB régulière avec une colonne pour chacune des valeurs mentionnées ci-dessus. Cela compte déjà plus de 90 millions de lignes et devrait croître plus rapidement dans les prochains mois.

InnoDB est-il globalement le meilleur moteur de stockage pour cela, ou devrais-je en considérer d'autres? Est-il recommandé d'archiver les données après un certain temps, peut-être une fois que toutes les images des mesures ont été traitées? Cela aiderait-il à activer la compression, ou cela aurait-il des impacts très négatifs sur les performances?

mysqlmariadbpercona
4
dbdemon

Avec juste MySQL/MariaDB, j'emploierais:

  • Ingestion à grande vitesse: http://mysql.rjweb.org/doc.php/staging_table
  • Tableaux récapitulatifs (pour accélérer la récupération des données): http://mysql.rjweb.org/doc.php/summarytables
  • Je considérerais même ne pas stocker les données brutes; résumez plutôt les données, puis lancez-les. Si cela est pratique, cela évite la plupart des questions que vous posez.
  • (Si les données doivent être purgées): Suppression rapide des anciennes données: http://mysql.rjweb.org/doc.php/partitionmaint
  • J'éviterais FOREIGN KEYS en raison des frais généraux supplémentaires. (Au lieu de cela, je déboguerais le SQL.)
  • Je n'utiliserais pas les clés UUID; les performances dégénèrent terriblement dans d'énormes tables. ( http://mysql.rjweb.org/doc.php/uuid )
  • J'éviterais les index supplémentaires - N'utilisez pas AUTO_INCREMENT si une ou plusieurs autres colonnes sont uniques.
  • Vous mentionnez Spatial - Veuillez développer. Les recherches 2D sont délicates; SPATIAL est une approche; en voici un autre: http://mysql.rjweb.org/doc.php/latlng

Votre dernier paragraphe jette dans l'évier de la cuisine des questions (Toku, MyRocks, archive, compression, table d'historique). Je suis surpris que la publication n'ait pas été tuée pour avoir été "trop ​​large". Veuillez expliquer à quoi ressemblent vos données et vos requêtes; sinon, tout ce que nous pouvons faire, c'est jeter un évier de cuisine plein de solutions.

Vous dites "en temps réel", mais vous avez besoin de "milliers/sec". Pouvez-vous prévoir un délai d'une minute en temps réel? 1 seconde? Vous ne pouvez pas obtenir 1 ms; Les 1s seront difficiles à réaliser. Combien de temps dure une rafale? Qu'est-ce qu'une rafale par minute? 1K/sec se répandra probablement dans les prochaines secondes. 6K/minute n'est pas un problème.

Combien de clients stockent des données? Certaines solutions fonctionnent bien avec un seul client; différentes solutions sont nécessaires pour plusieurs clients.

Gardez à l'esprit que les repères sont réglés pour montrer une chose et correspondent rarement à la vie réelle.

6
Rick James

Il y a là de grandes questions qui nécessitent probablement un examen plus approfondi que ce qui peut être réalisé ici, car il y a tellement de dépendances (réalisez que vous le savez!). Il existe un certain nombre de diapositives de présentations sur les pages Percona Live et Percona Live Europe sur les séries chronologiques qui pourraient vous aider à avancer plus loin. Par exemple, sur l'utilisation de ClickHouse de Yandex

https://www.percona.com/live/17/program/schedule/time-series

https://www.percona.com/live/e17/program-open-source-databases

Vous pourriez également trouver certains des articles de blog intéressants. Celui-ci examine TokuDB par rapport à InnoDB pour une référence de série chronologique.

https://www.percona.com/blog/2013/09/05/tokudb-vs-innodb-timeseries-insert-benchmark/

Alors que celui-ci regarde MongoDB et TokuMX https://www.percona.com/blog/2015/05/26/storing-time-series-data-with-mongodb-and-tokumx/

J'espère que ces aides.

3
percona-lorraine