Вопрос для Viks (PostgreSQL vs MySQL for Zabbix).

[rwx]

Добрый день,Viks.
В этом топике https://www.zabbix.com/forum/in-russ...82%D0%BE%D0%B2
вы рекомендовали использовать для Zabbix PostgreSQL вместо Mysql/MariaDB/etc...
Не могли бы вы раскрыть тему по подробнее:
1.Почему вы рекомендуете PostgrSQL вместо MySQL/MariaDB.
2.Как измениться профиль нагрузки сервера при переходе с MariaDB на PostgreSQL(нагрузка CPU, потребление памяти, дисковый IO, IOPS).
Спасибо.
P.S. Прошу форумчан не воспринимать данную тему как повод для холивара.
Хоть и вопрос для viks, прошу остальных имеющих опыт переезда БД MySQl => PostgreSQL так же отписаться о своем опыте.

[astrix89]

По всей видимости Viks не полностью использовал возможности MySQL/MariaDB/Percona
Вот вам для наглядности несколько графиков:
База данных, все графики будут за месяц:
Версия заббикса 3.4.12
2xCPU E5-2670 64GB RAM
ЦПУ:


Диски:
Массив sdb: Hard RAID 10 4x300 SAS 10k


Массив sdc: Hard RAID 10 4x8TB SATA


База MariaDB, движок таблиц history, history_uint, history_log, history_text, history_str, trends, trends_uint TokuDB, остальные InnoDB.

my.cnf()
innodb_lock_wait_timeout=36000
innodb_buffer_pool_size=12G(на самом деле можно и меньше)
innodb_buffer_pool_instances=4
innodb_flush_method=O_DSYNC
innodb_log_file_size=256M
innodb_max_dirty_pages_pct=0

tokudb_cache_size=4G

Сервер с ядром заббикса: Состояние Zabbix

Zabbix сервер запущен	Да	x.x.x.x:10051
Количество узлов сети (активированных/деактивированных/шаблонов)	25265	25039 / 23 / 203
Количество элементов данных (активированных/деактивированных/неподдерживаемых)	5141162	5081472 / 1460 / 58230
Количество триггеров (активированных/деактивированных [проблема/ок])	2208868	2207136 / 1732 [190849 / 2016287]
Количество пользователей (в сети)	104	10
Требуемое быстродействие сервера, новые значения в секунду	18336.47

2xCPU E5620 48GB RAM
ЦПУ:




Суть в чем, таблици history, history_uint, history_log, history_text, history_str, trends, trends_uint сегментированы по 12 часов, всежие сегменты таблиц висят в разделе в оперативной памяти(SSD? не не слышал). Каждые 12 часов в определенное время стопается база, заполненые сегменты переносятся на жетские диски, создаются символьные ссылки для них в раздел, который в оперативке(в это время заббикс сервер замерает, но не прокси), далее база запускается и заббикс всю накопленную историю начинает записывать(разрывов в графиках нет). По времени процесс переноса сегментов таблиц заниметс около 1-2 минут. Процесс заливки метрик в базу с заббикса занимает еще 10-15 мину, при этом самое большое отстование по времени будет как раз эти 1-2 минуты, и в течении 10-15 минут полностью устраняется.
Какие плюсы: жестко разделены зоны записи и чтения данных, у вас не получится так что из-за того, что кто-то начинает смотреть графики проседает history index и write cache.
Какие минусы: некоторый простой(1-2 минуты каждые 12 часов). Вообще сейчас я разрабатываю методику подключение второй базы через ProxySQL, если все получится, будет некий горячий кэш с конфигом и минимально нужным временным отрезком метрик, и полная копия базы. Теоретически при таком подходе можно будет снять 40-60k NVPS без SSD.

[astrix89]

ЦПУ с сервера ядра заббикса(не дает больше 5 пикчей прикреплять форум)

[max.ch.88]

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

[astrix89]

Уменьшился размер таблиц примерно в 3-6 раз(файлов таблиц), использовал алгоритм сжатия tokudb_snappy(оптимально на текущий момент по скорости запаковки/распаковки данных), соответственно можно дольше хранить таблицы history и history_uint. Спала нагрузка на цпу. Более того, теперь я имею 2 отдельных кэша данных, один грубо говоря для конфига с событиями, второй для метрик.
3 железных сервера, база, ядро, самый большой прокси(на нем снимаются метрики с 17к хостов), остальные это виртуализация.
Храню историю следующим образом: таблицы history и history_uint с глубиной в 11 дней, остальные() видимо вечно, или около того.
Housekeeper выпилил практически полностью, а то что он там чистит практически не заметно.

[rwx]

astrix89, вам спасибо за информацию. Плохо, что никто с опытом работы с PostgreSQL не отписался. У нас сейчас все на mariadb 10.1 БД - 140 Гб, innodb. При работе housekeeper мы утилизируем диск практически полностью(ssd, raid1), что сказывается на работе с WEB интерфейсом. Технологический простой (даже двухминутный, как у вас) невозможен. При этом даже на секционирование перейти не получиться - некоторые данные нужны за год(основная чать храниться 60 дней). Есть мнение, что PostgreSQL будет меньше нагружать дисковую систему. Вопрос будет так или нет и какой будет выигрыш - пока открытый. В связи с чем и ищу информацию по работе zabbix с PostgreSQL.

[astrix89]

Без разницы, housekeeper будет поедать диски на ура что на постгресе что на мускуле. Попробуйте проанализировать как часто метрики просматриваются, и на какую глубину. Больше чем неделю "деталку" хранить особого смысла нет, по крайне мере у нас.
Я бы на вашем месте попробовал использовать движек TokuDB, а с вашим объемом данных так это за час-полтора можно сделать.
П.С. посмотрел сколько чего пишется, оказалось около 50ГБ за 24 часа...

[max.ch.88]

astrix89, каков общий размер вашей базы?
rwx, есть рекомендации разработчика для больших баз - отключить кипер и сделать партиционирование. по другому никак.
у меня база mariadb 3ТБ и тормоза из-за iowait на селектах. всё на виртуализации. подозреваю, что она то и виновата в тормозах, но нет доказательств. конвертацию такого объёма на PostgreSQL плохо представляю. поэтому ищу аналог pgbouncer для mariadb.

[astrix89]

Около 1 ТБ(за 7 месяцев работы в проде).

[max.ch.88]

Если кто-нибудь использовал в проде proxySQL, поделитесь результатами. Ускорило работу приложения? Надежно?

[astrix89]

max.ch.88 кстати да, а вы каким образом бекап делаете? Классический mysqldump не работает адекватно с таблицами events и event_recovery, в тупую сливать каждый раз 50гб что-то не сильно хочется.

[max.ch.88]

https://www.percona.com/software/mysql-database/percona-xtrabackup

[astrix89]

https://www.percona.com/software/mys...ona-xtrabackup

Увы, данный вариант не подходит, так как используется движек TokuDB для самых жирных таблиц.
Вообщем проблему это решили, зачем бекапить все, когда можно каждый раз выдергивать определенный кусок истории?
Хотя с таблицами events и event_recovery такой подход не пройдет, если попытаться выдергивать данные по полю clock, запрос может висеть больше чем копируемый временной интервал.