эх, такая теория сорвалась)

Ребят, а у постгри есть асинхронный протокол? Чтобы по одному соединению более 1 запроса можно было гонять одновременно?

или только послал и сиди жди?

в рамках сокета - жди

но никто не мешает открыть еще сессии

ну точнее, если никто не запрещает

Частая. Особенно для новых систем. На этапе разработки невозможно учесть специфики данных. Допустим мы храним историю изменений в той же таблице и предполагаем, что изменений будет достаточно много - строим индекс с доп полем is_actual - и на начальном этапе - все тыркаются вносят/правят данные... Достаточно много как актуальных так и исторических данных... Индекс сразу фильтрует большую часть записей по признаку актуальности. Потом пользователи "освоились" и практически всегда вносят данные без ошибок... У нас доля актуальных растёт и индекс становится не привлекательным... мертвым

А Вы уверены, что хранение истории в той же таблице —- правильная архитектура (я просто сейчас как раз читаю про хронлогические БД)? А то в ненормализованных базах бывает всё что угодно, и даже индексы / их удаление совсем не помогает. ;)

в рамках сокета - жди

В этом в вопрос. Сам протокол не умеет делать асинхронное взаимодействие?

В этом в вопрос. Сам протокол не умеет делать асинхронное взаимодействие?

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

Ок. А может кто знает, есть ли планы сделать настоящий асинхронный протокол? Чтобы по 1 соединению гонять много запросов.

Ок. А может кто знает, есть ли планы сделать настоящий асинхронный протокол? Чтобы по 1 соединению гонять много запросов.

а у кого такое есть?

Ок. А может кто знает, есть ли планы сделать настоящий асинхронный протокол? Чтобы по 1 соединению гонять много запросов.

А как вы это видите на уровне работы базы?

все таки запросы, это не только селекты...

а у кого такое есть?

Вроде как rethinkdb умеет. Ну и там особой магии нету - добавляешь всем запросам айди, и потом при приеме ответа по айди понимаешь, какому запросу пришел ответ.

А Вы уверены, что хранение истории в той же таблице —- правильная архитектура (я просто сейчас как раз читаю про хронлогические БД)? А то в ненормализованных базах бывает всё что угодно, и даже индексы / их удаление совсем не помогает. ;)

Я не об архитектуре, я об принципе возникновения такой ситуации. Вообще историю можно хранить в той же "таблице", если бить на партиции

Вроде как rethinkdb умеет. Ну и там особой магии нету - добавляешь всем запросам айди, и потом при приеме ответа по айди понимаешь, какому запросу пришел ответ.

точно-точно в один коннект?

точно-точно в один коннект?

Инфа не 100%, но вроде как да. Ну и я не вижу в этом особых проблем - я такое делал на уровне приложения по вебсокету. Это стандартная практика.

все таки запросы, это не только селекты...

грязных данных и коллизий можно и в разных коннектах нахватать, тут разницы имхо особой нету

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

как быть с ворк_мем?

(посолить)

я не настоящий сварщик, я только спросить ?

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

а зачем?

Я не об архитектуре, я об принципе возникновения такой ситуации. Вообще историю можно хранить в той же "таблице", если бить на партиции

Видите ли, я говорю о том, что у каждого, у кого как-то "плохо работает", скажем, EAV, на самом деле есть одна основная проблема, и она вовсе не с индексацией. ;) Но приницип я понял, спасибо.

а зачем?

Меньше соединений - меньше накладных расходов. Плюс у нас есть шареный постгрес, и по требованию выдают только ограниченное количество соединений. Так был бы асинхронный драйвер и буквально парчкой соединений обошелся, и другим бы не мешал.

что-то вы в этой предметной области не понимаете, либо я вас не понимаю...

что именно непонятно?

Ок. А может кто знает, есть ли планы сделать настоящий асинхронный протокол? Чтобы по 1 соединению гонять много запросов.

планы есть: https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com

https://en.wikipedia.org/wiki/RethinkDB (а вернее русский раздел) говорит о цепочках вызовов функций ReQL

а у кого такое есть?

известные мне примеры: Tarantool и MySQL X Protocol поддерживают pipelining

планы есть: https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com

Круто!

Подготовить эти данные фоновым процессом никак не связанным с работой веб сервера.

это типа API) JSON-RPC)

если принципиальной разницы нет, грузить db или app сервер, какой вариант лучше?

db. но я бы эти данные в базу скопировал. а там уже селекты, джоины, вот это вот всё

без джанг и питонов

Подскажите, существует ли способ сделать ограничение по сумме строк? http://sqlfiddle.com/#!17/7f8dc/1 CREATE TABLE items ( id serial primary key, value int ); INSERT INTO items (value) VALUES (1), (1), (0), (1), (1); -- Какой-то триггер или constraint, чтобы сумма последних трёх строк не могла быть больше 2 -- не должно срабатать, можно вставить только 0: INSERT INTO items (value) VALUES (1);

без джанг и питонов

ну, там API нужно)

просто надо раз в 10 минут примерно синхронизировать (проверять, не сломалась ли одна панелька относительно другой)

ну, в общем я вроде сделал, оно довольно быстро работает)

Подскажите, существует ли способ сделать ограничение по сумме строк? http://sqlfiddle.com/#!17/7f8dc/1 CREATE TABLE items ( id serial primary key, value int ); INSERT INTO items (value) VALUES (1), (1), (0), (1), (1); -- Какой-то триггер или constraint, чтобы сумма последних трёх строк не могла быть больше 2 -- не должно срабатать, можно вставить только 0: INSERT INTO items (value) VALUES (1);

Что значит "последних трёх"?

Что значит "последних трёх"?

С максимальными тремя id, например. Надо было наверное пример с датами лучше. Строки за последние пять минут должны быть меньше определённого лимита.

С максимальными тремя id, например. Надо было наверное пример с датами лучше. Строки за последние пять минут должны быть меньше определённого лимита.

Я бы попробовал CONSTRAINT TRIGGER.

Я сделал c constraint trigger, но если в рамках одной транзакции вставить две записи по одтельности проходящие лимит, а в сумме дающие превышение, то триггер не ловит этот момент. Т.е. он не видит другую запись, которая ещё не закоммичена.

Я сделал c constraint trigger, но если в рамках одной транзакции вставить две записи по одтельности проходящие лимит, а в сумме дающие превышение, то триггер не ловит этот момент. Т.е. он не видит другую запись, которая ещё не закоммичена.

Ловит. Use SERIALIZABLE, Luke. ;)

С двумя конкурирующими транзакциями SERIALIZABLE меня спасёт? =)

Всем привет! Я Даша и вообще пишу на Python, но сейчас не об этом. Тут ищу SQL разработчика в команду МегаФон. Предстоит участвовать в создании аналитических сервисов, предобрабатывать данные (верификация, селекция и т.д.) и поддерживать документацию по процессу обработки. Нужно: – Отлично знать SQL (само собой); – Уметь в Excel продвинутом уровне; – Опыт с промышленными СУБД (Oracle, PostgreSQL, MySQL тд); – Опыт опыт построения систем хранения данных; – Техническое образование. Помимо зарплаты, ждет классный опыт в телекоме и обработке больших данных, офис в центре Москвы с возможностью гибкого графика, полное оформление, страховка и плюшки в виде компенсации мобильной связи и скидок в спортзале. Не кидайтесь тапками :) Кому интересно, резюме можно отправить тут → https://goo.gl/19eN7F

С двумя конкурирующими транзакциями SERIALIZABLE меня спасёт? =)

Да, конечно. Это вообще панацея (я не шучу).

Да, конечно. Это вообще панацея (я не шучу).

Спасибо, в документации как раз примеры на SUM. Почему-то сразу на это не обратил внимания.

http://risovach.ru/upload/2017/10/mem/ne-nado-tak_159262837_orig_.jpg

http://risovach.ru/upload/2017/10/mem/ne-nado-tak_159262837_orig_.jpg

Почему, тоже бд.

Почему, тоже бд.

Программный продукт для которого нужны совсем другие навыки, чем те, которыми обладают DBA

Я шутил)

сохранил в #избранное

Курс молодого бойца PostgreSQL https://habrahabr.ru/post/340460/ Tags: Программирование, SQL, PostgreSQL, Postgres, базы данных, СУБД Author postgres on #habrahabr

однако какой себе ник отхватил автор...

От скромности не умрёт.

Вроде как rethinkdb умеет. Ну и там особой магии нету - добавляешь всем запросам айди, и потом при приеме ответа по айди понимаешь, какому запросу пришел ответ.

постгрес даже не многопоточный, только процессы плодить умеет по этому о асинхронности нечего и думать. Но это нормально, асинхронность нужна когда есть какой либо io а тут всё в цпу упирается (ио есть но уже внутрях пг)

постгрес даже не многопоточный, только процессы плодить умеет по этому о асинхронности нечего и думать. Но это нормально, асинхронность нужна когда есть какой либо io а тут всё в цпу упирается (ио есть но уже внутрях пг)

на простом prepared-селекте упирается таки в сетевой io, а конкретнее в контекст свичи. В этом месте вычитать пачку коротких запросов и дать пачку коротких ответов может дать x3-x10

последовательные прстые запрос-ответ в один поток это 30-40 ktps, что в постгресе, что в редисе

на простом prepared-селекте упирается таки в сетевой io, а конкретнее в контекст свичи. В этом месте вычитать пачку коротких запросов и дать пачку коротких ответов может дать x3-x10

это немного другое

батчинг в протоколе

помогает это вылечить

я бы батчингом это неназвал... скорее очередь

помогает это вылечить

уже сделали?

вопросс только кто должен крутить эвент луп, сам процесс по идее не может, постмастер?

да не нужен ивент луп, клиент собирает 100 запросов в пачку, посылает их сразу в открытое соединение, конкретному процессу, он обрабатывает их и посылает сразу 100 ответов

в этом виде это конечно бачинг

в итоге посылается не 100 мелких пакетов, а один большой

ну это к асинхронщине отношения не имеет

Всем салам

кто пользуется PostgreSQL 10??

ну это к асинхронщине отношения не имеет

режим работы протокола асинхронный при этом

11dev

она стабильна??

ну это к асинхронщине отношения не имеет

вопрос терминологии. batching/pipelining вполне можно рассматривать как частный случай async IO

режим работы протокола асинхронный при этом

он и сейчас такой

вопрос терминологии. batching/pipelining вполне можно рассматривать как частный случай async IO

это просто оптимизация... асинхроности тут не добавляется

он и сейчас такой

сейчас есть синк/асинк режимы. Но асинк ну умеет в пачки.

Стас, так вы уже это сделали?

или делаете?

https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com#CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=B4dMMZw@mail.gmail.com

ок спс

вот тредик. Не мы и еще не закоммитили. Но работает)

она стабильна??

да

это просто оптимизация... асинхроности тут не добавляется

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

вопросс в обработке ошибок... хех

вот тредик. Не мы и еще не закоммитили. Но работает)

по иронии судьбы сейчас с похожей вещью работаю но не для ПГ

https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-redhat10-10-1.noarch.rpm

вот остюда можно на правильный линк выйти: https://www.postgresql.org/download/linux/redhat/

вот остюда можно на правильный линк выйти: https://www.postgresql.org/download/linux/redhat/

oo thanks

+ k karme )

Sup, судари Есть таблица attr вида: attr_p1, attr_p2, attr_p3 Задача: сделать INSERT INTO table (..) (select distinct attr_p1) и так для каждого аттрибута Проблема: аттрибутов 30 штук, писать 30 insert'ов не очень хочется. С SQL не очень дружу, поэтому прошу помощи

справочники делаете? делайте 30 инсертов

и в чем проблема? копипаст на пару минут

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