nixp.ru v3.0

7 декабря 2024,
суббота,
20:51:51 MSK

10 октября 2014, 10:49

В Яндексе успешно заменили СУБД Oracle на PostgreSQL для сборщиков своей почты

2
Пример панели мониторинга PostgreSQL с графиками Graphite
Пример панели мониторинга PostgreSQL с графиками Graphite
Иллюстрация с сайта Яндекс.Мероприятия

Яндекс в качестве эксперимента в сервисе «Почта» провёл успешную замену одной из баз Oracle на свободную СУБД PostgreSQL для инструмента сборки электронной почты с других ящиков и продолжает работать в этом направлении.

На проходившей 24 сентября в Москве встрече сообщества «PostgreSQL в России» выступил с докладом Владимир Бородин, сотрудник компании «Яндекс». Тема его доклада — «История небольшого успеха с PostgreSQL». Владимир рассказал, почему решили уйти от Oracle и почему в качестве первого шага были выбраны именно сборщики, как выглядит решение и с какими трудностями пришлось столкнуться.

Было названо два основных мотива отказа от продукта Oracle: высокая цена и возможность решения ряда проблем только через поддержку компании с неопределёнными сроками. Обе ситуации могут решить свободные проекты, один из которых — PostgreSQL — и начали использовать в качестве эксперимента. Сборщики почты были выбраны по принципу минимизации ущерба в случае отказов и неудачного перехода. Основные причины выбора таковы: сборщики не были связаны с другими данными, некритичность простоя в течение нескольких минут и достаточный объём данных для тестирования.

Переход осуществлён на PostgreSQL 9.3 с использованием PL/Proxy. Самостоятельно в компании создали два инструмента и разрабатывают третий для повышения отказоустойчивости решения. Когда качество кода повысится, исходный код этих инструментов обещают открыть. Инструмент pgcheck размещается на прокси-серверах, опрашивает и анализирует состояние узлов и с помощью выставленных весов, регулирует нагрузку в шарде. Вторая утилита pgswitch — простой скрипт, который планово меняет мастера, чтобы не допустить деградации в режим «только для чтения» при потере мастера. Третий инструмент находится в тестовом режиме и получил название pgsync. Он размещается на конечных базах и может менять репликацию с синхронной на асинхронную и обратно, а также может автоматически переключать мастера без потери данных.

В целях мониторинга используется несколько проверок, в том числе количество активных сессий и свободных соединений, количество ошибок в логах за минуту и «живых» реплик, лаг реплики и т.д. Графики для мониторинга прорисовываются при помощи Graphite, а pg_stats_reporter при таких объёмах не справляется.

При переходе на PostgreSQL в Яндексе натолкнулись на следующие проблемы:

  • выделили много памяти под shared_buffer, что привело к большим пикам ввода/вывода при Checkpoint;
  • много времени уделили оптимизации дисковой подсистемы;
  • в новой схеме шардинга использовали 32 логических шарда, что привело к мультипликации одного запроса в прокси до 32 запросов к шардам (т.к. сборщики одного пользователя могли храниться на разных шардах и могли быть показаны только при запросе с RUN ON ALL на все 32 шарда). Из-за частого запроса «показать все сборщики пользователя» происходило переполнение соединениями в прокси.

Также Владимир отмечает, что в PostgreSQL для целей компании не хватает ряда возможностей:

  • интерфейс ожиданий и трассировки сессии, как в Oracle;
  • возможность выделить для shared_buffer всю память и включить O_DIRECT, как в Oracle или MySQL;
  • нормальное партиционирование;
  • полусинхронная репликация;
  • параллелизм.

По итогу доклада отмечается, что опыт перехода в целом оказался положительным и компания уже задействует PosgreSQL в других своих проектах. Подробнее с темой «История небольшого успеха с PostgreSQL» можно ознакомиться из записи доклада Владимира Бородина. Там же доступны слайды.

Постоянная ссылка к новости: http://www.nixp.ru/news/12845.html. Никита Лялин по материалам Яндекс.Мероприятия.

fb twitter vk
Филипп Корвин

Я почему-то думал, что там и так везде постгря… Хорошая новость!

tinman321

У них много где MySQL (и даже не MariaDB), но при этом используются MongoDB и другие СУБД. С PostgreSQL они как-то не очень дружили, а вот про использование Oracle я тоже не знал.