быстрый запрос на hbase

Question

У меня здесь небольшой тест / документация.

Мне нужно ежедневно загружать несколько миллионов строк в базу данных. И это не данные файла журнала, у меня есть строки с разделителями-запятыми (столбцов), которые точно соответствуют реляционной базе данных.

После загрузки мне нужно разрешить очень быстрый механизм поиска. Посмотрев немного на реализацию Google Bigtable и структуры вокруг него, я изначально думал об использовании Hive, интегрированного с Hbase. Улей из-за его возможностей запроса. Загрузка работает отлично, лучше чем RDBMS perf. Однако узкое место в запросах, которое было причиной поиска альтернатив СУБД, продолжается и с улья.

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

Есть что-то еще? любой другой инструмент / решение / библиотека, которую я могу поставить поверх hbase? или даже без hbase? (Я смотрел на hbase как на альтернативу РСУБД, двигаясь в сторону удаленных вычислений)

Предложения, пожалуйста ...

Answer 1

Если вам нужны общие возможности поиска, вы можете вместо этого посмотреть на такие решения, как Solr или ElasticSearch HBase работает хорошо, если вы подготавливаете данные для запросов, которые вам нужны (дизайн ключей), а не для общего поиска.Также вы можете посмотреть на Lily , которая сочетает в себе Solr и HBase

Answer 2

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

Answer 3

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

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

Сложно сказать что-то большее, поскольку ваше описание данных и тип запросов, которые вы хотите выполнить, очень общие.

Answer 4

Вы смотрели на решение типа solr или lucene?Это не решение SQL, но язык запросов довольно гибкий для некоторых типов использования, и он очень быстрый.Есть также способы его распределения по кластеру серверов для повышения производительности, масштабирования либо размера индекса, либо количества запросов, которые он может обработать, либо обоих.