Рекомендации по платформе обработки данных (MapReduce/DHT?)

Question

Мне нужно выполнить распределенный поиск по большому набору небольших файлов (~ 10 МБ), при этом каждый файл представляет собой набор key: value пары.Для этого у меня есть набор серверов с 56 ядрами ЦП — в основном это двухъядерные и четырехъядерные процессоры, а также большой DL785 с 16 ядрами.

Система должна быть разработана для онлайн-запросов. В идеале я хочу реализовать веб-сервис, который возвращает выходные данные JSON по запросу из внешнего интерфейса.

Еще больше усложняет ситуацию то, что для любого конкретного поиска иногда мне нужно просмотреть только последний версию каждого файла, но другие поиски могут применяться только к тем версиям файлов, которые существовали на определенную дату.

Я рассмотрел Hadoop, но администрирование у него ужасное, а методы отправки заданий по умолчанию медленные.Похоже, что он предназначен для очень крупномасштабной автономной обработки, а не для онлайн-обработки данных.

CouchDB выглядит хорошо как хранилище документов и знает key: value документы стиля, управление версиями и MapReduce, но я не могу найти ничего о том, как его можно использовать в качестве распределенный Система MapReduce.Вся документация по кластеризации говорит об использовании кластеризации и репликации весь база данных для Балансировка нагрузки, тогда как мне нужно распределение нагрузки.

Я также исследовал различные DHT, и, хотя они подходят для фактического хранения и извлечения отдельных записей, они, как правило, плохо справляются с частью «карты» MapReduce.Перебор всего набора документов имеет решающее значение.

Следовательно, моя идеальная система должна включать распределенную файловую систему, такую ​​​​как HDFS Hadoop, с возможностями веб-сервиса CouchDB.

Может ли кто-нибудь указать мне направление, которое может помочь?Язык реализации не вызывает особого беспокойства, за исключением того, что он должен работать в Linux.

Answer 1

Кажется, что проблемная область лучше подходит для такого решения, как Solr.Solr предлагает http-интерфейсы для других приложений, даже JSON.Вы можете разделить поиск на несколько компьютеров или распределить одну копию по машинам для балансировки нагрузки (главный/подчиненный).Это будет зависеть от того, что лучше всего подходит для ваших данных.Но, по моему опыту, для результатов поиска в реальном времени Lucene/Solr превзойдет любую систему, основанную на системе карты/сокращения.

Интегрировать Solr в приложение и выполнять дополнительные обновления очень просто.Хотя на самом деле он не имеет никакого представления о версии.Если это действительно необходимо, возможно, вам придется найти другой способ прикрепить это.

Answer 2

Возможно, я немного смущен тем, что нужно вашему приложению, вы упомянули о необходимости иметь возможность поиска по парам ключ/значение, где Solr был бы отличным приложением.Но вы также упоминаете, что вам нужно использовать часть карты карты/сокращения и что вам нужно сканировать 10 миллионов документов.Я не уверен, что вы найдете решение, которое будет сканировать 10 миллионов документов и возвращать результаты в онлайн-режиме (в миллисекундном диапазоне).Но есть и другое решение. HBase.Это построено на основе HDFS и позволяет запускать задания по уменьшению карты того типа, который вам нужен, - миллионы более мелких элементов.Но работа не может быть отправлена ​​и завершена в какое-то время, которое вы ищете.

В настоящее время у меня есть тестовая HBase, настроенная с элементами RSS (2 миллиона элементов, несколько КБ на элемент).Общий размер БД ~5Гб.С этой БД выполняется несколько заданий, сканирующих все элементы и затем выдающих результаты.Кластер сканирует объекты со скоростью ~5000 в секунду, но выполнение задания все равно занимает около 10 минут.