Хочу хранить юзерские сессии в постгресе, вместо того чтоб разворачивать Редис: можно ли как-то заставить движок держать всю таблицу в памяти и отключить на ней fsync/wal?

какая версия постгри?

хотя, даже в 9.2 есть возможность создавать UNLOGGED-таблицы, транзакции в которых не проходят через WAL. И соответственно они не реплицируются

А зачем редис? Мемкэша не хватает? Максимально просто, никакого оверхеда

PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17), 64-bit

А зачем редис? Мемкэша не хватает? Максимально просто, никакого оверхеда

+1

Хочу хранить юзерские сессии в постгресе, вместо того чтоб разворачивать Редис: можно ли как-то заставить движок держать всю таблицу в памяти и отключить на ней fsync/wal?

И когда эти таблицы распухнут, от того что автовакуум не успевает за ними, а с первого раза подобрать всё идеально не получится и все давно в проде, вы пожалеете, что загнали это в постгрю. А меня вот мечта, как уговорить разрабов вынести это Г из базы в кейвалью

И когда эти таблицы распухнут, от того что автовакуум не успевает за ними, а с первого раза подобрать всё идеально не получится и все давно в проде, вы пожалеете, что загнали это в постгрю. А меня вот мечта, как уговорить разрабов вынести это Г из базы в кейвалью

подсунуть fdw на какое-нибудь другое хранилище не вариант?

А зачем редис? Мемкэша не хватает? Максимально просто, никакого оверхеда

ну редис довольно просто поднимается, и в нем много разных типов данных, pubsub, размер объекта до 512мб и так далее

Хочу хранить юзерские сессии в постгресе, вместо того чтоб разворачивать Редис: можно ли как-то заставить движок держать всю таблицу в памяти и отключить на ней fsync/wal?

set synchronuous_commit to off; и alter table aaa set unlogged;

уберёт 90% хождений в диск

вообще всегда как что берусь делать, теряюсь в плане того где хранить сессии, стараюсь использовать jwt где это возможно

set synchronuous_commit to off; и alter table aaa set unlogged;

воу спасибо, потестирую

сессии в jwt?

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

сессии в jwt?

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

а я все равно кажется не ту ссылку закинул лол

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

ну вроде бы все так и есть

ну редис довольно просто поднимается, и в нем много разных типов данных, pubsub, размер объекта до 512мб и так далее

Я про оверхед редиса для хранения сессий. Ну и рсубд для сессий... Мсье знает толк в извращениях, надеюсь не доведётся такое поддерживать

Да, я знаю, что можно. Но говно же медленное выходит

Тем более, если персистентность не требуется

512 метров объекта, это хорошо, но в других местах

Да, я знаю, что можно. Но говно же медленное выходит

Ну memcached/redis мне в этом проекте совсем не нужен, и совсем не хочется добавлять еще один point of failure

Хреново что TTL для тупла из коробки не задать

Вот постгрес в раме, без стабилизаторов в виде фсинка... Сама устойчивость?

не не, не весь постгрес, а одна таблица же

Жесть. Кстати, мемкэш туп и прост, тем самым рисков падения немного. Ну и key-value. Либы есть в большинстве языков. Хз, зачем тебе такой геморрой. Не успел вакуум, сожралась рама, своп. И снова копайся с базой

Жесть. Кстати, мемкэш туп и прост, тем самым рисков падения немного. Ну и key-value. Либы есть в большинстве языков. Хз, зачем тебе такой геморрой. Не успел вакуум, сожралась рама, своп. И снова копайся с базой

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

Приложение то на чем?

Приложение то на чем?

нода

хотел на go начать, но долго осиливать их ORM, и производительность почти идентична

Глянь ещё про ledis. Это вроде форк редиса, но там многопоточность, все дела

Ну да

Глянь ещё про ledis. Это вроде форк редиса, но там многопоточность, все дела

не форк, а отдельный проект похоже на Го

А можно всю схему пометить unlogged? \cc @Komzpa

не встречал

Можно конечно выдрать все таблицы из information_schema и на pl/pgsql обойти. Но вообще, было бы удобно. Допустим есть схема биллинга – обсчет всегда происходит на мастере, а эти таблицы на слейвах нафиг не нужны.

эмм, unlogged таблицы после креша транкейтятся

это то, чего ты хочешь в биллинге? :)

ну, эм, то есть select st_asx3d('LINESTRING EMPTY'); от любого юзера по идее сотрёт тебе все unlogged таблицы

Нубский вопрос про то как правильно сделать типичный биллинг, пока есть время исправить если что делаю не так: - Пользователи покупают подписки, выбирая из N планов - Подписки ребиллятся раз в месяц или раз в год - Активация подписки выставляет счетчики доступных юзеру действий до следующего продления Моя схема: Plans - id - name - actions_count - price - ... Users - id - plan_id :: Plan - actions_left - paid_till - ... Orders - id - user_id :: User - plan_id :: Plan - status - ... Проблем не должно возникнуть?

эмм, unlogged таблицы после креша транкейтятся

а не temp транкейтятся?

Нубский вопрос про то как правильно сделать типичный биллинг, пока есть время исправить если что делаю не так: - Пользователи покупают подписки, выбирая из N планов - Подписки ребиллятся раз в месяц или раз в год - Активация подписки выставляет счетчики доступных юзеру действий до следующего продления Моя схема: Plans - id - name - actions_count - price - ... Users - id - plan_id :: Plan - actions_left - paid_till - ... Orders - id - user_id :: User - plan_id :: Plan - status - ... Проблем не должно возникнуть?

Вообще по уму должна быть реализована т.н. "Главная бухгалтерская книга" – где есть счет системы и счета всех пользователей, все проводки (транзакции) от пользователя системе и т.п., – иначе вы не сможете свести "дебит с кредитом" и свести балансы

У нас есть проект один, в котором есть толькотаблица с балансами юзеров и инвойсами и не так давно мы обнаружили баг с адвизори локами, в которых ключем присутствовали два разных ID по невнимательности разработчика. Платежная система слала два запроса – один на фронтенд (редирект), другой на бекенд (подтверждение платежей) и в случае если они пападали в одну секунду – баланс пополнялся дважы, но бабки было уже не свести (но мы свели, потому что у нас есть еще косвенное логирование операций).

Вообще по уму должна быть реализована т.н. "Главная бухгалтерская книга" – где есть счет системы и счета всех пользователей, все проводки (транзакции) от пользователя системе и т.п., – иначе вы не сможете свести "дебит с кредитом" и свести балансы

Хмм, а как это на практике сделать? Добавить схему Transactions с полями user, debit, credit и добавлять новую строку при изменении статуса заказа?

У нас есть проект один, в котором есть толькотаблица с балансами юзеров и инвойсами и не так давно мы обнаружили баг с адвизори локами, в которых ключем присутствовали два разных ID по невнимательности разработчика. Платежная система слала два запроса – один на фронтенд (редирект), другой на бекенд (подтверждение платежей) и в случае если они пападали в одну секунду – баланс пополнялся дважы, но бабки было уже не свести (но мы свели, потому что у нас есть еще косвенное логирование операций).

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

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

Ну и что, фактически у вас те же балансы – с которых раз в N времени списываются средства за план.

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

В случае апгрейда – больше

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

Точно

Алгоритм описан по "Главная бухгалтерская книга" в инете

У нас есть проект один, в котором есть толькотаблица с балансами юзеров и инвойсами и не так давно мы обнаружили баг с адвизори локами, в которых ключем присутствовали два разных ID по невнимательности разработчика. Платежная система слала два запроса – один на фронтенд (редирект), другой на бекенд (подтверждение платежей) и в случае если они пападали в одну секунду – баланс пополнялся дважы, но бабки было уже не свести (но мы свели, потому что у нас есть еще косвенное логирование операций).

А есть смысл хранить инвойсы? Не лучше их генерировать на лету по запросу?

Сформированный заказ на оплату может быть не оплачен.

Когда юзер перешел на страницу оплаты в платежную систему – он может тупо закрыть окно

каждая платежная система передает внутренний ID операции (и подтверждает по нему)

Поэтому инвойсы нужны, иначе вы не будете знать о их статусе исполнения

Поэтому инвойсы нужны, иначе вы не будете знать о их статусе исполнения

Разве таблицы orders с полем status не хватит для этого?

ну это те же яйца, только в профиль)

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

ERROR: S client not available

Ну это все от специфики бизнеса – понимание "как надо" приходит с хотелками комерса и факапами с балансами.

А вы с несколькими платежными системами работали? Я хочу начать со stripe и fondy - есть смысл тащить в базу данные о гейтах (тут имею ввиду ключи доступа), или оставить это в env vars апи сервера?

Думаю что нужно, и еще иметь флаг активен гейт или нет, чтоб оперативно без рестартов обновлять это дело

Гейты ака креды ака пароли, лучше зашить куда-нибудь в environments на продакшн серверах (имхо) или файл доступ к которому имеет только приложение если речь об этом. Алсо, весь обмен с платежными системами есть смысл хранить, делать либо а ля enum для каждой платежной системы – либо вообще по таблице на каждую.

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

Коллеги, а можно как-нибудь изменить тип колонки таблицы над которой накручена пачка materialized view зависящих от этой колонки не грохая их? Т.е. чтобы они сами пересоздались

Всем привет. Подскажите, кто знает. Нужно ограничение уникальности на n количество полей. Например есть три поля и значения в них не могут повторяться. Получается мне нужно ограничение не только в пределах столбца но и столбцов строки строка1: 1|2|3 строка2: 4|5|6 и теперь эти числа не могут больше использоваться. Из коробки ничего нет, триггер писать?

хм, как в пределах строки я придумал

create table test ( col1 INT CHECK (col1 NOT IN (col2, col3)), col2 INT CHECK (col2 NOT IN (col1, col3)), col3 INT CHECK (col3 NOT IN (col1, col2)) );

а как теперь в пределах столбцов других строк

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

Всем привет. Подскажите, кто знает. Нужно ограничение уникальности на n количество полей. Например есть три поля и значения в них не могут повторяться. Получается мне нужно ограничение не только в пределах столбца но и столбцов строки строка1: 1|2|3 строка2: 4|5|6 и теперь эти числа не могут больше использоваться. Из коробки ничего нет, триггер писать?

Eav использовать нельзя? Create table cols(col_val int primary key , col_num int, row_key int) ;

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

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

повесть уникальный индекс ?

он не решает задачу только в пределах столбца

а, я думал ты решил про уникальность в строке

уникальный индекс помог бы со столбцом

да но не другим столбцом в другой строке ))

сделаю наверное отдельную таблицу - ссылка на сущность, код, какая операция. И на код уникальный индекс

С eav начнутся проблемы при большом количестве столбцов. Множественные join и вот это всё плохо скажется на производительности . А если колонок всего три, то почему бы и нет.

уникальный индекс помог бы со столбцом

1 2 3 2 1 4

вот такого не должно быть

спасибо за советы

Sequence использовать в качестве значений - не подходит?

Sequence использовать в качестве значений - не подходит?

желательна хоть какая-то случайность для хоть какой-то криптостойкости ))))

Коллеги, приветствую! Внимание, вопрос: есть ли у postgres аналог Events shelduler мускульного?

Из коробки нет, но есть лучше чем Events shelduler https://github.com/citusdata/pg_cron

Из коробки нет, но есть лучше чем Events shelduler https://github.com/citusdata/pg_cron

А чем же оно лучше, если не секрет?