LINUX.ORG.RU

1*10⁶ записей в сутки - как хранить, анализировать накопленное за пару лет?

 


0

2

Есть некая система в которую приходят некие сообщения (время, всякие там данные в float), сии сообщения пока что приходят в объеме 200тыс в сутки, но в дальнейшем планируется нагрузка и в миллион, а то может быть и более.

Сообщения надо обрабатывать, фильтровать, конвертировать, а потом сохранять... на годы (может на пару лет), и уметь быстро по сохраненным данным строить отчеты, графики, диаграммки.

Собственно вся кухня ныне успешно работает на одном сервере, и хранится все это дело в одной таблице субд, с индексами но без внешних ключей, однако с 30млн записей (там сейчас столько) мне не нравится время выборки более менее сложных отчетов.

Вопрос:

- как лучше хранить

- как обрабатывать (вытекает из ответа на предыдущий), банальные реляционные субд ээ немного убоги своим SQL (чтобы мне выбрать данные на основе предыдущего анализа лога приходиться делать временную таблицу, хорошо если одну)

- как бы реализовать очереди, всяких технологий MQ валом, но у меня идет рассылка сообщений сторонним серверам, которые часто падают, виснут, да и интернет тоже, в итоге надо как то сохранять не отправленное в файле (сервер может лежать неделями) а затем потихонечку, дабы не уронить сторонний сервер, сливать туда данные. Прозреваю, что с учетом нагрузки лучше всего будет что-то простое с файлами, но рисовать велосипед некогда.



Последнее исправление: belous_k_a (всего исправлений: 1)

все это дело в одной таблице

с индексами но без внешних ключей

я не большой спец, но разве это возможно?

однако с 30млн записей (там сейчас столько) мне не нравится время выборки более менее сложных отчетов

ну дайте пример что ли

ZuBB ★★★★★
()

Партицируешь записи посуточно и сохраняешь (в уже обработанном и отфильтрованном виде) в какой-нибудь hadoop, далее графики можно строить mapreduce'ом.

Reset ★★★★★
()

Про хранение данных не скажу, но вот тут:

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

явно описан алгоритм работы почтового сервера :)

cdslow ★★
()
Ответ на: комментарий от cdslow

явно описан алгоритм работы почтового сервера :)

Почтовый сервер в данном случае слишком жирно, нужно наваять банальную очередь.

belous_k_a
() автор топика

Уйди отсюда... на sql.ru ступай, помогут тебе там, если помощи хочешь ты...

xterro ★★★★★
()
Ответ на: комментарий от cdslow

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

belous_k_a
() автор топика

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

Вариант второй: все держишь в файлах и пишешь свою прибулуду для аггрегации и анализа (делал так для эмбед проекта).

Вариант третий: Handoop и к нему писать свои приблуды для графиков

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

Sigrlami
()
Ответ на: комментарий от Sigrlami

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

У нас кластер из одной машины. И анализ в терминах mapreduce также потребует хранения промежуточных результатов.

belous_k_a
() автор топика
Ответ на: комментарий от buddhist

О на примере mongodb я его ощутил, для анализа нам надо отфильтровать данные по хитрому критерию, настолько хитрому что простой запрос его не осилит:

-в обычной базе нам надо выгружать тонны данных на клиента и там выбирать что приглянулось

-в mapreduce мы не транспортируем данные к коду, а транспортируем код к данным, на примере mongodb -> фильтр пишется на js, в итоге - бешеный выигрыш на перепихивании ненужных данных.

belous_k_a
() автор топика
Ответ на: комментарий от buddhist

Профит малый. Но из исходного сообщения я сделал вывод, что производительность не устраивает, а хочется увеличивать объемы в разы и скорость.

Reset ★★★★★
()
Ответ на: комментарий от belous_k_a

Если разработчик системы не ты , то отличный повод выпросить мощный сервер и быстрый строрадж. разработчики системы должны были позаботиться о таких вещах, как организация хранения данных, заранее.

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

В топике какраз вопрос о организации хранения, а не о серверах, Вы как специалист не моглибы всетаки просветить меня именно на тему _организации хранения_ ?

belous_k_a
() автор топика

я события складываю в какой нить хранилище и насчитываю статистику в реальную бд

namezys ★★★★
()
Ответ на: комментарий от namezys

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

belous_k_a
() автор топика
Ответ на: комментарий от namezys

Почему хадуп, этож не бд, а какркас из mapreduce и hdfs

там придется озадачиваться велосипедами из своего формата хранения и индексирования.

belous_k_a
() автор топика
Ответ на: комментарий от belous_k_a

две таблици , одна для оперативных данных с некой глубиной хранения , которая не влияет на производительность. Вторая архивная в которую переносятся данные из первой. не подходит?

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

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

Разделение на архив неприменимо - оперативные данные сидят в памяти, а сама база по сути и есть большой архив.

belous_k_a
() автор топика
Ответ на: комментарий от namezys

индексирование? А оно возомжно?

Ну вручную - да, возможно что в этой фс есть что-то встроенное но это надо документацию курить.

belous_k_a
() автор топика
Ответ на: комментарий от ukr_unix_user

они же должны были сказать что нужен ещё и DW, для всяких там отчётов.

wtf DW?

для отчетов нужно все это отфильтровать\агрегировать до пары десятков строк, тогда желающие могут хоть в блокноте строить отчет. В том собственно и задача.

belous_k_a
() автор топика
Ответ на: комментарий от namezys

Сейчас да, производительность на запись пока хватает даже для вставки без удаления индексов.

belous_k_a
() автор топика
Ответ на: комментарий от belous_k_a

Можешь посмотреть на вариант, который используется в zabbix, там есть таблица trends, в которой хранятся уже посчитанные значения за некий период, тогда отчеты можно строить на такой таблице.

wtf DW?

Data warehouse

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

Можешь посмотреть на вариант, который используется в zabbix, там есть таблица trends, в которой хранятся уже посчитанные значения за некий период, тогда отчеты можно строить на такой таблице.

Это предварительная аналитика, уже предлагалась: 1*10⁶ записей в сутки - как хранить, анализировать накопленное за пару лет? (комментарий) ниже ответ

Если останется реляционка, то сей вариант будет в виде «кеша» (и то он покроет лишь один тип отчетов) но пока он ненужен.

belous_k_a
() автор топика
Ответ на: комментарий от belous_k_a

реализуя подобные системы, рискуете навсегда остаться заложником хотелок, которые не всегда идут в ногу со здравым смыслом. в итоге «скуэльщики» переделают всё по своему и все будут довольны.

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

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

belous_k_a
() автор топика
Ответ на: комментарий от belous_k_a

который, тупо _хочет_, и здравый смысл ему ненужен

Чего тогда голову ломать? «идеальный» заказчик! Cделай как получится , а потом по пути мощных(дорогих) серверов и быстрых(дорогих) стораджей.

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

Чего тогда голову ломать?

Навалять кучу г-на я всегда успею. А пока по принципу тов. Сухова: лучше конечно помучиться.

belous_k_a
() автор топика
Ответ на: комментарий от belous_k_a

и всё таки «с индексами но без внешних ключей, однако с 30млн записей (там сейчас столько) мне не нравится время выборки более менее сложных отчетов»

название СУБД , структуру таблицы и запросы увидим?

ukr_unix_user ★★★★
()
Ответ на: комментарий от belous_k_a

Читал я про эти ваши nosql, там при отключении света случается «прощай база».

Couchdb не портится от неправильного выключения. Проверено.

anonymous
()

А вы бы не могли рассказать хоть немного подробнее какие прилетают данные и какого рода нужны отчеты? Насколько непредсказуемы эти отчеты?

У меня был опыт хранения и обработки большого количества данных. Начиналось это приблизительно так же - таблица в РСУБД(PostgreSQL), какой-то набор индексов к ней, но быстро выяснилось что это ужасно неэффективно. Во-первых PostgreSQL требует гораздо больше места на диске чем сырые данные, во-вторых на некоторых видах отчетов простое индексирование не работает, оптимизатор из-за low selectivity выбирает sequence scan, и все становится медленно и печально.

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

У сырых данных есть время начала и окончания замера, и файлы с ними хранятся с именами %04x%04x.dat. Первые 4 символа - (epoch начала) << 18, потом (epoch окончания) << 18. 2**18 секунд - это около 3-х суток, предполагалось что замеры короткие и за год будет порядка 100 файлов. На самом деле получается около 300, это тоже нормально. Так вот, когда пользователь строит «медленный» отчет, выбираем только те файлы (т.е. периоды времени), которые ему нужны. Показываем прогресс-бар, перечитываем эти файлы полностью и строим отчет.

Вам, возможно, тоже подойдет (в какой-то степени) такая схема. Ну, может быть вместо времени в имени файлов можно будет использовать какие-то другие ключи или их комбинацию

anonymous
()
Ответ на: комментарий от anonymous

Черт, epoch >> 18. То есть дату(unix epoch) делим на 2**18 секунд, или «округляем» к 3-м суткам. Понятно, что это произвольная такая цифра, но мне в какой-то момент она показалась разумным компромиссом между количеством файлов в каталоге и перечитыванием «лишних» данных не за заданный пользователем период

anonymous
()
Ответ на: комментарий от ukr_unix_user

Нет, не увидим, ибо задача не как сделать существующее лучше, а как в принципе это делать.

belous_k_a
() автор топика
Ответ на: комментарий от anonymous

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

Причем эта схема ложится на всякие там mapreduce.

belous_k_a
() автор топика
Ответ на: комментарий от anonymous

А вы бы не могли рассказать хоть немного подробнее какие прилетают данные и какого рода нужны отчеты?

С ботнета, походу, данные собирают. :)

Reaper ★★
()

Потоки netflow храните ? :)

Мы их хранили в виде агрегированных данных. Агрегация происходит специально написанной программой на java. В базе хранить полные данные глупо, да и не нужно. Когда хранили все данные в бд - агрегация происходила за 3-5 часов, а программа на java справляется за 10 минут.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

Потоки netflow храните ? :)

нет, агрегация в моем случае возможна но даст 1-2% выигрыша по количеству записей.

belous_k_a
() автор топика

однако с 30млн записей (там сейчас столько) мне не нравится время выборки более менее сложных отчетов

если вы не собираетесь «кластеризоваться», и если на данный момент вас не устраивает _только_ скорость выборок, то (имхо) весь nosql (ну за исключением «low level» а-ля BerkeleyDB - смотрели?) идёт в сад, и если любое «пред-агрегирование» невозможно (с ваших слов), то только тюнинг бд (индексов и т.д.) и запросов (чтоб никакого скана).

yyk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.