Структуры данных для построения трендов во времени

Question

Учитывая поток данных постоянно поступающих элементов, содержащих метку времени и текст (например, журнал запросов поисковой системы), как бы вы сохранили данные, чтобы вы могли эффективно извлекать итоги с течением времени для построения трендовых линий для каждого термина?

База данных, ориентированная на строки, с такими кортежами, как (term, date, count), будет работать, но не будет масштабироваться с большим количеством различных терминов. Какие альтернативные структуры данных следует рассматривать в этом контексте (например, ориентированное на столбцы хранилище)? Быстрые вставки являются важным требованием.

Answer 1

Вы ошибаетесь в своем утверждении, что СУБД, ориентированные на столбцы, более эффективны, чем ориентированные на строки, все наоборот. В вашем сценарии производительность вставок в одну строку в СУБД, ориентированных на столбцы, будет ужасной - они не оптимизированы для производительности вставки, но для запросов только для чтения. Определенно не для однорядных вставок.

Насколько быстро «быстро»? Сотни записей в секунду, безусловно, не так уж и много, при условии наличия достаточного количества операций ввода-вывода (быстрых жестких дисков). Достаточно ли общие данные для размещения в оперативной памяти? Нормальные СУБД по-прежнему являются самым безопасным выбором, но в настоящее время также доступны механизмы в памяти, которые значительно превосходят традиционные дисковые

Для агрегирования и последующей отчетности вы можете использовать сводные таблицы или общую встроенную функцию, называемую Материализованные представления .

Answer 2

Несколько мыслей:

Если это правда, что объем данных превышает скорость записи на диск, то вам придется либо увеличить скорость записи на диск (например, RAID, более быстрые диски, RAM-диски) или распределить нагрузку по многим серверам. И если масштабируемость - ваша главная задача, то распределение - это ключ. К сожалению, я не могу дать больше мудрости в этом вопросе (у Ларри К есть некоторые ссылки, которые могут помочь).

Я могу получить непрерывную запись 30 МБ / с на 2,5-дюймовый диск 7200 об / мин без особых усилий, поэтому я подозреваю, что вам понадобится намного больше запросов от поисковых систем, чем «сотни в секунду», чтобы превысить это. В этом случае большинство реляционных баз данных не очень хорошо справляются с большим количеством записей отдельных строк. Вот несколько альтернатив:

1. Выясните, поддерживает ли ваша СУБД какой-либо вариант пакетной или массовой вставки (классы BulkCopy сервера SQL значительно повышают производительность вставки). Поместите несколько элементов в одну партию и запишите их в фоновом режиме.

2. Удалите индексы, внешние ключи из вашей таблицы. Эти замедляющие вставки.

3. Минимизируйте объем данных, которые вам нужно записать. Возможно, у вас будет одна таблица на полчаса дня, тогда вам не нужно будет сохранять метку времени (если для агрегации требуется только полчаса разрешения). Сожмите строку поиска (может помочь gzip или даже просто UTF8). Посмотрите, может ли использование хитрого затирания битов позволить вам хранить больше данных в меньшем пространстве.

4. Отказ от СУБД в целом. Откройте файл исключительно и добавьте записи фиксированной длины. Поворачивайте файл каждые полчаса. Затем попросите какой-нибудь другой процесс (или даже другой сервер) прочитать эти файлы и объединить их при необходимости. Все СУБД теряют некоторую производительность по сравнению с простыми файлами из-за проверки типов, анализа, транзакций и т. Д. А если производительность является вашим главным приоритетом, то вам придется обходиться без всех наворотов, предоставляемых СУБД.

Answer 3

Поскольку ОП говорит (в комментарии), что «объем данных очень высок, возможно, сотни записей в секунду. Это выше, чем скорость записи на диск», похоже, что данные агрегируются из ряда сервера. Мое предложение состояло бы в том, чтобы задача хранения была распределена по отдельным серверам.

Какие интерфейсные веб-серверы вы используете? Apache имеет модуль для входа в базу данных. Или используйте log rotate и регулярно подбирайте файлы.

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

свинья: http://hadoop.apache.org/pig/

обучающее видео со свиньями: http://www.cloudera.com/hadoop-training-pig-introduction

Answer 4

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

Также предполагается, что Hadoop отлично подходит для пакетной обработки огромных файлов журналов. Однако я не думаю, что это даст вам данные в реальном времени.