А то редакторы и копирайтеры местами поломали смысл. Ну и откровенные ошибки есть. Например, trench вместо range или web-интерфейс вместо wait-интерфейса.
Начнём с того, что речь не про сообщество PostgreSQL, а про mainteiner'ов одного околопостгрешного проекта (barman). И все эти ребята работают строго в одной компании (2ndQuadrant-it).
И мы (люди снаружи) прислали им патч с реализацией крутой фичи, в лучших традициях open source разработки. А они не удосужились за год на него посмотреть. Имеют право, конечно, но IMHO как-то некрасиво.
Все последующие ваши рассуждения мне не очень понятны.
Во-первых, партиций много не создашь, время планирования сильно деградирует. Во-вторых, нужен триггер на insert.
Эти проблемы решает pg_pathman, который мы используем в одном проекте (на наш взгляд он пока сыроват, но ребята оперативно его штопают), и нормальный partitioning, который закоммитили в 10-ую версию.
В-третьих, теряется ссылочная целостность на секционируемые таблицы, что не есть хорошо.
В-четвёртых, далеко не все запросы в таблички с письмами делаются с фильтром по полю, по которому производится секционирование. И эту проблему без изменения логики приложения не победить.
Вы правда считаете, что Яндекс много лет жил почтой на оракле и до сих пор живёт другими сервисами без хорошей экспертизы в оракле!? Если да, то я вас разочарую, вы ошибаетесь.
Что касается архитектуры, то не всё мы рассказывали/рассказываем. И потому это всё было в формате доклада на конференциях, а не статьи на Хабре, чтобы на какие-то вопросы можно было ответить в кулуарах, а не публично.
Ну, мы вроде и так вклад вносим. В barman, pg_repack, pg_rewind есть наше участие. В самом postgres'е при нашем активном участии в 9.6 появились зачатки wait interface'а. Надеюсь, дальше будет больше :)
Вам уже ответили комментарием ниже. Сложный проект за долгие годы активного развития умеет обрастать костылями.
В докладе честных два слайда про причины и слайд с результатами, там ведь всё расписано. Кроме денег получили более простой deploy кода и нормальные разработческие окружения. Попробуйте, например, оракл в докер засунуть.
Железо действительно разное и сравнивать его сложно. Из плюшек получили больше реплик, с которых обслуживаем часть нагрузки, меньшую зависимость от падения конкретной машинки и, главное, уход от вертикального масштабирования к горизонтальному.
Вся история происходила в 2012-2016 гг. И утверждение про слабую применимость NoSQL (особенно нахваливаемой вами MongoDB) для нашей задачи всё ещё актуально и в 2017-м.
SE мы рассматривали как альтернативу, но сейчас можно уверенно сказать, что мы сделали правильный выбор.
Да, это был более сложный путь, но не надо думать, что для SE не пришлось бы ничего переделывать. И потом оно, конечно, дешевле EE, но прямо скажем, не бесплатно :)
Declarative partitioning — https://www.depesz.com/2017/02/06/waiting-for-postgresql-10-implement-table-partitioning/ — в 10-й версии должен решать первые две проблемы.
Для тех, кто впервые увидел этот материал, очень рекомендую посмотреть слайды — https://simply.name/ru/slides-pgday2016.html — или лучше видео (только на английском) — https://simply.name/video-pgcon2016.html.
А то редакторы и копирайтеры местами поломали смысл. Ну и откровенные ошибки есть. Например, trench вместо range или web-интерфейс вместо wait-интерфейса.
Сотрудничество с Oracle и не заканчивалось. Он используется в других проектах Яндекса.
Решение проблем 1-3 из моего предыдущего комментария.
Начнём с того, что речь не про сообщество PostgreSQL, а про mainteiner'ов одного околопостгрешного проекта (barman). И все эти ребята работают строго в одной компании (2ndQuadrant-it).
И мы (люди снаружи) прислали им патч с реализацией крутой фичи, в лучших традициях open source разработки. А они не удосужились за год на него посмотреть. Имеют право, конечно, но IMHO как-то некрасиво.
Все последующие ваши рассуждения мне не очень понятны.
Нет. Мы, конечно же, используем встроенную поточную репликацию.
Успели, натоптались граблей и больше не использовали.
Команда бэкенда почты сильно больше. Но во время миграции сделали и запустили много несвязанного с переездом, потому и человеко-годы.
Во-первых, партиций много не создашь, время планирования сильно деградирует. Во-вторых, нужен триггер на insert.
Эти проблемы решает pg_pathman, который мы используем в одном проекте (на наш взгляд он пока сыроват, но ребята оперативно его штопают), и нормальный partitioning, который закоммитили в 10-ую версию.
В-третьих, теряется ссылочная целостность на секционируемые таблицы, что не есть хорошо.
В-четвёртых, далеко не все запросы в таблички с письмами делаются с фильтром по полю, по которому производится секционирование. И эту проблему без изменения логики приложения не победить.
Вы правда считаете, что Яндекс много лет жил почтой на оракле и до сих пор живёт другими сервисами без хорошей экспертизы в оракле!? Если да, то я вас разочарую, вы ошибаетесь.
Что касается архитектуры, то не всё мы рассказывали/рассказываем. И потому это всё было в формате доклада на конференциях, а не статьи на Хабре, чтобы на какие-то вопросы можно было ответить в кулуарах, а не публично.
Рассматривали, хотя в то время были только XC и XL на базе 9.2. Но даже текущие решения не выглядят довольно стабильными для OLTP.
Нет, нельзя, это сломает point in time recovery. Кроме того, уже есть WAL (в postgres'е бинарный), который мы храним.
Вся логика переноса — это ~ 5k строчек кода на питоне.
Ну, мы вроде и так вклад вносим. В barman, pg_repack, pg_rewind есть наше участие. В самом postgres'е при нашем активном участии в 9.6 появились зачатки wait interface'а. Надеюсь, дальше будет больше :)
Не было задачи избавиться от legacy. Просто решили, что переезд на postgres — это хороший шанс упростить себе жизнь в будущем.
Вам уже ответили комментарием ниже. Сложный проект за долгие годы активного развития умеет обрастать костылями.
В докладе честных два слайда про причины и слайд с результатами, там ведь всё расписано. Кроме денег получили более простой deploy кода и нормальные разработческие окружения. Попробуйте, например, оракл в докер засунуть.
Железо действительно разное и сравнивать его сложно. Из плюшек получили больше реплик, с которых обслуживаем часть нагрузки, меньшую зависимость от падения конкретной машинки и, главное, уход от вертикального масштабирования к горизонтальному.
Вся история происходила в 2012-2016 гг. И утверждение про слабую применимость NoSQL (особенно нахваливаемой вами MongoDB) для нашей задачи всё ещё актуально и в 2017-м.
SE мы рассматривали как альтернативу, но сейчас можно уверенно сказать, что мы сделали правильный выбор.
Да, это был более сложный путь, но не надо думать, что для SE не пришлось бы ничего переделывать. И потом оно, конечно, дешевле EE, но прямо скажем, не бесплатно :)
Это ведь была не статья, а доклад, ограниченный по времени. 3 года за 40 минут рассказать сложно :)
А вообще о некоторых вещах мы отдельно рассказывали и на эти доклады ссылки есть.