Comments 8
Я так понимаю, autovacuum тоже подкрутили или вообще отключили? Можете рассказать на каких настройках остановились?
Сборщик логов лезет по ssh и читает логи, используя tail -f? Шта? rsyslog — не не слышали?
Получение данных с сервера БД — проброс порта с использованием SSH и затем выполнение запроса «локально»? Нахуа? Вы не умеете настраивать pg_hba.conf? И еще, если я все правильно понимаю, то у какого-то софта есть возможность ползать по продуктивным серверам БД с использованием SSH? А у вас там есть отдел или служба ИБ, или тоже не слышали?
И вишенкой на торте будет попытка впихнуть невпихуемое. Я ведь все правильно понимаю, Вы берете неструктурированные данные (логи ведь не являются структурированными данными), пихаете их в реляционную СУБД, при этом, чтобы работало, Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной. Сверху вы прикручиваете балансировщик, который балансирует запись в БД.
А у вас в команде есть PostgreSQL dba? который вам попытался или не попытался сообщить, что вы занимаетесь фигней… Хотя глупый вопрос, если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствует, либо он не dba.
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?
Кроме шуток. Мне очень интересно, сколько ресурсов вы затрачиваете на обсуживание всего этого, ну и поток данных, который вы обрабатываете? или может быть есть результаты нагрузочного тестирования? Я просто хочу сравнить с нашими объемами, быть может все то, что Вы сделали, действительно жрет меньше, обходится дешевле, и я просто ничего не понимаю в реализации обработки логов.
Получение данных с сервера БД — проброс порта с использованием SSH и затем выполнение запроса «локально»? Нахуа? Вы не умеете настраивать pg_hba.conf? И еще, если я все правильно понимаю, то у какого-то софта есть возможность ползать по продуктивным серверам БД с использованием SSH? А у вас там есть отдел или служба ИБ, или тоже не слышали?
И вишенкой на торте будет попытка впихнуть невпихуемое. Я ведь все правильно понимаю, Вы берете неструктурированные данные (логи ведь не являются структурированными данными), пихаете их в реляционную СУБД, при этом, чтобы работало, Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной. Сверху вы прикручиваете балансировщик, который балансирует запись в БД.
А у вас в команде есть PostgreSQL dba? который вам попытался или не попытался сообщить, что вы занимаетесь фигней… Хотя глупый вопрос, если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствует, либо он не dba.
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?
Кроме шуток. Мне очень интересно, сколько ресурсов вы затрачиваете на обсуживание всего этого, ну и поток данных, который вы обрабатываете? или может быть есть результаты нагрузочного тестирования? Я просто хочу сравнить с нашими объемами, быть может все то, что Вы сделали, действительно жрет меньше, обходится дешевле, и я просто ничего не понимаю в реализации обработки логов.
Немного лирики…
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»
Собирать логи? Только Kafka + ElasticSearch! Мониторинг? Только Grafana и агент! Хранилище со статистикой? Только ClickHouse! Система очередей? Только RabbitMQ!
Почему-то очень редко после этого возникает мысль «А ведь это просто один из возможных инструментов. А у тех есть свои недостатки.» — и если другой инструмент решает задачу и делает это хорошо и эффективно — почему нет?
А теперь по делу:
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»
Собирать логи? Только Kafka + ElasticSearch! Мониторинг? Только Grafana и агент! Хранилище со статистикой? Только ClickHouse! Система очередей? Только RabbitMQ!
Почему-то очень редко после этого возникает мысль «А ведь это просто один из возможных инструментов. А у тех есть свои недостатки.» — и если другой инструмент решает задачу и делает это хорошо и эффективно — почему нет?
А теперь по делу:
- под мониторингом сейчас стоит примерно 1500 PG-хостов
- «сырых» логов генерируется суммарно примерно 230GB/сутки
- обработанной аналитики еще примерно 250GB/сутки
- суммарный формируемый в базу поток порядка 15-20K rows/sec или 200-250Mbps
- нагрузка на единственном сервере БД: CPU 5-7% (56 core), 2-3Kiops, 60MB/s
- нагрузка на паре коллекторов: CPU 25-40% (8 core)
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?Мы любим велосипеды, как и другие компании. Потом из них появляются, например, такие вещи как React, Bootstrap, Chrome, AWS.
1500 PG-хостов и 15-20К rows/sec — это всего 10-13,(3) rows/sec с одного PG-хоста, при этом 200-250Mbps, т.е. на 1 row приходится около 1,5-3MB данных???
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.
Непонятна мне Ваша лирика.
Да и меня смущает другое, зачем Вы используете то, что не предназначено для этой задачи?
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»Это Ваш личный девиз или Вы лично следуете этому постулату? Или это чье-то высказывание? не вижу копирайта.
Непонятна мне Ваша лирика.
Да и меня смущает другое, зачем Вы используете то, что не предназначено для этой задачи?
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.Да, но это получилось удачно взять «на вырост». Но несколько рефакторингов с тех пор снизили нагрузку кратно, несмотря на увеличение количества анализируемых хостов, поэтому продолжаем жить на том же железе.
tail -f? Шта? rsyslog — не не слышали?
Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной
если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствуетМожет, мне показалось, но это явно прозвучало как «неканон!»
на 1 row приходится около 1,5-3MB данных???200Mbps / 15Krps =~ 13.3Kb/row =~ 1.7KB/row
Может, мне показалось, но это явно прозвучало как «неканон!»Я не знаю, что значит «неканон», но я знаю, что есть более яркий пример — шуруп и молоток, т.е. все знают, что шурупы закручивают/заворачивают/ввинчивают, знают даже какой отверткой, шлицевая или крестовая, в зависимости от головки, но есть те, кто упорно пытаются забить шуруп молотком. Почему они это делают? Скорее всего потому, что умеют пользоваться только молотком, либо у них нет отверток. Конечно это можно сделать и молотком, но это потребует больше усилий, да и результат будет явно не такой, какой ожидается от вкрученного шурупа.
Но вы, конечно же, можете забивать шурупы молотком, объясняя свое поведение тем, что это просто иной, более прогрессивный, подход.
это потребует больше усилий, да и результат будет явно не такой, какой ожидается от вкрученного шурупаВот это я и имел в виду под «смотри, вот так можно эффективнее!»
Наши цифры приведены выше. PostgreSQL отлично себя показывает как хранилище структурированной информации с большой пропускной способностью на запись. При этом мы по-прежнему располагаем всем функционалом PG-экосистемы. В частности, имеем к нему SQL-доступ и практически мгновенную отзывчивость по всем отчетам в заранее заданных разрезах.
Если Ваше решение эффективнее — расскажите о нем, будет очень интересно сравнить. Потому что пока совсем непонятно, какой именно результат Вы ожидаете от «шурупа», и что с чем сравниваете, потому что пока выглядит как утверждение «все шурупы надо завинчивать только крестовой отверткой».
Sign up to leave a comment.
Телепортация тонн данных в PostgreSQL