Как стать автором
Обновить

Комментарии 119

Свитер просто класс!!! Наконец то true админ с докладом, а не хз кто, со следами смузи на бороде.
На свитере комета обходит по орбите звезду, направляясь дальше с лёгким смещением.
Ещё мы очень хотим нормальную работу с диском. В плане дискового I/O PostgreSQL сильно проигрывает Oracle.

А кто-нибудь может "развернуть" это предложение, что именно не так с I/O PostgreSQL?

у оракла есть многоблочное чтение (scattered read), когда по DMA одной SCSI командой достает 128 блоков напрямик в память.
И в отличии от Oracle postgresql слой чтения данных с диска в буффер ОС не оптимизирует никак (оставляет на откуп операционной системе) — это так задумано специально. Так что, можно, наверное, крутить настройки монтирования файловой системы.

P.S. Давно это было… мог и соврать.
Т.е. при full table scan PostgreSQL читает данные одноблочным чтением?
у оракла есть многоблочное чтение (scattered read), когда по DMA одной SCSI командой достает 128 блоков напрямик в память.

А под какой ОС он это умеет? В linux например можно работать с блочными устройствами напрямую минуя кэши из user-space, но штатного интерфейса для работы с DMA из user-space не предусмотренно.

в linux не знаю, знаю в windows они ReadFileScatter пользуют из win api. оно им мимо всяких кешей файлововой системы читает прямо в память. а у постгреса выходит еще и двойное кеширование, один раз кеширует файловая система второй раз постгесовский кеш.
под линухом точно умеет

Под нашей нагрузкой postgres по I/O проигрывал в 4 раза. И как показал PGCon 2016, разработчики postgres'а в курсе всех проблем.


Например, нельзя отдать без малого всю память под разделяемый кэш, потому что алгоритм вытеснения буфера очень паршивый. Приходится активно использовать page cache, которым сложно управлять + двойное кэширование. Или нет нормального асинхронного I/O, потому что поддерживается 100500 платформ, во многих из которых этого и близко нет.

Статья позитивная очень. Прочитал с удовольствием. Спасибо.
Вот только… Практический каждый параграф просто просится развернуться в отдельную техническую статью :)

Это ведь была не статья, а доклад, ограниченный по времени. 3 года за 40 минут рассказать сложно :)


А вообще о некоторых вещах мы отдельно рассказывали и на эти доклады ссылки есть.

После этого поста агрессивные психопаты набежали в комментарии пулл-реквеста barman:


нашим только дай повод побузить, надо или не надо… лучше бы помогли убедить разрабов в необходимости разработки ребят из яндекса…
Ой, не надо ныть. После такой лени и вывода автора «наглые ребята» стоило дать им пинка

Ох, Myötähäpeä сплошная.

>>Всего у нас это заняло 3 календарных года, но мы потратили больше 10 человеко-лет.
Т.е. вас не менее 4-ёх человек.
Не обязательно. Может быть они чем-то кроме «этого» занимались. Да и 10 человеко-лет — это рабочее время.
т.е. не менее 16 человек… (10/(3*((247-20)/365)*(8/24))) ничего не забыл?

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

Ребята из Oracle не приходили с предложениями возобновить сотрудничество на новых условиях?

Сотрудничество с Oracle и не заканчивалось. Он используется в других проектах Яндекса.

Раньше деплой на Oracle выполнялся прямой компиляцией и приводил к проблемам с library cache, как я понимаю. Успели ли попробовать Edition Based Redefinition?
Наверно нет, потому что в 11R2 эта фича работала с некоторыми нюансами, из-за чего ее редко пользуют.

Успели, натоптались граблей и больше не использовали.

а почему не поехали сперва на standart edition? оно же сильно дешевле и переписывать почти ничего не пришлось бы…
Обычно ответ зачем нужен enterprise edition — hot standby.
ну в статье говориться что стендбай для красоты стоял: Мы стали делать базы поменьше и по две реплики в каждом шарде. Это позволило нам заворачивать читающие нагрузки на реплики. То есть в Oracle всё обслуживалось с мастера
Он ждал своего звездного часа, чтобы когда мастер упадет самому стать мастером :)
вобщем вопрос так и повис в воздухе, чего SE редакцию не поставили?
явно было бы на порядок дешевле переезда на постгрес
а менять одну рсубд на другую путь в никуда, яндексу явно надо было куда-то в сторону бигдата смотреть, hadoop/spark скорее всего
Навряд ли на порядок дешевле постгреса.
У них явно не 30 ядер работают, а раза в 2-3 больше. 15-20 процев, на пальцах.
Стоимость SE на несколько лет все равно была бы под полляма.
Минус партиции, которых на SE никогда не будет, минус стэндбай.
откуда на 20 процев пол ляма? SE стоит $6к на проц (именно проц, не ядра), 20 штук с супортом $141k, со стандартными скидками и SE стебаями вышло бы отсилы $200к

по партишанам во первых у них партиций и так нет, во вторых в SE есть partition view (PARTITION_VIEW_ENABLED)
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=801747&msg=9747235

т.е. эти лапти могли бы на SE архивированные года уносить на HDD свежие года на SSD, объединять вьюшкой и оптимизатор оракла сам бы догадывался (partition elimination) не трогать таблицы 2010 года, если обращение идет к 2017 году.
примерно $6k — это для SE One, для SE — $17500 на процессор + 22% техподдержка на год
PARTITION_VIEW_ENABLED — это параметр оптимизатора
да, SE1, при шардинге ничего кроме SE1 и не нужно.
в 2016, когда они запускали постгрес, можно было уже по 40+ ядер на 2 сокета SE1 ставить. куда больше то?
и partitioning…

SE мы рассматривали как альтернативу, но сейчас можно уверенно сказать, что мы сделали правильный выбор.


Да, это был более сложный путь, но не надо думать, что для SE не пришлось бы ничего переделывать. И потом оно, конечно, дешевле EE, но прямо скажем, не бесплатно :)

Секционирования там нет.
Из статьи не до конца понял как реализовывалась реплика баз. Использовался pgpool-II?
Было бы странно если бы такие ребята использовали такие костыли при переделки такого проекта :)
Streaming у них.

Нет. Мы, конечно же, используем встроенную поточную репликацию.

Я правильно понял, что эксперименты с NOSQL были в середине нулевых?
ИМХО, надо вообще убрать тогда все упоминания NOSQL из текста статьи 2017 года, т.к. в те годы оно было никакое.

А сейчас эффективность утилизации железа у того же Mongo на порядки круче, чем у Oracle (а не в 3 раза хуже, как у PG). По крайней мере на моих проектах.

Впрочем, подозреваю, что информация о том, что PG в 3 раза неэффективнее Oracle тоже устарела.
А из чего следует что «PG в 3 раза неэффективнее Oracle»? В статье сказано «У нас сейчас в 3 раза больше железа под PostgreSQL», НО «сервер PostgreSQL» и «сервер Oracle» нельзя сравнивать напрямую. В статье опять же сказано, что хотелось больше серверов Оракла, но не моглось потому что резко возрастала цена лицензий. Поэтому приходилось «по максимуму» использовать имеющиеся сервера, нашпиговывая их «до упора». У постгреса 2 реплики, а не 1 — то есть серверов уже в полтора раза больше только за счет этого. Ну и подозреваю, что сервера постгреса все-таки «полегче» оракловых.
У меня домыслы, у вас домыслы. Возможно в статье безграмотная формулировка «в 3 раза больше железа», а имелось в виду не по стоимости, а по количеству например сокетов. Думаю, никто уже разьяснять не будет.
Так же не забываем что неизвестно что получили на «в три раза больше железа» — то же что и было или же + какие то плюшки (я вот тоже отметил увеличение числа реплик) В общем ждем комментариев от автора.

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

Вся история происходила в 2012-2016 гг. И утверждение про слабую применимость NoSQL (особенно нахваливаемой вами MongoDB) для нашей задачи всё ещё актуально и в 2017-м.

Скажем так, Монго 3.0 вышла всего лишь в 2015 году.
5 лет (даже с 2012) в мире ИТ это разные эпохи.
Mongo 2.1 из 2012 примерно такой же монго 3.4 как и mysql3 и mysql10 :)

Поэтому мнение про слабую применимость остается лишь мнением. Ещё и поданным без тезисов. :)

Я, как диванный эксперт и хэйтер кустарных решений, вообще бы максимально использовал промышленные решения: линуксовый dm-cache для разделения горячих и холодных данных и гибридные НЖМД. А не патчи, скрипты, хранимочки и синюю изоленту. Вполне возможно что работало бы не хуже, а время разработки было бы не десяток человеко лет, а несколько месяцев.

Скажем так, в Яндекс.Диске самая большая инсталляция MongoDB в мире. Да, версия 3.0 была большим шагом вперёд, но наш опыт (а не пустое мнение, как вы пишите) говорят о слабой применимости монги для задачи Яндекс.Почты. Да и сейчас ребята из 10gen ещё детские болячки долечивают — https://jepsen.io/analyses/mongodb-3-4-0-rc3.


Разделение данных на горячие/холодные внутри шарда мы только хотим сделать, а не сделали. И кучу времени мы потратили совсем не на это. Рекомендую вам сначала почитать статью/посмотреть презентацию или видео, прежде чем писать комментарии про синюю изоленту у нас.

То ли подача материала, то ли недостаток деталей, но прочитав статью возникли сомнения в компетентности админов во время работы с Oracle. А когда решили переехать взяли и поправили многие допущенные ранее ошибки.

1) Откуда и почему появилась мешанина бекэндов?

2)
Остальные проблемы связаны не столько с Oracle, сколько с тем подходом, который мы использовали.

То есть все причины к отказу от Oracle по сути сводятся к дороговизне? Или все же у варианта PostgreSQL есть инструменты которые решили проблему автоматизации, а у Oracle нет?

3) Перед решением о переезде считали ли итоговые затраты Oracle+железо+доработки с PostgreSQL+железо+доработки? Получился ль реальный экономический выигрыш?
Цитаты из текста:
«Яндекс.Почта» — сервис достаточно старый: он был запущен в 2000 году, и потому мы накопили много legacy.
Но главная причина перехода — это деньги. Oracle стоит дорого.
У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle.
И легаси, если правильно понял, они правили при переносе на PostgreSQL. Неужели нереально было было сделать перенос с Oracle на Oracle с исправлением легаси?

Про стоимость возник вопрос из-за:
Мы не придумали ничего лучше и запатчили barman, вот pull request. Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её.


Сравнивать стоимость одного железа с стоимостью лицензии Oracle как-то абстрактно и не показательно.
Мне приходят на ум варианты, когда итоговая стоимость переноса выше из-за суммы: покупок доработок к PostgreSQL, стоимости разработки переноса и самого переноса, стоимости оборудования с учетом его обслуживания (больше места, электроэнергии, охлаждение, замена вышедшего из строя, больше техников).
Неужели нереально было было сделать перенос с Oracle на Oracle с исправлением легаси?

Видимо, не смогли убедить начальство. «У нас всё и так работает, а мы влупим кучу денег и переделаем, и всё будет снова работать, но хуже, пока все баги не вычистим». Догадываюсь, куда их послали. А вот на экономию за счёт отказа от Оракла купились.

В чем смысл выдумывать всякую ерунду и постить её сюда? Если вы хотите, что-то узнать — вы же можете просто спросить и возможно вам ответят.

А для чего нужны тогда комментарии, если не для обсуждения и вопросов?

Не было задачи избавиться от legacy. Просто решили, что переезд на postgres — это хороший шанс упростить себе жизнь в будущем.

  1. Вам уже ответили комментарием ниже. Сложный проект за долгие годы активного развития умеет обрастать костылями.


  2. В докладе честных два слайда про причины и слайд с результатами, там ведь всё расписано. Кроме денег получили более простой deploy кода и нормальные разработческие окружения. Попробуйте, например, оракл в докер засунуть.


  3. Считали, получился.
Планирует ли Яндекс стать спонсором или внести другой вклад в сообщество PostgreSQL?
Уйти от Oracle из-за дороговизны и начать вливать бабки в PostgreSQL? Не думаю :) И вклад в сообщество они уже вносят, запатчив barman и отдав изменения разработчикам PostgreSQL. Только вот не нужна разработчикам PostgreSQL бесплатная помощь, они хотят что бы им помогали за деньги.

Ну, мы вроде и так вклад вносим. В barman, pg_repack, pg_rewind есть наше участие. В самом postgres'е при нашем активном участии в 9.6 появились зачатки wait interface'а. Надеюсь, дальше будет больше :)

Это возможно не совсем то место но в последнее время Почта регулярно рандомно выдаёт мне ошибку https SEC_ERROR_OCSP_OLD_RESPONSE в Ubuntu на последнем Firefox.
Время у меня правильное…
По-моему, Оракл — изначально неверный выбор БД для мэйл сервиса. Я себе слабо представляю, за счёт чего можно окупить энтерпрайз версию на бесплатном почтовом сервисе. Оракл — надёжный, удобный и быстрый — спору нет, но мне кажется, что с помощью хорошей архитектуры изначально можно было реализовать продукт соответствующий всем требованиям хорошего мэйл сервиса используя более дешёвые компоненты.
А какой был выбор в 2000 году? MySQL 3.23, который умел чуть менее чем ничего по сравнению с Oracle/MS SQL?
В каком состоянии был постгрес на тот момент я, к сожалению, не в курсе — об этой БД узнал значительно позже. Но, полагаю, у него тоже были определенные проблемы.
А, так внезапно удвоившееся количество правил в почте — это, значит, ваших рук дело. А меня саппорт убеждал, что 1) меня кто-то взломал 2) «сам дурак».
Интересно как работает перенос пользователей с холодной в горячую базу и назад, это через постгрэс или полностью ручками писалось?

Вся логика переноса — это ~ 5k строчек кода на питоне.

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

Перенос можно запустить либо руками (скрипт/jenkins job), либо это делает автоматика по весьма тупым критериям (не шевелился никак кроме покладки полгода — в sata и т.п.). Сейчас думаем в это место вкрячить ML, чтобы критерии самим не прописывать.


FK, конечно же есть, многие из них deferrable. Потому данные переносятся потаблично в правильном порядке. Параллелизма для пользователя нет (один пользователь — один поток). Потребление памяти константное, потому что копирование делается поточно с помощью COPY пачками фиксированного размера.


Глобально же перенос выглядит так. Открываются транзакции в шард-источник, где пользователь блокируется на запись, в шард приёмник и в шарпей. В случае успешного переноса всё коммитится с 2PC. В случае ошибок откатывается. Во время переноса ящик пользователя в read-only, но это в общем случае не проблема, потому что ящик на 10**5 писем переносится за единицы секунд.

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

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

Можете подсказать что такое `шарпей` :)?
Задан жёстко. Логика переноса лежит в том же репозитории, что и схема БД с кодом и тестами. На каждое изменение гоняются покоммитные тесты, проверяющие в т.ч. и работу трансфера.

Шарпей — это наш сервис шардирования, который хранит соответствие пользователя и шарда. И в нём, конечно, при переезде происходит обновление данных. Про это есть в презентации.
Спасибо, познавательно.
Почему не использовали вместо этого хардварный или программный automated tiering (https://en.m.wikipedia.org/wiki/Automated_tiered_storage), чтобы он вам на уровне блоков данные ротировал на самом хранилище?
по моему такое противопоказано рсубд с оптимизаторами, эта фигня дурит оптимизатор. у нас оракловый оптимизатор с ума сходил, он ночью собирал статистику и рассчитывает пробежать по индексам на SSD за 4 секунды, но эти блоки были вытеснены на HDD и реально вместо секунд 30 минут долбит HDD одноблочным…
Выше речь идёт про перенос между физическими шардами, никаких NAS/SAN там и близко нет из соображений производительности.

Что касается разделения данных на горячие и холодные внутри шарда, то стоит об этом подумать, хотя я бы предпочёл, чтобы база про это знала при планировании запросов. А подскажите какое-нибудь программное решение для linux'а?

Неужели SAN медленнее, чем просто диски в сервере? Там же FC, кеши, вот это всё… Или вопрос сугубо экономический?


По поводу программного тиринга на Linux говорят что-то про lvmts, но личного опыта не имею, поэтому советовать ничего не стану

«А подскажите какое-нибудь программное решение для linux'»

Удивительный вопрос от людей, которые «всё учли» и «10 человеколет переписывали скрипты». А Dm-cache ещё в 2013 в ванилле (3.9) появился.

И снова я вам порекомендую внимательно почитать, в этот раз комментарий от Botkin. В нём есть ссылка, по которой можно увидеть, что нахваливаемый вами dm-cache не является решением для automated tiering.


Ещё раз повторю, что 10 человеко-лет мы потратили совсем не на "скрипты". И фраз "всё учли" я что-то тоже не припоминаю.

Чтоб все ужаснулись, сколько стоит Оракл за 1 ядро, и сколько их было?
Уж не знаю, наколько цены одинаковы для всех, но в процессе общения на одном из форумов админской тематике всплыла цена что-то вроде $9100 за одно ядро. Всплыло это в контексте лицензирования (кажется, надо лицензировать все ядра на железе во всём кластере, даже если под БД отдано всего 4 ядра). В общем-то итоговая цена в скриншоте для сервера в кластере была в районе $19 000 000.
Опять же. Говорю только на основе скриншота и слов того форумного собеседника.
звучит бредово.
если речь о EE редакции то там ценник $25 000 за ядро ($50 000 за «ядро» * 0.5 коефициент x86) + каждая опция отдельно. типа партишенинг + $25к*0.5 + дата гвард +…
если речь о SE то там $6k на сокет. не ядро, сокет.
т.е. о чем бы речь не шла, все мимо.
PDF

-50% коэф. x86 процессоров. Остальное по договоренности.
Все конечно классно в Yandex.Почта, но вот с почтой в Yandex.PDD… не очень, она на неделе порой по 2 раза рушится, то не работает отправка писем, то прием идет с задержкой в десятки минут… тех.поддержка говорит что проблемы… устраняем, а тем временем пользователи толпами ходят возле меня и жалуются.
Скоро я чувствую придется съезжать с Yandex.PDD обратно на свой почтовый сервер, пусть нас зальет спам, но это лучше, чем не получать или не отправлять вовремя почту клиентам.

До Gmail Yandex.Почте как до китая пешком.
Непонятно отношение к коллегам: «Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята.» А сам Вова и его команда бесплатно все вот это реализовывали?
PostGreSQL хорош своими коммьюнити, но это будет не всегда. Чем больше будет серьезных проектов, где «большие деньги»крутятся и отвественность большая, все захотят, что бы советчики «отвечали» за свои советы. И все разом махнет из открытой коммьюнити на какой-нибудь платный сервис. Хотя не спорю — у Оракл поддержка — это нечто запредельное. И тогда вот станет не понятно, стоило ла овчинка выделки, тем более, что железа уже сейчас стала в 3 раза больше: «Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle.»

Начнём с того, что речь не про сообщество PostgreSQL, а про mainteiner'ов одного околопостгрешного проекта (barman). И все эти ребята работают строго в одной компании (2ndQuadrant-it).


И мы (люди снаружи) прислали им патч с реализацией крутой фичи, в лучших традициях open source разработки. А они не удосужились за год на него посмотреть. Имеют право, конечно, но IMHO как-то некрасиво.


Все последующие ваши рассуждения мне не очень понятны.

В PostgreSQL мы используем barman, и в нём под бэкапы нужно места минимум в 5 раз больше, чем размер базы


Интересно, а нельзя логировать именно запросы к БД в виде журнала? Такое должно хорошо сжиматься. То есть создать один неикрементный бэкап, а потом накапливать историю изменений. Можно какой-то велосипед было соорудить, который бы такое делал, или неэффективно?

Нет, нельзя, это сломает point in time recovery. Кроме того, уже есть WAL (в postgres'е бинарный), который мы храним.

К своей софтине всегда делаю логгирование SQL запросов со штампом времени. Нет никакой проблемы повторить все DML-ки с определенного момента времени. Или я чего-то недопонимаю? Отдельно можно создать не просто бэкапы, а полные копии-хранилища данных и накатывать на них эти самые запросы. Будет соотношение бэкап-исходные данные в соотношении 1:1, при этом из бэкапа восстановиться можно будет без долгого копирования всех терабайтов самой БД. Накатывать с отставанием в те же самые 7 дней.
На самом деле всё не так просто, как вы пишите.

1. Бэкендов, которые что-то модифицируют в базе, много. Время на них, конечно, синхронизируется, но NTP не даёт нужной точности.

2. Даже если предположить, что время идеально синхронизировано, в READ COMMITTED (уровень изоляции по-умолчанию и мы используем его) видны изменения уже закомиченных конкурентных транзакций. Транзакция А могла прочитать что-то, что было закомичено в транзакции B, но завершиться после транзакции C, которая изменений в B не видела в момент чтения. Потому 100% консистентности достичь будет сложно.

3. Накатывать такой логический лог запросов с параллелизмом сложно, а в один поток оно упрётся в одно ядро при хоть какой-то нагрузке. Именно потому в postgres'е WAL бинарный и накат на репликах легко справляется одним ядром, не отставая, упираясь в ядро.
Транзакция А могла прочитать что-то, что было закомичено в транзакции B, но завершиться после транзакции C, которая изменений в B не видела в момент чтения

И в чём суть конфликта? Не очень понял пример. Вы наверное имелди в виду наоборот, что C со своими устаревшими данными завершится после A?
Суть конфликта в том, что в результате наката statement'ов этих транзакций, упорядоченных по времени коммита, на реплике получится другой результат.

Например, в транзакции B в табличке foo заменили какое-то поле с 1 на 2 во всех строчках. Транзакция C читает чиселку из foo и получает 1, потому что B ещё не закоммитилась. Транзакция C записывает вычитанную чиселку в табличку bar и делает что-то ещё, повисая на блокировке. Транзакция B коммитится, транзакция А читает чиселку из foo (получает уже 2), пишет её в табличку baz и коммитится. Транзакция C успешно коммитится. Итого на мастере получается следующая картина маслом:
foo: 2,
bar: 1,
baz: 2.

Если же теперь повторить транзакции на реплике по времени коммита, то получится вот так:
foo: 2,
bar: 2,
baz: 2.

Отсюда вывод, что применять такой лог запросов по timestamp'у коммита нельзя, а другого timestamp'а у вас как бы и нет. Можно было бы писать timestamp каждого statement'а (вернее, когда БД вернула ответ на него), но во-первых, это уже включает в себя передачу по сети, которая может вносить произвольный лаг, а во-вторых, это не покрывает работы триггеров или хранимую логику.

Короче, реализовать свою логическую репликацию сильно сложнее, чем кажется. Не стоит так делать.
Спасибо, теперь понял. Но мне кажется, такая архитектура изначально неверна. У нас ведь на реплике получается «логически верно», а на мастере нет — из-за того, что время выполнения транзакций так совпало неудачно. Мастер в таком случае будет содержать неправильную картинку. Я бы вообще избегал одновременных операций, которые зависят друг от друга. Лучше сделать кучу блокировок и пожертвовать производительностью, чем потом по факту разгребать такие конфликты, пытаясь понять, что где должно было быть :)
К стыду своему не знал, что такое WAL. Почитал, разобрался. А зачем тогда вам barman? И сколько эти двоичные журналы весят? Достаточно ли их, чтобы обеспечить откат на любой произвольный момент во времени?
Обо всём этом я рассказывал тут — https://events.yandex.ru/lib/talks/3202/
Собственно, в этом и есть суть WAL, который, как и отмечено в статье, отлично сжимается. Проблема, насколько я понял, в хранении именно неинкрементальной версии (версий), на которую уже накатываются WAL.
Рассматривали ли вариант использования готовых решений для шардинга (CitusDB, Postgres-XL)?

Рассматривали, хотя в то время были только XC и XL на базе 9.2. Но даже текущие решения не выглядят довольно стабильными для OLTP.

а зачем с такой архитектурой понадобился enterprise edition? все что нужно, начиная с standby (тот который SE standby на скриптах), заканчивая partitioned view с его partition elimination есть в SE edition, которое стоило уже в те времена лишь $6k на сокет?
partitioned view + partition elimination замечательно бы развели бы старые майлы на HDD, свежие на SSD. выглят что в яндексе просто не было хардкорного ораклойда.
Да и на стандарте много раз, на внедрениях, где руководство зажимало деньги, реализовывал скриптовый стендбай со своим мониторингом. Работало годами и переключалось нормально.

Вы правда считаете, что Яндекс много лет жил почтой на оракле и до сих пор живёт другими сервисами без хорошей экспертизы в оракле!? Если да, то я вас разочарую, вы ошибаетесь.


Что касается архитектуры, то не всё мы рассказывали/рассказываем. И потому это всё было в формате доклада на конференциях, а не статьи на Хабре, чтобы на какие-то вопросы можно было ответить в кулуарах, а не публично.

вы почту держали на оракле EE и толком не пользовали его возможности. вы платили сумасшедшие деньги за EE standby, а он стоял без дела. ну согласитесь есть повод подозревать, что вы не совсем понимали сколько стоит EE и где преимущества оракла с его UNDO, блокировками в блоке данных, мегаоптимизатоаре и прочим не нужным почте грузом. все ваши конкуренты за долго до 2012 в hadoop облаках и с noSql.
опять же по своему опыту, если бы у вас были бы хардкорный ораклойды, они бы бились за оракл до последнего (как я) и вариант с SE1 edtion + partitioned view как минимум серьезно бы продемонстрировали бы.
Мы потому и спрашиваем. Всплыло в этом докладе то, что мягко говоря не ожидаешь от такого уровня как яндекс, которым практически вся страна пользуется. Вот и хотелось бы узнать про реализацию, хотя бы примерную, других сервисов.
> У нас сейчас в 3 раза больше железа под PostgreSQL,

наверно стоит оговориться что это не потому что постгрес тормозной, а потому что стали горизонтально масштабироваться
Думаю что оракл дорогой не для Яндекс а для Яндекс почты, т.к. это далеко не единственный сервис, и вполне возможно для бюджета почты это менее позволительно чем какому-нибудь другому сервису.
Оракл слишком дорогой даже для Яндекс? Для кого тогда нет?
Для бесплатной Яндекс.Почты, у которой еще и бесплатная почта для доменов.

Мне уже давно интересно, как настолько отличный сервис могут отдавать просто так.
Товарищ, но Yandex Поиск, Переводчик, <продукт X> и даже Диск тоже бесплатный. Не аргумент.
А яндекс.деньги на какой реализации у них живут?! Как раз ведь и народ.ру был выкинут яндексом то же в то же время. Видать реально разрослись. Народ.ру жалко конечно.
ТС, что это за проблема с секционированием, о которой вы упомянули?
У Постгресса партиции настраиваются вручную и им можно указать tablespace, который физически м.б. размещен хоть на харде, хоть на ssd, хоть в ОП. Я так и делаю, вынося горячие данные в оперативку.
Или вы что-то другое имеете ввиду?

Во-первых, партиций много не создашь, время планирования сильно деградирует. Во-вторых, нужен триггер на insert.


Эти проблемы решает pg_pathman, который мы используем в одном проекте (на наш взгляд он пока сыроват, но ребята оперативно его штопают), и нормальный partitioning, который закоммитили в 10-ую версию.


В-третьих, теряется ссылочная целостность на секционируемые таблицы, что не есть хорошо.


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

Понял вас.
Но что для вас «нормальный partitioning»?

Решение проблем 1-3 из моего предыдущего комментария.

Вы ожидаете, что проблему 1 решат на уровне движка?
Тогда ждем от вас продолжения статьи — как решились проблемы после перехода на 10-ку. У себя, к счастью, проверить не могу — мне повезло, что удалось нарезать партиции по условиям из поиска, при этом кол-во партиций или их размер не стремятся в бесконечность.

Для тех, кто впервые увидел этот материал, очень рекомендую посмотреть слайды — https://simply.name/ru/slides-pgday2016.html — или лучше видео (только на английском) — https://simply.name/video-pgcon2016.html.


А то редакторы и копирайтеры местами поломали смысл. Ну и откровенные ошибки есть. Например, trench вместо range или web-интерфейс вместо wait-интерфейса.

какой ужас. 300 тб данных, по 10 тб на сервере. т.е. 30, явно не односокетных серверов + 30 стенбаев, т.е. это лицензировать минимум 200+ ЕЕ ядер + standby option. это же многие сотни тысяч только за супорт в год.
яндекс реально не осознавал куда идет, запуская бесплатную почту на оракле?
как пользователь, скажу что работа стала менее комфортной, быстродействие заметно снизилось, часть функционала начала работать некорректно (например сортировка при группировке писем, обновление счётчиков), часть была урезана (например отсутствие сортировок писем и пагинации в поиске)
НЛО прилетело и опубликовало эту надпись здесь
Это — не первая наша попытка избавиться от Oracle. В начале нулевых была попытка переехать на MySQL, она провалилась. В 2007 или 2008 была попытка написать что-то своё, она тоже провалилась. В обоих случаях был провал не столько по технически причинам, сколько по организационным.

Ящик у меня с 2000 или 2001 года, а вот письма с 30 марта 2006… обидно ж!
можно же вместо «хитрого функционального индекса» i_box_uid_lids воспользоваться расширением btree_gin и создать другой индекс с аналогичным назначением: gin (uid, lids). Или такой индекс будет в чем то уступать «чистому» gin?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории