Recommandations pour un cadre de traitement de données (MapReduce / DHT?)

Question

J'ai besoin d'effectuer une recherche distribuée sur un ensemble assez volumineux de petits fichiers (~ 10M), chaque fichier constituant un ensemble de paires clé: valeur . J'ai un ensemble de serveurs avec un total de 56 cœurs de processeur disponibles: il s'agit principalement de processeurs à double cœur et à quadruple cœur, mais également d'un grand DL785 à 16 cœurs.

Le système doit être conçu pour les requêtes en ligne. Je cherche idéalement à implémenter un service Web qui renvoie la sortie JSON à la demande d'un serveur frontal.

Pour compliquer encore les choses, pour une recherche particulière, je ne veux parfois que regarder la dernière version de chaque fichier, mais d’autres recherches peuvent uniquement s’appliquer aux versions de fichiers qui existaient déjà. date particulière.

J'ai examiné Hadoop, mais l'administration est plutôt horrible et les méthodes de soumission des travaux par défaut sont lentes. Il semble être conçu pour le traitement hors ligne à très grande échelle et non pour le traitement de données en ligne.

CouchDB a l'air sympa comme magasin de documents et connaît les documents de style clé: valeur et les versions et MapReduce, mais je ne trouve rien sur la façon dont il peut être utilisé comme distribué Système MapReduce. Toute la documentation sur les clusters parle de la mise en cluster et de la réplication de la base de données entière pour l'équilibrage de la charge , alors qu'il me faut la répartition de la charge .

J'ai également enquêté sur divers DHT. Même s'ils sont capables de stocker et d'extraire des enregistrements individuels, ils sont généralement peu capables de faire la partie "carte" de MapReduce. Itérer sur l'ensemble des documents est crucial.

Mon système idéal comprendrait donc un système de fichiers distribué comme le système HDFS de Hadoop, doté des fonctionnalités de service Web de CouchDB.

Quelqu'un peut-il m'indiquer quelque chose qui pourrait aider? Le langage d’implémentation n’est pas un problème, sauf qu’il doit fonctionner sous Linux.

Answer 1

Il semble que le domaine du problème conviendrait mieux à une solution comme Solr. Solr propose des interfaces http avec d’autres applications, même JSON . Vous pouvez partitionner la recherche sur plusieurs machines ou distribuer une copie unique sur plusieurs machines pour équilibrer la charge (maître / esclave). Cela dépend de ce qui fonctionne le mieux pour vos données. Mais dans mon expérience des résultats de recherche en temps réel, Lucene / Solr va battre n'importe quel système basé sur un système de carte / réduction.

Il est très simple d'intégrer Solr dans une application et d'effectuer des mises à jour incrémentielles. Cependant, il n'a aucune idée de la gestion des versions. Si cela est vraiment nécessaire, vous devrez peut-être trouver un autre moyen de l'utiliser.

Answer 2

Je suis peut-être un peu confus quant aux besoins de votre application. Vous mentionnez la nécessité de pouvoir effectuer des recherches dans des paires clé / valeur, où Solr serait une excellente application. Mais vous mentionnez également la nécessité d’utiliser la partie carte de map / reduction et la nécessité de numériser des documents 10M. Je ne suis pas sûr que vous trouviez une solution capable de numériser des documents de 10 millions de dollars et de renvoyer les résultats en ligne (à la milliseconde près). Mais une autre solution est de regarder HBase . Cela s’appuie sur HDFS et vous permet d’exécuter des tâches de réduction de carte du type souhaité, des millions d’éléments plus petits. Mais un travail ne va pas être soumis et finir dans n'importe quelle période proche du temps que vous recherchez.

J'ai actuellement un test HBase configuré avec des éléments RSS (2 millions d'éléments, plusieurs Ko par élément). La taille totale de la base de données est d'environ 5 Go. Plusieurs bases de données exécutées sur cette base de données analysent tous les éléments, puis génèrent les résultats. Le cluster analysera les éléments à environ 5 000 / seconde, mais il faudra encore environ 10 minutes pour terminer un travail.