это да, как минимум

ещё беспокоит, не "сдурит" ли в какой-то прекрасный момент планировщик или оптимизатор? Так-то тесты проходят, конечно...

в общем, с конфликтами более или менее ясно: в cur-е select должен быть for update, а вероятность гонки между select-ом и insert-ом можно свести к минимуму на, так сказать, уровне бизнес-логики.

ещё беспокоит, не "сдурит" ли в какой-то прекрасный момент планировщик или оптимизатор? Так-то тесты проходят, конечно...

А как он должен сдурить?

ну я не очень-то хорошо разбираюсь в потрохах Постгреса.. Может быть, это просто паранойя от незнания :)

Уважаемые, подскажите пожалуйста, какие подводные камни могут быть в подобном, хмм, странном, варианте: http://lpaste.net/357996 Мне нужно атомарно либо обновить "документ" с сохранением предыдущего значения, либо добавить новый "документ", если его ранее не было. Upsert мне тут не поможет - версия 9.4. Вообще, этот вариант работает и на первый взгляд корректно (там trace, для отладки вставленные, показывают, что лишние "ветки" не исполняются), но всё же немного страшновато. А вообще, если сие переписать на PlPgSQL в императивном стиле, оно получится куда логичнее, но, по идее, будет сильно менее эффективно.

@verrens , https://www.postgresql.org/docs/9.6/static/plpgsql-control-structures.html Example 41-2. Exceptions with UPDATE/INSERT

Иначе гонки

Но ведь гонка тут может быть только одна - между select-ом в cur, не вернувшим ничего, и insert-ом, свалившимся с duplicate?

SELECT FOR UPDATE или SELECT FOR SHARE, нє ?

Вроди ж как уже 6 лет в спеке ...

Я уже добавил for update (в ветку cur), буквально сразу после первой публикации:) Вот только от insert-а оно не спасёт

Ну дык оно и не должно спасать если нормально моделька оформлена...

* обычно у всех через жопу, по крайней мере у большинства, где-то по субъективным кофейно-гуще-гаданиям 73%.

а можно пример, так сказать, жопы?)

кстати, много лет лезут гонки insert-update (в другом месте) - исключения логируются, операции повторяются "сверху" - как бы и пофиг :) Будет 2.5, перепишу, может быть..

Типичная Жопа, это : • Незнание того что на свете уже давно есть 6 нормальных форм • неумение и непонимание как работать с предствлениями как на них ложить правила и триггеры, как при это происходит блокировка... (UDF желательно оформлять на сишке, потому что кошерно, иногда с x86 intrinsic'ами) • Желание слезть на Cassandra/MongoDB когда есть BRIN/GIN • Незнание и неумение разделения табличных пространств для холодных / тёплых / гарячих хранилищ • Незнание и неумение готовки CQRS-ES'a и использования встроенного PUB/SUB'a для обновления сторонних представлений etc

Я уже повидал овер дохера контор и стартапов с фразой "Ой, да кому нужны эти нормальные формы", потом через полгода: "Ой, Бля! у нас база уже до петабайта скоро дорастёт, между нодами вакханалия непонятная происходит - давайте слезать на NoSQL", через две недели после запила Монги: "Ой, чего-то у нас ларджовых EC2 нод стало в 3 раза больше, наверное к дождю".

На практике таблички и индексы, накладные расходы на синхронизацию, бывает растут экспоненциальненько... со всеми последствиями, и большой Абзац происходит совсем уж незаметно. Прикольно когда все работают с БД, но никто их не умеет проектировать - потом боль & страдания & увеличение бюджета в 2-3 раза...

Полностью согласен. Хотя, насчёт нормальных форм вот, знать их обязательно, а вот ли использовать всегда и везде - вопрос.

".. использования встроенного PUB/SUB'a для обновления сторонних представлений" - а это что имеется в виду?

я разве что с notify игрался

На практике таблички и индексы, накладные расходы на синхронизацию, бывает растут экспоненциальненько... со всеми последствиями, и большой Абзац происходит совсем уж незаметно. Прикольно когда все работают с БД, но никто их не умеет проектировать - потом боль & страдания & увеличение бюджета в 2-3 раза...

Я когда слышу "монго" читаю это как в проекте сидят недоучки

Проектирование любой реляционной СУБД с использованием всех 6ти нормальных форм подразумевает отсутствие избыточности и оптимальную индексацию - нет проблем с производительностью, ростом базы и журнала транзакций. > а вот ли использовать всегда и везде - вопрос Если на практике не ковыряли 200+ Гб таблички и не делали Explain на 10ти секундных запросах поверх кривых ормов рельсов/hibernate etc ... то естественно будет непонятно.

Я когда слышу "монго" читаю это как в проекте сидят недоучки

Грёбаные хипстеры...

Да, на добавление удаление поля с sql тебе придется прогнать 3 релиза

Ничего страшного я в этом не вижу

Я когда слышу "монго" читаю это как в проекте сидят недоучки

зря, хороший кеш :)

@verrens , https://www.postgresql.org/docs/9.6/static/plpgsql-control-structures.html Example 41-2. Exceptions with UPDATE/INSERT

Кстати, вот если честно, не вижу, чем в моём случае plpgsql-ные statement-ы могут помочь. Логика будет той же, только менее эффективно - у меня всё внутри одного запроса, а тут, по идее, разделение на императивные, так сказать, команды, с подзапросами

твой декларативный запрос и так разбирается в императивный план

".. использования встроенного PUB/SUB'a для обновления сторонних представлений" - а это что имеется в виду?

Если у нас есть CQRS-ES в рамках базы - отдельно используется ограниченное мат. представления для сериализации, т.е. все наши JOIN'ы и тяжёлые запросы с сериализацией в JSON, последующей индексацией уплывают в мат. представление. Ограниченное (Constrainted) означает что мы эти данные храним месяц с последнего логина пользователя, и удаляем опосля... таким образом само представление можно хранить в отдельном табличном пространстве (Table Space) где-то на SSD'шке ещё и в пережатом виде через ZSON, а остальное в 6ой нормальной форме - где-то на православных винтах. Также отдельно формируется не материализованное представление с правилами (RULES) на Запись (INSERT/UPDATE), которое подёргивает PUB/SUB, чистит кэш. Таким образом у нас в рамках CQRS мат представление является моделью чтения, а простое - моделью записи. ES при этом выполняет задачи блокировки и подчистки многоуровневых кэшей, обновления представлений, допустим он может подёргивать SSR какого-то SPA на Node.js / ClojureScript etc.

твой декларативный запрос и так разбирается в императивный план

Да. А функция на PlPgSQL-е разве тоже в такой же императивный план типа-компилируется? Я исходники не смотрел, но всегда думал, что там тупо последовательный вызов заранее заготовленных планов (если не execute)

зря, хороший кеш :)

Это шутка такая ?

Да. А функция на PlPgSQL-е разве тоже в такой же императивный план типа-компилируется? Я исходники не смотрел, но всегда думал, что там тупо последовательный вызов заранее заготовленных планов (если не execute)

Тебе ничего не мешает взять любой другой язык если pl/sql не нравится.

Тебе ничего не мешает взять любой другой язык если pl/sql не нравится.

ну так я и взял "числый" SQL :)

максимально близко, так сказать, к кормушке

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

Тебе ничего не мешает взять любой другой язык если pl/sql не нравится.

Другое дело что функции должны быть чистыми - IMMUTABLE STRICT.

@YuriyYarosh так "PUB/SUB" - это таки notify/listen, или я чего-то ещё пока не знаю?

Да, это notify/listen

ээх, если бы там payload типизированный был..

Просто есть много синонимов этого понятния - EventSource, Pub/Sub, Observable ...

ээх, если бы там payload типизированный был..

Где ?

И notify на ro-реплики распространялись.. Ну да мечтать не вредно

Где ?

в notify, вестимо. Там payload :: Text

а хотелось бы какой-нибудь произвольный record передать

Мы раньше JSONB в бинарном виде гоняли %) С парой хаков...

короч, оно в postgres-е слишком низкоуровневое

ну можно и так, да

Это по SQL стандарту там просто TEXT ...

В самом стандарте pub/sub не особо то и типизирован.

Я у себя пока просто JSON гоняю ... не то что бы быстро, но пока не жалуюсь - хватает.

главное, чтоб в 8000 байт влезло (интересно, откуда у них эта фицра-то вылезла?

Размер страницы для текста

аа, точно. Надо будет потратить-таки время и изучить потроха постгреса.

Очень помогает... особенно если влазить в мат представления и полноценный CQRS-ES ...

Бэкендщикам жизнь очень упрощает.

меня, кстати, в последнее время больше всего парит гонка между базой и её ro-репликами. Вот, например, вешается backend на listen (понятно дело, на rw, т.к. notify на реплики не распространяются), получает уведомление - и сделать бы ему теперь select на ro, но нет, не дошли до туда ещё данные. Эээх...

в итоге на ro- остаются разве что тяжёлые отчёты всякие

> тяжёлые отчёты всякие Нужно правильно ворочить представлениями что бы такого не было. Вообще идеально - все агрегированные плюшки переписывать на сишку...

или вот банальный пример - проверка авторизационной сессии. На каждом запросе backend-а, даже если он из ro- только читает, приходится делать по select-у к rw-, ибо гонка-с.

Типичная Жопа, это : • Незнание того что на свете уже давно есть 6 нормальных форм • неумение и непонимание как работать с предствлениями как на них ложить правила и триггеры, как при это происходит блокировка... (UDF желательно оформлять на сишке, потому что кошерно, иногда с x86 intrinsic'ами) • Желание слезть на Cassandra/MongoDB когда есть BRIN/GIN • Незнание и неумение разделения табличных пространств для холодных / тёплых / гарячих хранилищ • Незнание и неумение готовки CQRS-ES'a и использования встроенного PUB/SUB'a для обновления сторонних представлений etc

О, наконец-то пошла жара! Как пересекаются кассандра и brin/gin и es и pub/sub?

> тяжёлые отчёты всякие Нужно правильно ворочить представлениями что бы такого не было. Вообще идеально - все агрегированные плюшки переписывать на сишку...

Это да, materialized view сильно помогают. Правда, проблема плавно перетекает в их (актуальные) обновления..

или вот банальный пример - проверка авторизационной сессии. На каждом запросе backend-а, даже если он из ro- только читает, приходится делать по select-у к rw-, ибо гонка-с.

Это можно выполнить отдельным ААА представлением.

Это можно выполнить отдельным ААА представлением.

ну, я просто пример привёл. У меня там немного накручено (например, backend подключается к sql-серверу под ролью конкретного пользователя).

или вот банальный пример - проверка авторизационной сессии. На каждом запросе backend-а, даже если он из ro- только читает, приходится делать по select-у к rw-, ибо гонка-с.

Для сессий есть мемкеш и редис

ERROR: S client not available

О, наконец-то пошла жара! Как пересекаются кассандра и brin/gin и es и pub/sub?

> Как пересекаются кассандра и brin/gin BRIN или же BlockRangeIndex может быть использован как замена LSM-tree индекса для табличек больше 4Тб+. GIN очень неплохо индексирует JSONB - монгу в топку. EventSource == pub/sub.

в любом случае, время между репликацией отнюдь не нулевое и при этом не особо-то предсказуемое, и с этим нельзя не считаться.

Для сессий есть мемкеш и редис

Это нынче считается довольно плохой практикой - есть Stateless сессии, есть JWT. Куда бы не пришёл запрос - он нормально обработается.

> EventSource == pub/sub ох, нет

или вот банальный пример - проверка авторизационной сессии. На каждом запросе backend-а, даже если он из ro- только читает, приходится делать по select-у к rw-, ибо гонка-с.

remote_apply режим репликации есть, тогда не будет такой гонки. Мастер дождется когда на реплике в файлах значение появится, прежде чем ответить своему клиенту

ну, я просто пример привёл. У меня там немного накручено (например, backend подключается к sql-серверу под ролью конкретного пользователя).

Мне будет сложно объяснить на пальцах левой ноги как сделать Аутентификацию/Авторизацию в рамках СУБД для обычных CURD приложений, все особенности реализации и поддержки подобных решений.

Для сессий есть мемкеш и редис

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

> EventSource == pub/sub ох, нет

Например, почему нет ?

Потому что это перпендикулярные понятия?

ES существует без того, чтобы кто-нибудь публиковал, а кто-то подписывался, и наоборот.

remote_apply режим репликации есть, тогда не будет такой гонки. Мастер дождется когда на реплике в файлах значение появится, прежде чем ответить своему клиенту

Знаю, но это сказывается на производительность мастера, плюс мастер начинает зависеть от "живучести" реплик, что не очень-то приемлимо, по крайней мере в моём случае.

ES существует без того, чтобы кто-нибудь публиковал, а кто-то подписывался, и наоборот.

Святая вера в DDD ...

стоп, EventSource - вы имеете в виду тот, что в http?

Нет, тот что в CQRS-ES.

аа, понятно, пардон.

Святая вера в DDD ...

well that's an argument

Знаю, но это сказывается на производительность мастера, плюс мастер начинает зависеть от "живучести" реплик, что не очень-то приемлимо, по крайней мере в моём случае.

Если внутри одного дц, то почти не сказывается, характерный пинг на порядок меньше времени коммита.

well that's an argument

Реализация декларативных плюшек в рамках представлений СУБД чуток полностью ставит крест на существующей C#/Java ORM-вакханалии.

well that's another argument

Для асинхронной можно спросить lsn на мастере и дождаться его на реплике

Если внутри одного дц, то почти не сказывается, характерный пинг на порядок меньше времени коммита.

ну, у меня не 10Г между серверами. Но в общем, конечно, это вариант; главное понимать его пользу и соответствующую за это цену.

Угу

А вот задача: надо выполнить запрос только в том случае, если некий подзапрос не вернул ни одной строчки. Пока в голову пришёл лишь такой хак: With q As (..) Select tbl.* From tbl Left Outer Join q On (True) Where (q.some_field is Null) Можно как-нибудь покрасивше?

Where not exists не подойдёт?

Where not exists не подойдёт?

О, ещё как подойдёт, спасибо! Я и не предполагал, что оно существует отдельно от PlPgSQL (век живи - век учись)

О, ещё как подойдёт, спасибо! Я и не предполагал, что оно существует отдельно от PlPgSQL (век живи - век учись)

Пожалуйста

надо чаще документацию перечитывать :)

Реализация декларативных плюшек в рамках представлений СУБД чуток полностью ставит крест на существующей C#/Java ORM-вакханалии.

Что?

> Как пересекаются кассандра и brin/gin BRIN или же BlockRangeIndex может быть использован как замена LSM-tree индекса для табличек больше 4Тб+. GIN очень неплохо индексирует JSONB - монгу в топку. EventSource == pub/sub.

Именно больше 4ТБ ? 1ТБ или 100ГБ мало будет?

=# select count(id) from rambo_vehicle; count ---------- 38817536 (1 row) =# select count(id) from forensics_forensic; count ---------- 51960595 (1 row)

https://dumpz.org/2698499/

Есть запрос сгенерированый через Django ORM