Еще насчет шашечек… Нигде не могу найти синтаксис запросов по тексту документа. Пробовал синтаксис Spinx или Solr — не подходит.
Может здесь помогут — как осуществить поиск по фразе, чтобы слова шли точно рядом? Например, как найти все документы с фразой «предварительное обеспечение» (и все падежи и словоформы)?
У Solr-а есть стандартная, кастомизируемая — Hue (http://gethue.com/solr-search-ui-only/). Но в нашей ситуации важно было оставить интерфейс легаси корпортативного приложения, чтобы пользователи не видели разницы. Так что мы написали адаптер между этим приложением и API Solr-а.
Посмотрите еще HP Vertica — она гораздо старше, чем Hadoop, и популярна среди банков. И там есть MPP.
Но опять же, они позиционируют этот продукт для аналитику, а не OLTP (это к пожеланию «и что бы можно быть и realtime нагрузки давать,»).
Требование понятно. Мы пытались объяснить, что движки типа Spark и Impala не используют MapReduce, у них другие механизмы, гораздо более быстрые, чем традиционный MR. Хотя, возможно, они не подойдут для ваших задач.
Зависит конечно от типов запросов, но очень похоже для кейс для Spark-а. Там real-time updating (streaming), анализируемые выборки (у них называются «коллекции») по максимуму держатся в памяти.
Но, конечно по скудной информации сложно давать взвешенные советы
-> В частности не realtime нагрузка.
Не совсем. В Hadoop От Cloudera входит, например, такой компонент как Flume Solr Sink. Он позволяет в момент получения Flume-ом события сразу его индексировать в Solr-е, и при достаточной пропорции размеров индексов и машин в кластере производительность может легко превышать сотни тысяч в секунду (если говорить про типичные события приложений, не документы).
Другой пример — Lily HBase Indexer. Он отправляет запись на индексацию в момент, когда она вставляется в HBase.
Ну и конечно же нельзя обойти вниманием Spark, который позволяет делать complex event prosessing в почти реальном времени (near-realtime). Однако Spark очень требователен к оперативной памяти. Ну, правда, это уже не к теме поиска в данных.
-> Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Если говорить про задачи YARN (например, MapReduce), то конечно получится. Для их одновременно-параллельного запуска достаточно (если грубо), чтобы 200*{amount_of_memory_required_for_any_task} < {total_amount_of_memory_in_cluster_devoted_for_yarn_tasks} и {amount_of_processor_cores_in_cluster} > 200
Просто цель описанной в статье задачи — произвести начальную выгрузку всех существующих логов приложений (а их десятки терабайт и миллиарды записей). И делать это через merge индексов — самый производительный способ. И конечно же большое количество файлов нет необходимости индексировать все параллельно — можно пачками.
Может здесь помогут — как осуществить поиск по фразе, чтобы слова шли точно рядом? Например, как найти все документы с фразой «предварительное обеспечение» (и все падежи и словоформы)?
Но опять же, они позиционируют этот продукт для аналитику, а не OLTP (это к пожеланию «и что бы можно быть и realtime нагрузки давать,»).
Но, конечно по скудной информации сложно давать взвешенные советы
Не совсем. В Hadoop От Cloudera входит, например, такой компонент как Flume Solr Sink. Он позволяет в момент получения Flume-ом события сразу его индексировать в Solr-е, и при достаточной пропорции размеров индексов и машин в кластере производительность может легко превышать сотни тысяч в секунду (если говорить про типичные события приложений, не документы).
Другой пример — Lily HBase Indexer. Он отправляет запись на индексацию в момент, когда она вставляется в HBase.
Ну и конечно же нельзя обойти вниманием Spark, который позволяет делать complex event prosessing в почти реальном времени (near-realtime). Однако Spark очень требователен к оперативной памяти. Ну, правда, это уже не к теме поиска в данных.
-> Batch обработка, т.е. запустить 200 параллельных задач не получиться?
Если говорить про задачи YARN (например, MapReduce), то конечно получится. Для их одновременно-параллельного запуска достаточно (если грубо), чтобы 200*{amount_of_memory_required_for_any_task} < {total_amount_of_memory_in_cluster_devoted_for_yarn_tasks} и {amount_of_processor_cores_in_cluster} > 200
Просто цель описанной в статье задачи — произвести начальную выгрузку всех существующих логов приложений (а их десятки терабайт и миллиарды записей). И делать это через merge индексов — самый производительный способ. И конечно же большое количество файлов нет необходимости индексировать все параллельно — можно пачками.