Вы бы порекомендовали использовать Hadoop / HBASE?

Question

У нас есть SQL-сервер 2008 и одна из таблиц, скажем, таблица A имеет следующие характеристики:

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

• Схема выглядит так:

Таблица содержит переменное количество строк. По сути, мы должны очистить его по выходным, иначе размер влияет на производительность. Таким образом, размер варьируется от 3 до 15 м рядов в течение недели. В связи с некоторыми новыми требованиями мы ожидаем, что это число будет увеличено на 10 млн. К концу 2012 года . Таким образом, мы будем говорить о 10-25 м рядах.

Теперь дополнительно

• Данные в A никогда не меняются . Средний уровень может использовать данные A, но это будет операция только для чтения. Но обычно средний уровень даже не заботится о содержимом. Обычно (не всегда, но в 80% случаев) запускаются хранимые процедуры для создания отчетов и доставки отчетов в другие системы.
• Клиенты из этой таблицы обычно хотят выполнять длинные последовательные операции чтения для одной бизнес-даты и типа. т.е. "получите все значения типа 1 на сегодня"
• Клиенты захотят присоединиться к этой таблице с 3-5 таблицами и затем доставлять отчеты в другие системы.
• Приведенные выше допущения не обязательно действительны для всех таблиц, с которыми объединяется А. Например, мы обычно соединяем A с таблицей B и выполняем вычисления, подобные B.value * A.value. B.value является изменчивым столбцом.

Вопрос

• Характеристики A очень похожи на то, что могут предложить HBase и другие ориентированные на столбцы схемы.
• Однако некоторые объединения содержат изменчивые данные.

Вы бы порекомендовали перенести A в схему HBase?

А также, если бы мы переместили А, я бы предположил, что нам также пришлось бы перенести В и другие зависимые таблицы, которые (наоборот, с А) используются несколькими другими местами среднего уровня. Не будет ли это сильно усложнять?

Answer 1

25 миллионов строк не звучат достаточно большими, чтобы оправдать использование HBase, хотя шаблон использования подходит. Вам нужен узел имени, трекер заданий, мастер, а затем и серверы вашего региона, поэтому вам понадобится минимум 5 узлов для запуска HBase любым приемлемым способом. Ваши строки настолько малы, что я предполагаю, что это может быть 10 ГБ данных, поэтому хранение этих данных на 5 серверах кажется излишним.

Если вы пойдете этим путем (возможно, вы захотите хранить больше чем за неделю данные), есть способы интеграции HBase с реляционными БД. Hive, например, обеспечивает подключение ODBC / JDBC и может запрашивать HBase. Oracle и Teradata обеспечивают интеграцию между программным обеспечением для реляционных БД и нереляционным хранилищем. Я знаю, что Microsoft недавно объявила, что они отказываются от Dryad в пользу интеграции с Hadoop, но я не уверен, насколько далеко продвинулся этот процесс по отношению к SQL Server. И если все, что вам нужно, это «получить список идентификаторов для использования в моем запросе SQL», вы, конечно, можете написать что-то самостоятельно достаточно легко.

Я думаю, что HBase очень увлекателен, и могут быть вещи, которые вы не упомянули, которые могут подтолкнуть вас к этому (например, высокая доступность). Но моя интуиция говорит, что вы, вероятно, можете уменьшить свой реляционный БД гораздо дешевле, чем перейти на HBase.