Я хотел бы использовать вашу мудрость для подбора правильного решения для системы хранилища данных. Вот некоторые подробности, чтобы лучше понять проблему:
Данные организованы в виде звездообразной схемы с одним БОЛЬШИМ фактом и ~ 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
Вопросов:
Где его можно разместить (EC2?)
(пожалуйста, пока не обращайте внимания на проблемы с импортом и загрузкой)
Tnx,
Аггей.
Сколько пользователей и какое время отклика вам нужно? Вы сосредоточены здесь на специалисте-одиночке со стойкой для лезвий и его ежемесячными отчетами, или вы хотите предоставить доступ в реальном времени по всему миру тысячам конечных пользователей? 19 измерений - это много для материализации субкубов.

Альтернативой для небольшого числа пользователей может быть кластер (беовульф). 20K покупает вам 50 неттопов по 500G каждый. Это пиковая мощность около 3 кВт. Или 4 месяца в облачном хранилище.
NXC, вы уверены насчет этих 600 миллиардов строк в день? Даже если одна строка будет состоять всего из одного байта, это 600 ГБ данных в день. Предполагая более разумные 100 байт на строку, мы говорим о 60 ТБ данных в день, 1,8 ПБ в месяц. Я действительно сомневаюсь, что кто-то перекачивает столько данных через Oracle.
Другие источники, похоже, подтверждает, что Oracle становится довольно сложно обрабатывать, когда объем данных достигает двузначных цифр в ТБ.
Это то, что мне сказал кто-то, близкий к источнику, но он мог что-то потерять при переводе - я предполагаю, что это может быть 600 миллионов строк / день или 600 ГБ / день, что гораздо более правдоподобно. Они делают что-то необычное с переносными табличными пространствами, чтобы перемещать данные по различным системам.
Имейте в виду, что в этом подразделении есть команда бизнес-аналитики, в которой работает 800 человек, только для подразделения фиксированной связи, и еще одна, которая не намного меньше в другом конце города, которая занимается мобильным подразделением.
Я не уверен, что большое количество сотрудников в национальных телекоммуникационных компаниях свидетельствует о большом объеме выполняемой работы!
Нет, но они говорят о больших бюджетах.
Почитайте сайт Монаша: 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.
Какой домен приложения является источником данных?