Recomendaciones para un marco de procesamiento de datos (MapReduce / DHT?)

Question

Tengo la necesidad de realizar búsquedas distribuidas en un conjunto grande de archivos pequeños (~ 10M) con cada archivo como un conjunto de pares key: value . Tengo un conjunto de servidores con un total de 56 núcleos de CPU disponibles para esto: estos son en su mayoría de doble núcleo y cuatro núcleos, pero también un gran DL785 con 16 núcleos.

El sistema debe estar diseñado para consultas en línea, idealmente estoy buscando implementar un servicio web que devuelva la salida JSON a pedido desde un front-end.

Para complicar aún más las cosas, para cualquier búsqueda en particular a veces solo querré ver la última versión de cada archivo, pero otras búsquedas solo pueden aplicarse a aquellas versiones de archivos que existían en un fecha particular.

He examinado Hadoop, pero la administración es bastante horrible y los métodos de envío de trabajos predeterminados son lentos. Parece estar diseñado para el procesamiento fuera de línea a gran escala, y no para el procesamiento de datos en línea.

CouchDB se ve bien como un almacén de documentos y sabe acerca de los documentos y versiones de estilo key: value y MapReduce, pero no puedo encontrar nada acerca de cómo se puede usar como distribuido Sistema MapReduce. Toda la documentación de clustering habla sobre el uso de clustering y la replicación de la base de datos completa para equilibrio de carga , mientras que lo que necesito es distribución de carga .

También he investigado varios DHT, y aunque están bien para almacenar y recuperar registros individuales, en general son pobres para hacer la parte de "mapa" de MapReduce. Iterar sobre el conjunto completo de documentos es crucial.

Por lo tanto, mi sistema ideal comprendería un sistema de archivos distribuido como HDFS de Hadoop, con las capacidades de servicio web de CouchDB.

¿Alguien puede señalarme en la dirección de algo que pueda ayudar? El lenguaje de implementación no es una gran preocupación, excepto que debe ejecutarse en Linux.

Answer 1

Parece que el dominio del problema sería más adecuado para una solución como Solr. Solr ofrece interfaces http para otras aplicaciones, incluso JSON . Puede dividir la búsqueda en varias máquinas o distribuir una sola copia en todas las máquinas para el equilibrio de carga (maestro / esclavo). Dependería de lo que funcionó mejor para sus datos. Pero en mi experiencia para los resultados de búsqueda en tiempo real, Lucene / Solr va a vencer a cualquier sistema basado en un sistema de mapa / reducción.

Es muy sencillo integrar Solr en una aplicación y realizar actualizaciones incrementales. Sin embargo, en realidad no tiene idea de las versiones. Si eso es realmente necesario, puede que tenga que encontrar otra forma de abordarlo.

Answer 2

Puedo estar un poco confundido sobre cuáles son las necesidades de su aplicación, usted menciona la necesidad de poder buscar a través de pares clave / valor, donde Solr sería una gran aplicación. Pero también menciona la necesidad de usar la parte del mapa de map / reduce y que necesita escanear documentos de 10M. No estoy seguro de que vaya a encontrar una solución que escanee documentos de 10 millones y devuelva resultados en línea (en el rango de milisegundos). Pero otra solución también es mirar HBase . Esto se basa en HDFS y le permite ejecutar trabajos de reducción de mapas del tipo que desee, millones de elementos más pequeños. Pero un trabajo no se puede enviar y terminar en cualquier lugar cerca del tiempo que estás buscando.

Actualmente tengo una prueba HBase configurada con elementos RSS (2M elementos, varios Kb por elemento). El tamaño total de la base de datos es de ~ 5 Gb. Hay varios trabajos que se ejecutan en esta base de datos que escanea todos los elementos y luego genera resultados. El clúster escaneará elementos a ~ 5,000 / segundo, pero aún demora alrededor de 10 minutos para completar un trabajo.