#postgresql

Ядро чатжпт работает на одном Postgres-сервере с 50 read-only репликами. Это к вопросу о масштабируемости и потребности в сложной инфраструктуре.

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

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

У postgres открытая, по-настоящему распределенная разработка, в которой участвуют сотни инженеров со всего мира.

Многие ИТ-проекты держатся на власти диктатора (Линукс на Линусе), а Postgres вот уже 30 лет управляется меритократией в консенсусной модели.

Свободная BSD-подобная лицензия, которая (в отличие от религиозной GPL) позволяет открыто делать коммерческие продукты на его основе.

Отличная обратная совместимость и близкое соответствие стандартам, и при этом они умудряются первыми реализовывать фичи, которые только позже появляются в платных БД.

PostgreSQL как программа — это настоящее произведение инженерного искусства, а проект в целом — чудо в плане самоорганизации людей. Горжусь, что у нас как у человечества получилось сделать такую красивую штуку.

Я рад, что Postgres постепенно становится самой популярной базой для начинающих, заменяя MySQL.

Проекты, которые мы делаем с Федей и командой, сильно отличаются от постгреса всем — и размером, и стеком, и задачами. Но это тот уровень инженерного мастерства, которым вдохновляюсь я и на который, я надеюсь, равняется вся моя команда.

Чуваки из Electric упаковали PostgreSQL сервер (один из главных движков баз данных в мире) в js-библиотеку размером 3 мегабайта.
Работает на WASM в браузерах и в nodejs, поддерживаются экстеншены. Скорость отработки базовых запросов — 0.3ms.

Это как если бы дизельный локомотив с железной дороги поместили под капот WV Beetle. 🤯

Называется pglite, попробовать в браузере можно тут.

Figma красиво рассказывает, как они масштабируют свою базу данных (горизонтальное шардирование Postgres).

Всего 4 года назад они хвастались, что все данные помещаются в одной БД на самой жирной тачке в AWS и выросли с тех пор в 100 раз.

Во-первых, прикольно читать, как устроен сервис, которым пользуешься почти каждый день. Во-вторых, в «internet-scale компаниях», мне кажется, засилие MySQL, так что приятно, когда делятся серьезными инсталляциями Postgres, который предпочитаем мы и большинство наших знакомых.

Вспомню ещё две другие, довольно старые истории про масштабирование баз данных:

1. Вот техническая команда инстаграма в 2012 году дает прикольные советы и рассказывает про шардирование постгреса. Заметьте, совсем другой вайб — не огромный лонгрид, а короткие заметки «с чем столкнулись и что сделали».

2. Культовая статья Uber 2016го года, которая называется «Почему мы переехали с MySQL на Postgres». Прикол в том, что название не отражает сути: они отказались от реляционной БД и сделали свою собственную СУБД на основе MySQL — срачи про это не утихают до сих пор, вот последнее обсуждение 2021 года и набор ссылок на предыдущие.

Вот неплохой список подходов к масштабированию БД, пускай они и не нужны в 99% проектов.

В мире есть 4 главные программы базы данных. Oracle, Microsoft SQL и даже MySQL принадлежат корпорациям. Четвертую, PostgreSQL, придумали ученые в Калифорнийском университете в Беркли и сделали опенсорсной. Вместе с американскими учеными и энтузиастами по всему миру, эту базу данных разрабатывал Олег Бартунов. Спустя много лет он основал компанию, которая занимается поддержкой PostgreSQL и помогает ее использовать Яндексу и Министерству финансов РФ. Мы поговорили с Олегом о его работе с базами данных. Как Олег из ученого-астронома стал главных специалистом по PostgreSQL в России, как он наблюдал рождение IT-гигантов Кремниевой долины и как участвовал в создании рунета.

Слушайте и подписывайтесь: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.

Мы в iGooods лежали почти полдня. Стыдно! Зря я угорал вчера над утконосом, что они упали. Поделюсь честно, от чего мы лежали. Это подробный постмортем аварии с техническими подробностями, мама, извини.

—

Из-за коронавируса к нам начали приходить в 2-3 раза больше клиентов, чем обычно. Плюс у нас на днях запускается два новых партнерства — с Joom и с магазинами Лента. Серверы работали на 40-60 процентах емкости и мы решили «добавить железа». В 6 вечера мы налили пару новых машин в кластер приложений, в час ночи по Москве — перетащили базу на новую, ультра мощную тачку. Обе операции — необычные для iGooods, множество вещей делалось руками. Ошибка №0 — мы сделали 2 крупных изменения близко друг с другом

В 7 утра по Москве, сервер базы данных начал плавиться от нагрузки в процессор. Это компьютер с 70 ядрами, но базе нужно было минимум 300. Запросов было вроде бы не сильно больше, чем обычно, но занимали они всё больше времени. Люди просыпались у себя дома и начинали делать заказы — сервера умирали, сайт не открывался, приложения выдавали ошибки. Самое опасное — курьеры и сборщики заказов выходили на работу и не могли работать.

Мы, конечно, думали, что сможем быстро починить проблему. Через час стало понятно, что нужно хотя бы временное решение. Мы выключили все пользовательские интерфейсы iGooods, оставив рабочей только админку и внутренние приложения курьеров и пикеров (сборщиков заказов). Ошибка №1 — в случае аварии не нужно пытаться «сделать хорошо», нужно определить критичные сервисы и восстановить их первым делом.

Мы решили, что проблема в новой базе данных. Мало ли, конфигурация, железо, да хоть драйверы. Попытались вернуться на старый сервер. Мы не сохранили WAL логи между переездами, так что вместо 3 минут эта операция заняла 40 минут — пришлось перегнать всю базу данных между серверами. Мы планировали откат для приложений, но не для переноса базы — он нам казался довольно безопасной операцией. Ошибка №2 — мы решили, что «уж тут-то не взорвется», на самом деле вместе с любым изменением нужно продумывать пути отката.

Возвращение на старый сервер базы данных не помогло. Каждый раз, когда мы включали пользовательские приложения — база данных мгновенно уходила в несознанку и работа бэкофиса парализовалась. Сайт и мобильные приложения к тому моменту лежали уже больше нескольких часов. Самое страшное — мы всё ещё не были уверены, что проблема не в базе данных.

В конце концов, Женя случайно заметили ошибку, что наше rails приложение не может записать в redis-кеш. BINGO! Вот тут всё наконец-то встало на свои места. В нашем приложении есть много страниц, которые собираются очень долго. Все они кешируются rails'ами в redis. И вот этот редис кеш у нас отвалился на запись на части серверов приложений из-за кривых настроек окружения (душераздирающие подробности приложены картинкой). Кеш протухал постепенно и с каждой потерянной записью все больше тяжелых запросов грузили Postgres. Ошибки №3, 4 и 5: настройка тачек производится руками, не кодом; логи переполнены, так что сложно заметить новую ошибку; не все важные сервисы (redis, rails cache) включены в мониторинг.

Как вы можете видеть, всё довольно банально. Будь у нас настроена нормальная рабочая среда — не было бы такой аварии.

Итак, чего нам не хватило и что мы приведем в порядок:
- инфраструктура в коде (полный ansible вместо хождения руками на серверы);
- хороший, чистый мониторинг всех ключевых метрик приложения, APM — за день до аварии мы включили Datadog, но ещё не было нормальных дэшбордов и исторических данных;
- сообщения об ошибках (у нас bugsnag) засраны нерелевантными сообщеними — их нужно почистить.

Мы с Федей обозначили проблемы в первые же дни, но не успели решить их — были вещи поважнее. Знал бы прикуп — жил бы в Сочи.

Если у вас похожая ситуация — рекомендую навести порядок заранее, не ждать форс-мажора.

Ну и делать много сложных правок вместе — чревато. Стоило разнести перенос базы и деплой новых машин на день — тогда бы мы не потратили так много времени на ложный след тормозной базы.

Fin.

Нашёл классный способ выбрать по одному представителю из группы в SQL.

❧

SQL — cтруктурированный язык запросов, изначально — SEQUEL, «структурированный английский язык запросов» к базам данных родом из 1974го (да, IBM). Почти все технари и аналитики на нем описывают, какие столбцы и строки из таблиц мы хотим получить, как их отфильтровать, отсортировать и преобразовать.

В SQL мы описываем не что сделать, но какой результат мы хотим получить (декларативная парадигма программирования). Большинство программирования в мире происходит по-другому: мы перечисляем компьютеру, какие шаги нужно выполнить (императивная модель). Переключиться на другой режим мышления непросто. Порой при написании большого запроса я чувствую, что «мозги скрипят» - как при решении математической задачи.

Умение пользоваться различными парадигмами, осознанно выбирать более подходящую в данный момент — то, что отличает по-настоящему крутого специалиста. Учите SQL! В конце концов, думать над запросами просто приятно :)

Продакты и аналитики! Научитесь SQL и сможете сами, без программиста отвечать на многие вопросы про проект.

Вот четыре супер классных интерактивных курса (бесплатно без СМС): побогаче, полапидарнее, с довольно сложными задачами в конце и очень красивыми фабулами.

В мои годы таких курсов не было, так что я учился по официальной документации PostgreSQL. Это один лучших технических текстов, что я видел (хороший русский перевод).

❧

На сладкое для заинтересованных:
- хороший туториал по написанию своей базы данных, где разобраны основные концепции на примере клона SQLite;
- доклад создателя SQLite о том, как работают базы данных (ютуб): подача так себе, но в теме чувак разбирается очень хорошо, поэтому интересно.

У движка «Валли» сложная судьба.

Три года назад Ярослав Кравченко (он тогда отвечал за фронтенд монитора, админки Медузы) за несколько дней запрограммировал «игру». В ней нужно было угадывать положение точки на картинке (обычно используется географическая карта). Это была одна из первых игр Медузы.

Никто не думал, что движок станет популярен и вообще будет использоваться повторно. Админка была довольно неудобная, но редакция стабильно делала в ней «географические тесты».

Данные хранились в mongo, настроить к ней бекапы мы забыли. В прошлом году сервер с этой базой сломался. Мы потеряли все «географические тесты», сделанные редакцией в течении несколько лет.

Сейчас произошло второе рождение этого движка. Модный react, наша стандартная админка игр на бутстрапе, postgres-база с горячим резервом, даже тепловая карта кликов читателей — всё дышит 2018 годом.

В ролях: Витя Ходак — дизайн, Гоша Девяткин — программирование, Лёша Прилепский — менеджмент, Илья Красильщик и Саша Поливанов — редакционная поддержка.

https://meduza.io/games/gde-samaya-deshevaya-kvartira-v-rossii-a-samyy-vysokiy-dom

Кстати, интересная деталь — как мы храним токены для соцсетей. Их, как вы понимаете, дофига. Хочется:
1. иметь возможность легко посмотреть и отредактировать токены в рантайме;
2. иметь защиту от того, чтобы запостить со стейджинга в продакшен.

Мы решили хранить их в основной базе данных проекта (pg), но с перфиксом env (production | staging). Таким образом, эти токены легко редактировать real-time. При этом нет опасности, что при импорте продакшен данных на стейджинг мы начнем фигачить тестовые статусы в основной паблик. И ноль дополнительных зависимостей. Достаточно элегантно, мне кажется.

Буду очень рад, если кто-то подскажет простую централизованную систему хранения секретов. Сейчас мне кажется, что, ничего проще Vault от HashiCorp нет и в любой мало-мальски большой компании без этой дополнительной зависимости (и сложности) не обойтись :(

Хорошо описанный кейс с финансовыми отчетами Airbnb.

Близкая мне тема, я писал одну из первых версий отчетности для правообладателей в Zvooq (звучит громко, в реальности это были безумные SQL запросы в PG и небольшие скрипты поддержки).

Финансовая отчетность из данных сервиса — классическая задача, где для программирования нужно серьезно разобраться в предметной области с безумными бизнес-правилами и процессами. Близко к тому, что делают SAP-специалисты :)

У меня есть личная неприязнь к MySQL. Причина не в функциональных недостатках - это исключительно мощный софт; многие крутые технари делают базы именно на нем.

Причина - в документации. В этом неумении сформулировать мысль не растекаясь на 10 страниц. В неумении отделить один раздел от другого.

Подростком я читал The FreeBSD Handbook. Это пример идеального технического документа своего формата. Рекомендую почитать, даже если вы не технарь. Просто оцените лёгкость слова и качество подготовки текста.
https://www.freebsd.org/doc/handbook/

Документация PostgreSQL - из той же лиги.
https://www.postgresql.org/docs/9.5/static/index.html

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

Навеяно вот этим списком свежих критических уязвимостей MySQL.
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html