MySQL Cluster gère une base de données de téraoctets

Je dois trouver des solutions pour fournir une base de données MySQL capable de traiter des volumes de données de l'ordre du téraoctet et être hautement disponible (cinq neuf). Chaque ligne de base de données est susceptible d'avoir un horodatage et jusqu'à 30 valeurs flottantes. La charge de travail attendue est de 2500 insertions/sec. Les requêtes sont susceptibles d'être moins fréquentes mais peuvent être volumineuses (impliquant peut-être 100 Go de données), mais n'impliquant probablement que des tables uniques.MySQL Cluster gère une base de données de téraoctets

J'ai regardé MySQL Cluster étant donné que c'est leur offre HA. En raison du volume de données, je devrais utiliser le stockage sur disque. De manière réaliste, je pense que seuls les horodatages pourraient être conservés en mémoire et toutes les autres données devraient être stockées sur le disque.

Quelqu'un at-il l'expérience de l'utilisation de MySQL Cluster sur une base de données de cette taille? Est-ce même viable? Comment le stockage sur disque affecte-t-il les performances?

Je suis également ouvert à d'autres suggestions sur la façon d'obtenir la disponibilité souhaitée pour ce volume de données. Par exemple, serait-il préférable d'utiliser une bibliothèque tierce comme Sequoia pour gérer le clustering des instances MySQL standard? Ou une solution plus directe basée sur la réplication MySQL?

La seule condition est que ce soit une solution basée sur MySQL. Je ne pense pas que MySQL soit la meilleure solution pour les données que nous traitons, mais c'est une exigence difficile.

Source

2009-05-11 Mark

Si vous recherchez des technologies, vous pouvez envisager certains projets basés sur Google BigTable. HBase de Hadoop, et Hypertable sont des projets intéressants à regarder. http://hadoop.apache.org/hbase/ et http://www.hypertable.org/ – Kekoa

Cette question peut être mieux posée sur serverfault.com. – lothar

Vitesse sage, il peut être manipulé. Du point de vue de la taille, la question n'est pas la taille de vos données, mais plutôt la taille de votre index, car les index doivent tenir entièrement dans la mémoire.

Je serais heureux d'offrir une meilleure réponse, mais le travail de base de données haut de gamme est très dépendant de la tâche. Je devrais en savoir beaucoup plus sur ce qui se passe avec les données pour être d'une aide supplémentaire.

Source

2009-05-11 22:17:46

La base de données stockera un flux de données horodatées que nous recevons à 50 Hz pour un certain nombre d'emplacements, d'où 2500 insertions/sec. La configuration du flux peut changer à tout moment, il pourrait donc y avoir un nombre variable de valeurs flottantes. L'horodatage sera la clé primaire et aura un index. Nous supposons que la colonne timestamp sera en mémoire avec le reste des données sur le disque. – Mark

Je voudrais insérer par lots, alors. Un insert/client/seconde pour plusieurs lignes. La réplication maître-maître simple vous permettra de basculer et de rencontrer facilement une charge de 50 insertion/seconde. La seule vraie question est de savoir à quel point il est important d'éviter de perdre un échantillon, et je suppose que vous pouvez gérer 2 ou 3 secondes de données perdues pour un crash de serveur. Comme indice supplémentaire, le partitionnement de votre table peut être utile si vous avez un index autre que la clé primaire. Il peut également y avoir des astuces d'entreposage de données pour accélérer ces grosses requêtes. –

Merci pour les commentaires. Nous avons pensé que les encarts par lots seraient la solution. J'ai fait quelques calculs en utilisant le script ndb_size.pl et vous aviez raison sur la taille de l'index. La mémoire requise ne rend pas possible l'utilisation de Cluster. Cependant, nous avons également appris aujourd'hui que certaines pertes de données sont correctes. Comme vous l'avez dit, nous étudions maintenant la possibilité d'utiliser une réplication simple. – Mark

Ok, je fait a lu la partie à propos de mySQL étant une exigence dure. Permettez-moi tout d'abord de souligner que la charge de travail dont vous parlez - 2500 insertions/sec, requêtes rares, requêtes susceptibles d'avoir des ensembles de résultats allant jusqu'à 10 pour cent de l'ensemble des données - est à peu près pessimal pour tout système de base de données relationnelle. (Cela me rappelle plutôt un projet, il y a longtemps, où j'avais l'obligation de charger 100 mégaoctets de données de programme sur une ligne RS-422 à 9600 bauds (également une exigence) en moins de 300 secondes (également une exigence difficile.) le fait que 1K octets/sec × 300 secondes = 300 Ko ne semblent pas communiquer.)

Ensuite, il y a la partie de « contenir jusqu'à 30 chars. » Le phrasé suggère au moins que le nombre d'échantillons par insert est variable, ce qui suggère des problèmes de normalisation - ou bien il faut faire une largeur de 30 lignes et utiliser des valeurs NULL. Mais avec tout cela, d'accord, vous parlez de 300 Ko/s et 2500 TPS (en supposant qu'il s'agit vraiment d'une séquence d'échantillons non liés). Ce set of benchmarks, au moins, suggère qu'il n'est pas hors de la possibilité.

Source

2009-05-11 23:58:07

Merci pour les commentaires et pour m'avoir appris un nouveau mot! (pessimal) Pour gérer le nombre variable d'échantillons, nous envisageons de créer un nouveau tableau chaque fois que cela change, car il ne devrait pas être trop souvent. Nous aurions alors une table de consultation qui vous permettrait de trouver la table de données appropriée pour une période de temps. – Mark

This article est vraiment utile pour identifier ce qui peut ralentir une grande base de données MySQL.

Source

2009-05-12 00:01:16

Essayez peut-être des fragments d'hibernation et exécutez MySQL sur 10 nœuds avec 1/2 téraoctet chacun, donc vous pouvez gérer 5 téraoctets alors;) bien au-delà de votre limite, je pense?

Source

2010-11-23 17:27:02

MySQL Cluster gère une base de données de téraoctets

Répondre

Questions connexes