Имеет ли смысл HBase, если она не работает в распределенной среде?

Question

Я создаю индекс данных, который повлечет за собой хранение множества триплетов в форме (document, term, weight).Я буду хранить до нескольких миллионов таких строк.В настоящее время я делаю это в MySQL в виде простой таблицы.Я сохраняю идентификаторы документа и термина в виде строковых значений, а не внешних ключей для других таблиц.Я переписываю программное обеспечение и ищу лучшие способы хранения данных.

Глядя на то, как работает HBase, кажется, что это довольно хорошо вписывается в схему.Вместо того чтобы хранить множество тройняшек, я мог бы сопоставить document Для {term => weight}.

Я делаю это на одном узле, поэтому меня не волнуют распределенные узлы и т.д.Должен ли я просто придерживаться MySQL, потому что он работает, или было бы разумно попробовать HBase?Я вижу, что Lucene использует его для полнотекстового индексирования (что аналогично тому, что я делаю).Мой вопрос на самом деле заключается в том, как один узел HBase будет сравниваться с одним узлом MySQL?Я пришел из Scala, так может ли прямой Java API иметь преимущество перед JDBC и MySQL При разборе каждого запроса и т.д.?

Моя главная забота - скорость вставки, поскольку ранее это было узким местом.После обработки я, вероятно, в конечном итоге помещу данные обратно в MySQL для оперативного запроса, потому что мне нужно выполнить некоторые вычисления, которые лучше выполнять в MySQL.

Я попробую создать прототипы обоих, но я уверен, что сообщество сможет дать мне ценную информацию по этому поводу.

Answer 1

Используйте правильный инструмент для этой работы.

Существует множество анти-СУБД или БАЗОВЫХ систем (в основном доступных, в мягком состоянии, в конечном итоге согласованных), в отличие от ACID (атомарность, согласованность, Изоляция, Долговечность) на выбор здесь и здесь.

Я использовал традиционные РСУБД и хотя вы можете хранить объекты CLOB/Blob-объекты, они делают не имеет встроенных индексов по индивидуальному заказу, специально для поисков этих объектов.

Вы хотите выполнить большую часть работы (вычисление взвешенной частоты для каждого найденного кортежа) при вставке документа.

Возможно, вы также захотите провести некоторую работу, оценивая полезность каждой пары (documentId, searchWord) после каждого поиска.

Таким образом, вы сможете с каждым разом выполнять поисковые запросы все лучше и лучше.

Вы также хотите сохранить оценку или вес для каждого поиска и взвешенные оценки за сходство с другими поисками.

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

Вставка документа также должна привести к некоторому изменению веса при поиске индексы.

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

Answer 2

MapReduce кажется отличным способом генерации кортежей.Если вы можете поместить задание scala в файл jar (не уверен, поскольку я раньше не использовал scala и являюсь jvm n00b), было бы просто отправить его и написать небольшую оболочку для его запуска. на карте уменьшить кластер.

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

В общем, похоже, что вы делаете с текстами что-то более статистическое...Рассматривали ли вы возможность просто использовать lucene или solr вместо того, чтобы писать свои собственные?