2013-06-12 1 views
0

Je le scénario suivant:Quelle approche et base de données à utiliser dans la solution des performances critiques

  • Environ 70 millions d'équipements envoyer un signal tous les 3 ~ 5 minutes à le serveur d'envoi de son identifiant, le statut (en ligne ou offiline), IP, emplacement (latitude et longitude), nœud parent et quelques autres informations.

  • Les autres informations peuvent ne pas être dans un format standard (donc pas de schéma pour moi) mais j'ai encore besoin de l'interroger.

  • Les équipements peuvent disparaître pendant un certain temps (ou pour toujours) sans envoyer de signaux dans le processus. J'ai donc besoin d'un moyen pour "oublier" les équipements si ils n'ont pas envoyé de signal au cours des X derniers jours. Les nouveaux équipements peuvent également être mis en ligne à tout moment.

  • Je dois interroger toutes ces données. Comme savoir combien d'équipements sont hors ligne sur une région spécifique ou sur une plage IP. Il n'y aura pas beaucoup de requêtes en cours d'exécution en même temps.

  • Certaines requêtes doivent être exécutées rapidement (moins de 3 minutes par requête) et en même temps que la base de données est mise à jour. J'ai donc besoin d'index sur les attributs principaux (id, statut, IP, emplacement et nœud parent). Les résultats de la requête n'ont pas besoin d'être précis à 100%, la cohérence finale est correcte tant que cela ne prend pas trop de temps (plus de 20 min sur avarage) pour qu'ils apparaissent dans les résultats des requêtes.

  • Je n'ai pas besoin de persistance du tout, si l'alimentation est coupée, il est acceptable de perdre tout.

tenu de tout cela, je pensais à l'aide d'une approche NoSQL MongoDB ou CouchDB peut-être que j'ai l'expérience avec MapReduce et Javascript mais je ne sais pas quel est le meilleur pour mon problème (je suis graviter vers CouchDB) ou s'ils sont aptes à gérer cette énorme charge de travail. Je ne sais même pas si j'ai réellement besoin d'une base de données "traditionnelle" car je n'ai pas besoin de persistance sur le disque (peut-être une approche mémoire principale serait-elle préférable?), Mais j'ai besoin d'un moyen de créer facilement des requêtes personnalisées.

Le principal problème que je perçois sont les suivantes:

  • besoin d'insérer/mettre à jour beaucoup de tuples vraiment rapide et je ne sais pas avance si le signal que je reçois est déjà dans la base de données ou non . Presque tous les signaux seront dans le même état que la dernière fois, alors peut-être interroger par ID et vérifier si le tuple a changé sinon ne rien faire, s'il a mis à jour?

  • Oubliez les équipements hors ligne. Un travail par lots exécuté pendant la nuit en supprimant des tuples expirés résoudrait ce problème.

  • Il n'y aura pas beaucoup de requêtes en cours d'exécution en même temps, mais elles ont besoin de pour fonctionner rapidement. Donc je suppose que j'ai besoin d'avoir un cluster qui effectue une requête unique sur plusieurs nœuds du cluster (est-ce que CouchDB MapReduce divise la charge de travail à plusieurs nœuds du cluster?).Je ne suis pas enterily sûr que j'ai besoin d'un cluster si, une seule machine plus cher gérer toute la charge?

  • Je n'ai jamais utilisé un système noSQL auparavant, mais j'ai des connaissances théoriques sur le sujet.

Répondre

1

Est-ce logique?

Apache Flume pour collecter les signaux.

Il s'agit d'un système distribué, fiable et disponible pour collecter, agréger et déplacer efficacement de grandes quantités de données de journaux provenant de nombreuses sources différentes vers un magasin de données centralisé. Facile à configurer et à mettre à l'échelle. Stockez les données dans HDFS sous forme de fichiers à l'aide de Flume.

Hive pour les requêtes par lots.

Mappez les fichiers de données dans HDFS en tant que tables externes dans l'entrepôt Hive. Écrivez des requêtes SQL comme HiveQL lorsque vous avez besoin d'un traitement hors ligne.

HBase pour les lectures/écritures aléatoires en temps réel.

Étant donné que HDFS, étant un FS, n'a pas la capacité de lecture/écriture aléatoire, vous auriez besoin d'une base de données à cette fin. En regardant votre cas d'utilisation, HBase me semble bon. Je ne dirais pas MongoDB ou CouchDB puisque vous ne traitez pas de documents ici et que ce sont des bases de données documentaires.

Impala pour des requêtes interactives rapides.

Impala vous permet d'exécuter des requêtes SQL rapides et interactives directement sur vos données stockées dans HDFS ou HBase. Contrairement à Hive, il n'utilise pas MapReduce. Il utilise à la place la puissance du MPP, donc c'est bon pour les choses en temps réel. Et il est facile à utiliser car il utilise les mêmes métadonnées, la syntaxe SQL (Hive SQL), le pilote ODBC, etc. que Hive.

HTH

0

En fonction du type d'analyse, CouchDB, HBase de Flume peut être tout être de bons choix. Pour les statistiques strictement numériques «à écriture unique», le graphite de données est une solution open source très populaire.

Questions connexes