20 миллиардов строк в месяц - Hbase / Hive / Greenplum / What?

Я хотел бы использовать вашу мудрость для подбора правильного решения для системы хранилища данных. Вот некоторые подробности, чтобы лучше понять проблему:

Данные организованы в виде звездообразной схемы с одним БОЛЬШИМ фактом и ~ 15 измерениями.
20 млрд строк фактов в месяц
10 измерений с сотней строк (несколько иерархия)
5 измерений с тысячами строк
2 измерения с ~ 200 тыс. Строк
2 больших размера с рядами от 50 до 100 миллионов

К этой БД выполняются два типичных запроса

Топ участников в dimq:

select    top X dimq, count(id) 
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 
group by  dimq 
order by  count(id) desc

Меры против кортежа:

select    count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),...
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 

Вопросов:

  1. Какая платформа лучше всего подходит для выполнения таких запросов
  2. Какое оборудование нужно
  3. Где его можно разместить (EC2?)


    (пожалуйста, пока не обращайте внимания на проблемы с импортом и загрузкой)

Tnx,
Аггей.

Какой домен приложения является источником данных?

ConcernedOfTunbridgeWells 10.12.2008 03:04

Сколько пользователей и какое время отклика вам нужно? Вы сосредоточены здесь на специалисте-одиночке со стойкой для лезвий и его ежемесячными отчетами, или вы хотите предоставить доступ в реальном времени по всему миру тысячам конечных пользователей? 19 измерений - это много для материализации субкубов.

Stephan Eggermont 10.12.2008 02:12
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
31
2
19 648
6

Ответы 6

Альтернативой для небольшого числа пользователей может быть кластер (беовульф). 20K покупает вам 50 неттопов по 500G каждый. Это пиковая мощность около 3 кВт. Или 4 месяца в облачном хранилище.

NXC, вы уверены насчет этих 600 миллиардов строк в день? Даже если одна строка будет состоять всего из одного байта, это 600 ГБ данных в день. Предполагая более разумные 100 байт на строку, мы говорим о 60 ТБ данных в день, 1,8 ПБ в месяц. Я действительно сомневаюсь, что кто-то перекачивает столько данных через Oracle.

Другие источники, похоже, подтверждает, что Oracle становится довольно сложно обрабатывать, когда объем данных достигает двузначных цифр в ТБ.

Это то, что мне сказал кто-то, близкий к источнику, но он мог что-то потерять при переводе - я предполагаю, что это может быть 600 миллионов строк / день или 600 ГБ / день, что гораздо более правдоподобно. Они делают что-то необычное с переносными табличными пространствами, чтобы перемещать данные по различным системам.

ConcernedOfTunbridgeWells 18.12.2008 02:42

Имейте в виду, что в этом подразделении есть команда бизнес-аналитики, в которой работает 800 человек, только для подразделения фиксированной связи, и еще одна, которая не намного меньше в другом конце города, которая занимается мобильным подразделением.

ConcernedOfTunbridgeWells 18.12.2008 02:45

Я не уверен, что большое количество сотрудников в национальных телекоммуникационных компаниях свидетельствует о большом объеме выполняемой работы!

Will Dean 20.12.2008 02:35

Нет, но они говорят о больших бюджетах.

ConcernedOfTunbridgeWells 24.12.2008 15:17

Почитайте сайт Монаша: http://www.dbms2.com/ Он пишет о больших базах данных.

Может быть, вы можете использовать Oracle Exadata (http://www.oracle.com/solutions/business_intelligence/exadata.html и http://kevinclosson.wordpress.com/exadata-posts/) или, может быть, вы можете использовать Hadoop. Hadoop бесплатен.

У меня был большой успех с Vertica. В настоящее время я загружаю от 200 миллионов до 1 миллиарда строк в день - в среднем около 9 миллиардов строк в месяц - хотя я достиг 17 миллиардов в месяц. У меня около 21 измерения, и запросы выполняются невероятно быстро. Мы перешли от старой системы, когда у нас просто не было времени для загрузки данных.

мы провели очень исчерпывающее испытание и изучение различных решений - и практически изучили все, что есть на рынке. Хотя и Teradata, и Netezza подошли бы нам, они были для нас слишком дорогими. Vertica превзошла их обоих по соотношению цена / качество. Это, кстати, столбчатая база данных.

Сейчас у нас около 80 пользователей - и ожидается, что к концу следующего года их число вырастет до 900, когда мы начнем полное развертывание.

Мы широко используем сервисы ASP.NET/dundas/reporting для отчетов. Он также хорошо работает со сторонними решениями для отчетности - хотя мы еще не пробовали.

Кстати, что собираетесь использовать для загрузки данных? Мы используем информатика и очень им довольны. SSIS загнал нас в стену.

Мне любопытно, что вы в итоге выбрали. Ваш вопрос был до конца 2008 года. Сегодня ситуация иная с HBase, Greenplum, pig и т. д., Предоставляющими доступ, подобный SQL.

Используя плагин отчетов HBase и jasperserver hbase, можно создавать достойные отчеты. OLAP с низкой задержкой можно создать в HBase. Это будет работать так же, как SQL. Плагин Jasperserver HBase предоставляет язык запросов Hbase, который является расширением команды сканирования Hbase.

Другие вопросы по теме