salut là-bas à Je voudrais des idées / commentaires sur ce qui suit chez vous honorable et vénérable BUNCH.
J'ai un enregistrement de 100 m que je dois traiter. J'ai 5 nœuds (dans un cluster des rochers) pour faire cela. Les données sont très structurées et tombent bien dans le modèle de données relationnelle. Je veux faire des choses en parallèle depuis mon traitement prend un certain temps.
Comme je le vois, j'ai deux options principales:
Installez MySQL sur chaque nœud et mettre 20 m enregistrements sur chacun. Utilisez le nœud de tête pour déléguer les requêtes des nœuds et agréger les résultats. Capacités de requête ++ , mais je risque de risquer des maux de tête lorsque je viendrai choisir des stratégies de partitionnement, etc. (Q. Est-ce ce qu'ils appellent le cluster MySQL / Postgres?). La très mauvaise partie est que le traitement des enregistrements est laissé à moi maintenant pour prendre soin de (comment répartir à travers les machines, etc.) ...
Installez alternativement Hadoop, HIVE et HBASE (notez que cela pourrait ne pas être le moyen le plus efficace de stocker mes données, car HBASE est orienté colonne) et définit simplement les nœuds. Nous écrivons tout dans le Mapreduce Paradigm et, Bang, nous vivons heureux pour toujours. Le problème ici est que nous perdons les capacités de requête "en temps réel" (je sais que vous pouvez utiliser la ruche, mais qui n'est pas suggérée pour les requêtes en temps réel - dont j'ai besoin) - car je dispose également de certaines requêtes SQL normales pour exécuter parfois " Sélectionnez * du vin de couleur = 'Brown' ".
Notez que, en théorie - si j'avais 100 millions de machines, je pourrais tout faire instantanément, car pour chaque enregistrement, le traitement est indépendant de l'autre. Aussi - mes données sont en lecture seule. Je n'envisage aucune mise à jour ne se produit. Je n'ai pas besoin / veut des enregistrements de 100 m sur un nœud. Je ne veux pas qu'il y ait des données redondantes (car il y en a beaucoup de choses), donc le garder à la fois dans MySQL / Postgres et Hadoop / HBase / HDFS. n'est pas une véritable option.
Merci beaucoup
4 Réponses :
salut,
J'ai eu une situation où j'ai eu de nombreuses tables que j'ai créées en parallèle avec Sqlalchemy et la bibliothèque multiprocessionnaire Python. J'ai eu plusieurs fichiers, un par table et les chargés en utilisant des processus de copie parallèles. Si chaque processus correspond à une table séparée, cela fonctionne bien. Avec une table, l'utilisation de la copie serait difficile. Vous pouvez utiliser des tables partitionnement dans PostgreSQL, je suppose. Si vous êtes intéressé, je peux donner plus de détails.
Cordialement.
Il y a quelques questions à poser, avant de suggérer.
de
Pouvez-vous formuler vos requêtes pour accéder uniquement à la clé primaire? En d'autres termes - si vous pouvez éviter toutes les jointures et les analyses de la table. Si tel est le cas, HBASE est une option, si vous avez besoin de très haut débit d'accès en lecture / écriture.
de
Je n'ai pas la chose que la ruche est une bonne option en tenant compte de la faible valeur de données. Si vous vous attendez à ce qu'ils grandissent de manière significative - vous pouvez le considérer. Dans tous les cas, la ruche est bonne pour les charges de travail analytiques - non pour le type de traitement OLTP.
de
Si vous avez besoin de modèle relationnel avec des jointures et des analyses - je pense qu'une bonne solution pourrait être un noeud maître et 4 esclaves, avec une réplication entre eux. Vous dirigerez toutes les écrivies au Master et la balance se lit entre tout cluster. C'est particulièrement bon si vous avez beaucoup plus de lecture, puis écrit.
Dans ce schéma, vous aurez tous les enregistrements de 100 m (pas de correspondance) sur chaque nœud. Dans chaque nœud, vous pouvez utiliser le partitionnement le cas échéant.
Pouvez-vous prouver que MySQL est le goulot d'étranglement? Les enregistrements de 100 m ne sont pas que beaucoup, et on dirait que vous n'effectuez pas de requêtes complexes. Sans savoir exactement quel type de traitement, voici ce que je ferais, dans cet ordre:
Dans votre situation, je résisterais à la tentation de sauter de MySQL, à moins que ce ne soit absolument nécessaire.
Vous pouvez également envisager d'utiliser Cassandra . J'ai récemment découvert cet article sur HBase vs. Cassandra que j'ai rappelé quand j'ai lu votre message.
Le gist de celui-ci est que Cassandra est une solution NOSQL hautement péquible Donc, tout dépend de la maintenance de votre modèle relationnel ou non.
Un de mes amis m'a posté quelque chose comme ça: Cloudera. com / blog / 2009/03 / accès à la base de données - Hadoop C'est une petite étape dans la bonne direction - mais j'aimerais entendre vos opinions sur la conception et comment je devrais y aller ...