System Design & Highload (Alexey Rybak)

Вывод #2: PostgreSQL “сгладил” родовую травму

Второй вывод, который я сделал: PosgtreSQL к 17й версии (а может, и раньше – не изучал) значительно “смягчил” свою родовую травму, модель process-per-connection в обработке соединений. Я собственными глазами видел, как наша тестовая машинка “жила” с 5000 процессами. И это с 128G памяти, что по нынешним меркам немного, то есть при желании 20-25 тысяч одновременных соединений PostgreSQL может легко вытянуть на достаточно мощном железе просто даже без кеша соединений.

Конечно, другие СУБД справятся с таким количеством соединений на значительно более скромном железе, но поскольку я последовательно выступаю за “разумную” комбинацию горизонтального и вертикального масштабирования – большинство проектов PostgreSQL “потянет” даже без баунсера. С баунсером, кстати, тоже не всё гладко, дополнительное звено и extra-hop, это раз, но поскольку он по-прежнему однопоточный – это может ограничивать пропускную способность на больших нагрузках (надо делать пул баунсеров, уносить баунсеры на бекенд-машины – короче, всё это делается, но заметно увеличивает сложность). Тут интерес представляет мульти-поточный яндексовский одиссей – мы его даже поставили, но банально руки так и не дошли: с пол-пинка он не завелся, а ковырять уже времени не было.

Кстати, большое спасибо всем, кто голосовал за СУБД-направления (ещё можно это сделать). На мой взгляд, такой перевес интереса к PostgreSQL по сравнению c MySQL не соответствует реальному уровню этих СУБД и эко-систем вокруг них. Лично я считаю, что они равнозначны, и я ожидал бы распределения интереса 50% на 50%. Но объективно голосование лишь подтверждает известный факт: в русско-язычных командах PostgreSQL или связка PostgreSQL/Redis является самой популярной.

Для справки:
- презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- вывод #1

www.tgoop.com/rybakalexey/184

1.7K viewsedited  Jan 13 at 07:21

Вывод #2: PostgreSQL “сгладил” родовую травму

Второй вывод, который я сделал: PosgtreSQL к 17й версии (а может, и раньше – не изучал) значительно “смягчил” свою родовую травму, модель process-per-connection в обработке соединений. Я собственными глазами видел, как наша тестовая машинка “жила” с 5000 процессами. И это с 128G памяти, что по нынешним меркам немного, то есть при желании 20-25 тысяч одновременных соединений PostgreSQL может легко вытянуть на достаточно мощном железе просто даже без кеша соединений.

Конечно, другие СУБД справятся с таким количеством соединений на значительно более скромном железе, но поскольку я последовательно выступаю за “разумную” комбинацию горизонтального и вертикального масштабирования – большинство проектов PostgreSQL “потянет” даже без баунсера. С баунсером, кстати, тоже не всё гладко, дополнительное звено и extra-hop, это раз, но поскольку он по-прежнему однопоточный – это может ограничивать пропускную способность на больших нагрузках (надо делать пул баунсеров, уносить баунсеры на бекенд-машины – короче, всё это делается, но заметно увеличивает сложность). Тут интерес представляет мульти-поточный яндексовский одиссей – мы его даже поставили, но банально руки так и не дошли: с пол-пинка он не завелся, а ковырять уже времени не было.

Кстати, большое спасибо всем, кто голосовал за СУБД-направления (ещё можно это сделать). На мой взгляд, такой перевес интереса к PostgreSQL по сравнению c MySQL не соответствует реальному уровню этих СУБД и эко-систем вокруг них. Лично я считаю, что они равнозначны, и я ожидал бы распределения интереса 50% на 50%. Но объективно голосование лишь подтверждает известный факт: в русско-язычных командах PostgreSQL или связка PostgreSQL/Redis является самой популярной.

Для справки:
- презентация по результатам исследования PostgreSQL/MySQL/Redis/Valkey/Memcached
- вывод #1

BY System Design & Highload (Alexey Rybak)