Есть записи типа А (которых 4 млн): 1. Порядковый номер 2. Хэш 3. Временная отметка 4. Набор доп. информации одинаковый для всех записей Записи типа Б(125 млн): 1. Хэш 2. Внешний ключ для связи с А (либо хэш, либо номер еще не знаю что лучше) 3. Временная отметка 4. Набор доп. информации одинаковый для всех записей Сейчас это всё в неудобном формате (можно сказать, что текстовый), а чтобы сделать запрос - нужно долго вычитывать файлы (60 GB) и в общем как-то неудобно. Для этого собственно и выбрали pg

Грубо говоря итоговая цель - по доп. информации, которую хранят сущности из Б (пусть будет IP адрес, к примеру) найти все записи с этим IP адресом и что-нибудь посчитать.

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

для этого норм подойдет ELK

Есть записи типа А (которых 4 млн): 1. Порядковый номер 2. Хэш 3. Временная отметка 4. Набор доп. информации одинаковый для всех записей Записи типа Б(125 млн): 1. Хэш 2. Внешний ключ для связи с А (либо хэш, либо номер еще не знаю что лучше) 3. Временная отметка 4. Набор доп. информации одинаковый для всех записей Сейчас это всё в неудобном формате (можно сказать, что текстовый), а чтобы сделать запрос - нужно долго вычитывать файлы (60 GB) и в общем как-то неудобно. Для этого собственно и выбрали pg

извини что влажу, а сколько места индексы занимают?

извини что влажу, а сколько места индексы занимают?

Я еще только продумываю решение, не пробовал пока даже импортировать данные

а, ок

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

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

обязательно посмотрите в сторону clickhouse

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

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

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

:))

ELK и Elastic Search как относятся друг к другу, это не одно и то же? Я просто мало очень об этом знаю, поэтому пока не рассматривал этот вариант. Почему это будет быстрее сабжа?

Одно и тоже, просто стек эластиксерч, логстеш и кибана

Быстрее будет, потому что для таких данных он и оптимизирован

ELK и Elastic Search как относятся друг к другу, это не одно и то же? Я просто мало очень об этом знаю, поэтому пока не рассматривал этот вариант. Почему это будет быстрее сабжа?

ELK аббревиатура эластик, логстеш, кибана

Кликхаус выглядит более подходящим. Можно вообще сравнивать колоночную субд с ES?

для логов кликхаус получше

elasticsearch конечно крутой поиск. но не понимаю зачем туда реальные терабайтные логи загоняют ._.

Кликхаус почитаю

Заинтриговал

elasticsearch конечно крутой поиск. но не понимаю зачем туда реальные терабайтные логи загоняют ._.

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

Кликхаус почитаю

его документация тоже быстро интригует :)

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

там не совсем логи, но что-то близкое по смыслу.

Всем спасибо, буду гуглить) с праздниками всех)

Елк просто готовое уже для сборов логов, клиехаус наверняка надо дориливать

там не совсем логи, но что-то близкое по смыслу.

главное, чтобы логически и технически архитектура для логов туда накладывалась

Елк просто готовое уже для сборов логов, клиехаус наверняка надо дориливать

да нет, он уже под это заточен как раз сразу

То есть есть аналог кибаны и логстеша?

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

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

То есть есть аналог кибаны и логстеша?

А зачем? в теории логстэш может писать куда угодно

https://github.com/mikechris/logstash-output-clickhouse

Первая строка гугла

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

Все писать свой велосипед - как то не то

а как потом грепать кликхауз?

Ну файлбит и логстэш поддерживают много всякого... а вот насчет кибаны неуверен

Только не надо, что через селект)))

https://redash.io/

любителям поинтересоваться за кликхаус милости прошу сюда @clickhouse_ru

сейчас я выбрал не использовать MyRocks, а просто в течении месяца аккумулировать новые данные в отдельную табличку без индексов (вставка будет за O(1)) А раз в месяц пушить ее в основную за O(log(N)) в санитарный день

А если попробовать неравномерный "ручной" многоуровневый partitioning. Когда данные в основном разбиты по годам, свежие данные разбиты помесячно. А в maintenance window месячные партиции мерджатся в годовую. Так можно держать число партиций на уровне приемлимом для ванильного postgres

А если попробовать неравномерный "ручной" многоуровневый partitioning. Когда данные в основном разбиты по годам, свежие данные разбиты помесячно. А в maintenance window месячные партиции мерджатся в годовую. Так можно держать число партиций на уровне приемлимом для ванильного postgres

вся загвоздка в merge будет :)

вся загвоздка в merge будет :)

Но раз в год, а не каждый месяц

Плюс можно свежие партиции класть на более быстрые диски.

да, в принципе можно, но это тоже скорость занизит на ≈10^1 т.к. напомню, что партиции придется смотреть все

Плюс можно свежие партиции класть на более быстрые диски.

нет проку: данные нужно в равной мере и старые и новые

Новые вроде в вашей схеме неиндексированные

я пока придержался методики на двух партициях...

тесты всё ещё выполняются, надеюсь через пару часов будет результ

да, в принципе можно, но это тоже скорость занизит на ≈10^1 т.к. напомню, что партиции придется смотреть все

А вы на данные pgpro о зпвисимости времени plannerа от числа партиций смотрели?

кинете? я самостоятельно прикидку делал

https://postgrespro.com/blog/pgsql/17869

Можно попробовать запись доклада поискать.

@SergeyPpro спасибо, посмотрим

там не совсем логи, но что-то близкое по смыслу.

Если прикрутить полнотекстовый поиск, то получается тот же ES, со всеми плюшками postgresql. БД логов 343Gb, 42 хоста, Макс 20 млн в сутки, Глубина в 45 суток. Посуточное партиционирование, Поиск - стремителен.

Мле

Всем привет, можете порекомендовать материал про хранения юзера в бд, процесс аутентификации ? Или все намного проще ? ( пароль храним как varchar, хэшируем через bcrypt , проверяем в приложении через select )

Всем привет, с Праздником Вас, подскажите, для сайта вот это опасно? http://prntscr.com/hx4qjc

попытка заинектить sql степень опасности зависит от кода, который засовывает это в постгрю

т.е беспокоиться не стоит, верно?

только вы знаете что у вас там внутри стоит или не стоит решать вам

ros Спасибо за ответы большое

т.е беспокоиться не стоит, верно?

У вас в запрос значение через конкатенацию подставляется?

@netneladno привет! результаты теста такие: 1. Билд индексов: 20ч 2мин 2. Вставка 3.4кк rows в таблицу без индексов: 3мин 51сек 3. Вставка 3.4кк rows в таблицу с индексами: 7ч 7мин -- Короче говоря, если пачка данных больше 10млн, то индексы таки быстрее полностью снести, вставить пачку, и построить уже...

@netneladno привет! результаты теста такие: 1. Билд индексов: 20ч 2мин 2. Вставка 3.4кк rows в таблицу без индексов: 3мин 51сек 3. Вставка 3.4кк rows в таблицу с индексами: 7ч 7мин -- Короче говоря, если пачка данных больше 10млн, то индексы таки быстрее полностью снести, вставить пачку, и построить уже...

Bloom индекс не подошёл?

@netneladno привет! результаты теста такие: 1. Билд индексов: 20ч 2мин 2. Вставка 3.4кк rows в таблицу без индексов: 3мин 51сек 3. Вставка 3.4кк rows в таблицу с индексами: 7ч 7мин -- Короче говоря, если пачка данных больше 10млн, то индексы таки быстрее полностью снести, вставить пачку, и построить уже...

И что же, Вы настройки PostgreSQL меняли на время заливки? (Кстати, этот результат про "~ 10 млн" относится только к Вашей конкретной ситуации, его даже запоминать не стоит.) ;)

Коллеги, привет. Так-как ни одного нормального ресурса с удобными поиском и большой базой IT-событий (хакатонов, конференций, вебинаров) не нашли, решили сделать свой агрегатор. Кто готов - потратьте, пожалуйста, минуту на наш Google-опросник https://docs.google.com/forms/d/e/1FAIpQLSeF62yKGrK_dA9s06MXASrGZMof2pVPsI_cBXCvKk-6BBA4-A/viewform

@netneladno привет! результаты теста такие: 1. Билд индексов: 20ч 2мин 2. Вставка 3.4кк rows в таблицу без индексов: 3мин 51сек 3. Вставка 3.4кк rows в таблицу с индексами: 7ч 7мин -- Короче говоря, если пачка данных больше 10млн, то индексы таки быстрее полностью снести, вставить пачку, и построить уже...

мда, спасибо

Коллеги, привет. Так-как ни одного нормального ресурса с удобными поиском и большой базой IT-событий (хакатонов, конференций, вебинаров) не нашли, решили сделать свой агрегатор. Кто готов - потратьте, пожалуйста, минуту на наш Google-опросник https://docs.google.com/forms/d/e/1FAIpQLSeF62yKGrK_dA9s06MXASrGZMof2pVPsI_cBXCvKk-6BBA4-A/viewform

Meetup.ru

Они за такие копейки сервис поддерживают

Полторы чашки кофе

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

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

timepad.ru например

его минус в фокусе на онлайне: при отборе по городу - он показывает и онлайн мусор

то есть вы планируете, что разработка и поддержка сайта с мероприятиями будет дешевле, чем 8 баксов в месяц?

Мы два года так проводим мероприятия не платя никому, с бюджетами 5–50 тысяч и скидываясь не деньгами а своим временем ?

ну так делайте мероприятия! Зачем вам поддержка ресурса?

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

указал что там на митапе собраны не все мероприятия и указал почему

Если прикрутить полнотекстовый поиск, то получается тот же ES, со всеми плюшками postgresql. БД логов 343Gb, 42 хоста, Макс 20 млн в сутки, Глубина в 45 суток. Посуточное партиционирование, Поиск - стремителен.

запутался - куда поиск прикручивать?

запутался - куда поиск прикручивать?

logs=# \dS log__20180101 Таблица "public.log__20180101" Столбец | Тип | Модификаторы —--------+--------------------------+------------— snd_date | timestamp with time zone | rcv_date | timestamp with time zone | host | text | facility | text | level | text | program | text | source | text | pid | text | message | text | tsv | tsvector | Индексы: "log__20180101_host_idx" btree (host) "log__20180101_level_idx" btree (level) "log__20180101_rcv_date_idx" btree (rcv_date) "log__20180101_snd_date_idx" btree (snd_date) "log__20180101_tsv_idx" gin (tsv) Ограничения-проверки: "partition_check" CHECK (rcv_date >= '2018-01-01 00:00:00+09'::timestamp with time zone AND rcv_date < '2018-01-02 00:00:00+09'::timestamp with time zone) Триггеры: tsvectorupdate BEFORE INSERT OR UPDATE ON log__20180101 FOR EACH ROW EXECUTE PROCEDURE tsvector_update_trigger('tsv', 'pg_catalog.english', 'message') Наследует: all_events

запутался - куда поиск прикручивать?

Если вкратце - то при вставке записи отрабатывает триггер, который в столбцец tsv складывает вектор сформированный из message. На столбце построен Gin индекс, по которму и идёт поиск.

Мы два года так проводим мероприятия не платя никому, с бюджетами 5–50 тысяч и скидываясь не деньгами а своим временем ?

С бюджетом в 5 тык в ресторане даже нормально одному не поесть. У вас что на квартире чтоли люди собираются и со своим приходят?

С бюджетом в 5 тык в ресторане даже нормально одному не поесть. У вас что на квартире чтоли люди собираются и со своим приходят?

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

Всем привет

Bloom индекс не подошёл?

нет :(