Практики, особенности и нюансы при работе с Postgres в Go / Артемий Рябинков (Авито)
Вставка
- Опубліковано 10 вер 2024
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
Saint HighLoad++ 2019
Тезисы и презентация:
www.highload.r...
В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Отличный доклад, все по делу. Спасибо!
Мне как раз это сейчас нужно.!
Спасибо за видео, очень полезно!
Как называется либа которая делает emulate prepared statements?
А почему pgbouncer не может после каждого PREPARE который он выполняет в одной из сессий, автоматически выполнить тот же PREPARE в остальных сессиях, это же просто! Как только получил на любой PREPARE ответ без ошибки, сразу добавить в очередь всех других сессий этот же запрос чтобы в них создались такие же стейтменты. Это уже можно делать асинхронно, но главное добавлять в очередь перед тем как отправить клиенту ответ, чтобы остальные PREPARE гарантированно отработали во всех сессиях до попадания в них EXECUTE с тем же именем. Можно еще сделать мапинг client_name -> bouncer_name чтобы при отрыве клиента удалять все его PREPARE во всех сессиях, через этот мапинг так же подменять все имена для EXECUTE.
спасибо за доклад
отличный доклад
1:54 - объясните, почему отсутствие ORM - это сила языка?
Тоже хотел бы понять) все гоферы об этом говорят, но никто почему
@@yodapunishes потому что "зумеров" не приходится обучать SQL, им приходится его изучать
pg не держит более 100 коннектов?
Пых не поддерживает пул соединений?
Одного Bouncer-а может не хватать?
100 коннектов - гипербола, про баунсеры всё достаточно ясно сказано (одного баунсера может не хвататать dba.stackexchange.com/a/155739)
тоже не понял, у меня 300 коннектов работает без баунсера, почему несколько баунсеров надо ставить я не понял.
Сам раз работчик PG не рекомендует больше 100 коннектов
@@winfle но объяснения нет
@@user-di7kt7bn3b Если приходит приличная пачка запросов, то унылый пг будет поднимать отдельный процесс под каждое новое соединение, запросы будут отваливаться по таймауту
Отличный спич
ничего себе, в 21м веке яп умеет работать с бд и для этого нужен доклад. Вот это хайлоад не по годам.
Был свидетелем. Открывал лк, видел чужой акк. дальше новый акк при обновлении.
Какойто стремный и костыльный язык, аля нам надоел пхп в авито, хотим геморроя, давайте перейдем на го
Люблю объективные аргументы
Очень плохо, начиная со snake_case в коде Го, паник, которые "не надо использовать", про работу драйвера БД, "в Го есть пул соединений" и прочие перлы вообще молчу. Блять, и половина доклада про какую-то левую библиотеку, смысл которой это чтобы не дай бог не написать пару лишних строчек кода, аля чтобы все было как в уютненьком PHP.
Вообще так-то смысл любой библиотеки в том чтобы не писать какое-то количество лишних строчек кода
Да, всё говно, кэш на чтение в редиске или мемкэше нет не слышал? - все запросы в базу уникальны?
Лол.
чет чуш