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

голоса
31

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

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

Два типичных запросов, выполняемых на этом DB

Лучшие участники в 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,
Аггей.

Задан 09/12/2008 в 22:05
источник пользователем
На других языках...                            


7 ответов

голоса
55

Я не могу не подчеркнуть это достаточно: Получить то , что играет хорошо с вне готовых инструментов отчетности.

20 миллиардов строк в месяц ставит вас на территории VLDB, так что вам нужно разделение. Размеры низкие мощностные также предположить, что растровые индексы будет выигрыш производительности.

  • Забудьте облачные системы ( Hive , Hbase ) , пока они не имеют зрелую поддержку SQL. Для хранилища данных приложения вы хотите что - то , что работает с обычными инструментами отчетности. В противном случае, вы окажетесь постоянно увязли писать и поддерживать программы отчетов одноранговых.

  • Объемы данных управляемы с более традиционным СУБД , как Oracle - Я знаю о крупной европейской телекоммуникационной компании , которая загружает 600GB в день в Oracle базы данных. При прочих равных условиях , это на два порядка больше , чем ваши объемы данных, поэтому общие архитектуры диска все еще имеют запас для вас. Разделяемого ничего архитектура , как Netezza или Teradata , вероятно , будет еще быстрее , но эти объемы не на уровне , который выходит за пределами обычной системы с разделяемым диском. Имейте в виду, однако, что эти системы все довольно дорого.

  • Кроме того, иметь в виду , что MapReduce является не эффективный алгоритм выбора запроса . Принципиально механизм для распределения вычислений грубой силы. Greenplum действительно есть MapReduce фоновой, но специально построенном совместно ничего двигатель будет намного более эффективным и получить больше работы за меньшее оборудования.

Мой взгляд на это , что Teradata или Netezza, вероятно , будет идеальным инструментом для работы , но , безусловно , самый дорогой. Oracle , Sybase IQ или даже SQL Server будет также обрабатывать объемы данных , участвующих , но будет более медленным - они общие архитектуры диска , но все еще может управлять такого рода объема данных. См этой публикации для изношенном на связанных VLDB функций в Oracle и SQL Server, а также иметь в виду , что Oracle только представила платформу хранения Exadata также.

Моя спина из-а-пидор-пакет плана предполагает способность может быть 3-5 ТБ или около того в месяц, включая индексы для Oracle или SQL Server. Вероятно, меньше на Oracle с индексами растровыми, хотя индекс лист имеет 16-байтовый ROWID на оракул vs. на странице справки 6 байт на SQL Server.

Sybase IQ делает широкое использование битовых индексов и оптимизирован для хранилищ данных запросов. Хотя разделяемой дисковой архитектуры, она очень эффективна для этого типа запроса (IIRC, это была оригинальная колонна-ориентированная архитектура). Это, вероятно, будет лучше, чем Oracle или SQL Server, как это специализированное для данного вида работ.

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

Если у вас есть 10 измерений с помощью всего лишь нескольких сот строк рассмотреть возможность объединения их в единое измерение старья , которое будет худеть вашу таблицу фактов пути объединения десяти клавиш в одной. Вы все еще можете реализовать иерархии по измерению нежелательного , и это будет стучать 1/2 или более от размера вашей таблицы фактов и устранить много использования дискового пространства с помощью индексов.

Я настоятельно рекомендую вам идти с чем - то , что играет хорошо с разумным сечением инструментов отчетности. Это означает, что SQL переднего конца. Коммерческие системы , такие как Crystal Reports позволяет отчетность и аналитику , чтобы сделать людьми с более легко получить набор навыков SQL. Мир с открытым исходным кодом также генерируется BIRT , Джаспер отчеты и Pentaho. , Улей или HBase поставить вас в бизнесе построения пользовательского передний конец, который вы действительно не хотите , если вы не будете счастливы провести следующие 5 лет написания форматтеры пользовательских отчетов в Python.

И, наконец, разместить его где-то вы можете легко получить быстрый канал данных от ваших производственных систем. Это, вероятно, означает, что ваше собственное оборудование в собственном центре обработки данных. Эта система будет стороны ввода / вывода; он делает простую обработку больших объемов данных. Это означает, что вы будете нуждаться в машинах с быстрыми дисковыми подсистемами. провайдеры облачных, как правило, не поддерживают этот тип оборудования, как это на порядок дороже, чем типа одноразовой 1U коробки традиционно используется в этих нарядах. Fast Disk I / O не сила облачных архитектур.

Ответил 09/12/2008 в 22:49
источник пользователем

голоса
9

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

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

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

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

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

Ответил 20/12/2008 в 01:50
источник пользователем

голоса
3

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

Ответил 01/10/2012 в 10:23
источник пользователем

голоса
2

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

Ответил 25/01/2012 в 17:22
источник пользователем

голоса
2

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

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

Ответил 20/12/2008 в 01:17
источник пользователем

голоса
0

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

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

Ответил 12/12/2008 в 14:42
источник пользователем

голоса
0

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

Ответил 11/12/2008 в 14:41
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more