Конференции Олега Бунина (Онтико) corporate blog
Авито corporate blog
High performance
PostgreSQL
Go
Comments 27
0
На мой взгляд, сила Go в простоте. И это выражается, например, в том, что в Go принято писать запросы на голом SQL (ORM не в чести). Это и преимущество, и источник дополнительных трудностей.

Кем принято, если не секрет? Насколько я вижу — у gorm, к примеру, очень активная и большая аудитория.
+4
Аудитория у gorm, действительно, большая. Я это объясняю только тем, что люди переходя с других языков тащат за собой практику использовать orm.

Но, по разным причинам, в Go чуть меньше распространены orm.

А в целом, у постгри много функциональности, которая слабо покрывается orm'ками: мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по json (а в 12 версию закоммитили jsonpath www.postgresql.org/docs/12/datatype-json.html#DATATYPE-JSONPATH) и большое кол-во других вещей, которые делают использование orm неразумным.

orm-холивар предлагаю не разводить. Отличный вопрос, мне понравился, спасибо!)
+1
мощная индексация по json

Стоит обратить внимание, что по json просто нельзя собрать статистику.
А база, планер которой работает по весовой схеме, просто не может нормально работать без статистики.


Но надеюсь скоро исправят, здесь smagen писал: http://akorotkov.github.io/blog/2015/09/07/jsonb_statistics/ для 10-ки точно еще актуально.

0
мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по json
Плюс замечательный PL/pgSQL. Мы так вообще отказались от идеи разрешать приложениям лезть в базу с запросами напрямую, только через API, благо и JDBC, и psycopg2 умеют в callable statements/procedures. В результате вся логика изолирована, больше не надо заворачивать семантику в строку (ура!), можно вообще не париться насчет кавычек и экранирования (тайпчекер постгреса сам проверит корректность аргументов), многие вещи можно фиксить в продакшне без пересборки и перезапуска приложений и пр.

Transaction Mode и Prepared Statements это известная проблема, мы просто запретили их на клиенте через prepareThreshold=0.
0
github.com/lib/pq — pure Go Postgres driver for database/sql. Этот драйвер долгое время оставался стандартом по умолчанию. Но на сегодняшний день он потерял свою актуальность и не развивается автором.


С чего вы это взяли? Кодовая база обновляется, последние обновления несколько дней назад.
На Гитхабе никакой информации о прекращении поддержки нет, да и авторов там не один.
+1
Не развивается. Либо очень медленно.
Вот фикс который я очень давно ждал, так и не дождался. Сильно влияет на производительность.
Использую в результате pgx.
+1
Уходя немного в сторону: я нажал в том PR Approve и одобрил изменения (полагая, что ничего не произойдёт, коненчо). Но нет, моё одобрение появилось в списке ревьюверов.

Это Гитхаб так работает и любой может жать кнопки в любом публичном репозитории?
0
Любой может одобрить PR, но они показываются отдельным списком и не учитываются в подсчете количества необходимых одобрений для мержа
+2

Кроме примера из треда, могу еще вот такой PR показать https://github.com/lib/pq/pull/714. О том, что библиотека заброшена пишут даже люди имеющие статус Collaborator.


Основными людьми, поддерживающими жизнь в библиотеке остаются ребята из cockroachdb. Но, например mjibson пишет


It is indeed sad this has no active maintainers. Open source has its problems.
I don't have permissions to grant permissions so I'm not able to do anything. A few of us from cockroach just asked the last time this was a problem and they gave us commit here. We just keep limping along.

Мне кажется, правильным решением будет пометить библиотеку как deprecated, заархивировать проект и забыть о нём. pgx давно обогнал. А с 4 версии станет совсем хорошо)

+3
хочется сказать спасибо Артемию за интересный доклад, т.к. сами внутри прошли весь тот же путь в прошлом году, и добавить, что с момент доклада произошло радостное событие — он подготовил и закинул ПР с поддержкой многосерверности в DSN (https://github.com/jackc/pgx/pull/545) c автопереключением на текущего мастера при проблемах и этот ПР был принят и вмержен в pgx.
-1
github.com/jackc/pgx — именно этот драйвер вы хотите использовать.


Хммм… а GORM использует github.com/lib/pq. Интересно, почему не перешли.
0

В issue глянул — с ходу не нашел. Возможно еще не осознали, что пора.

+3
С одной стороны, после стольких лет использования Sequel и ActiveRecord — так больно смотреть на гошников, жующих свой кактус простоты с самого нуля.
С другой стортоны, этот же кактус заставляет лучше и глубже разбираться в том, как все работает внутри, что явно плюс!
0
Добрый день, не понял, почему нужно использовать дополнительно pgbouncer, если в пакете БД для Го уже идет свой пуллер соединений с БД.
0
Просто потому что приложении много и, даже при использовании пула внутри, все вместе они могут породить соединений больше чем порог деградации.
0
При штатном режиме работы базы и приложения пул соединений в Go позволяет не порождать новые соединения к базе. А вот при малейшей деградации базы данных пул соединений на стороне приложения исчерпывается и кол-во порождаемых соединений на единицу времени в разы возрастает.

А можете прояснить, какая тут причинно-следственная связь?
0
Впрочем, я понял. Имеется в виду, что пул не исчерпывается (если он ограничен сверху, то какие проблемы?), а наоборот, пул разрастается.
0
Я воспринимаю пул как ведро) Мы в него кладём соединения если их не используем и забираем оттуда, когда нужно заиспользовать. Но когда в ведре нет соединений — приходится устанавливать новое соединение с базой.
+1
Потенциальные SQL-уязвимости. Разработчик может забыть или некорректно сделать экранирование.

Вероятность этого остается в pgx. Дело в том, что pgx честно делает Simple Query внутри себя, выполняя экранирование аргументов.
github.com/jackc/pgx/blob/0151aeb3077d63ed90110bc083521f709a5d4fef/query.go#L524
Если в этой функции пойдет что-то не так, то это прямой путь к уязвимостям.
lib/pq делает иначе. При указании в connection string параметра binary_parameters=yes драйвер отправит один запрос, в котором сначала идет Parse query string, затем Bind параметров в бинарном виде.
github.com/lib/pq/blob/master/conn.go#L835
Видно, что далее драйвер честно читает Parse и Bind response от базы, как в сценарии с Extended Query.
Это позволяет разработчику или драйверу не собирать запрос в строку самостоятельно, а передать это все базе.
0
Спасибо! Вы правы, в данном случае экранирование делает сам драйвер. Я надеюсь найти время, закоммитить в pgx передачу параметров в бинарном виде. Но, кстати, этот протокол не стандартизирован и может быть изменен в следующих версиях постгреса. Впрочем, это не так страшно, так как переезд на новую версию дело долгое и можно будет подготовить драйвер к этому.

Как преимущество, с simple query меньше запросов в сеть и ниже latency)
0
Спасибо за доклад! Скажите, пожалуйста, рассматривали ли вы для себя пакет go pg? По большей части — это пакет, заточенный именно под Postgres. В нем есть очень приятная фича — это внутренний пакет ORM, который дает вам общий для транзакций и обычных соединений интерфейс, за счет которого можно абстрагировать бизнес логику от инфраструктурного слоя.
0
> абстрагировать бизнес логику от инфраструктурного слоя.
Так как мы работу с базой делаем сразу отдельным слоем (что-то вроде паттерна repository, но без фанатизма), то необходимости в ORM не возникает. Собственно, из-за того, что gopg чуть переусложнена, не хочется её использова. Ну и опыта с pgx просто больше)
-1
Flaker, спасибо за материал, не подскажете, как с помощью sqlx импортировать csv в таблицу postgres?
Only those users with full accounts are able to leave comments., please.