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

Question

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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