LINUX.ORG.RU

Конкурентное обновление таблицы с ресурсами

 , ,


0

2

Вкратце опишу задачу. У компании есть клиенты, от имени которых она ведет переписку с третьими сервисами используя google workspace.

У каждого email эккаунта в google workspace можно завести алиас с помощью api, и использовать его в дальнейшем для конкретной переписки. После окончания переписки алиас можно просто удалить с помощью того же api. Это нужно потому, что есть лимит на количество алиасов для каждого email эккаунта в google workspace.

Бэк реализован на python с использованием sqlalchemy. БД - postgres.

Поэтому возникла идея создать две таблицы. Одну - со списком имеющихся email эккаунтов. И вторую, где будет список использующихся в данный момент алиасов для каждого email.

То есть во второй таблице (aliases) будут следующие поля: id, email, alias_email.

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

То есть делаем запрос вроде

select email, count(*)
from aliases
group by email

А затем выбираем из результата любой email, у которого не превышен лимит и вставляем новую запись со свежим алиасом для этого email в эту же таблицу. Ну и создаем алиас помощью google workspace api.

При окончании переписки просто удаляем запись с алиасом из таблицы и удаляем с помощью api сам алиас.

Возникает ситуация гонок, надо бы на момент выбора алиаса лочить таблицу aliases.

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


Ответ на: комментарий от Toxo2

Не представляю себе нужды в таком количестве реальных подключений к БД одновременно. На таких количествах уже само ядро Линукса начинает помирать (и надо крутить somaxconn), какой уж там ПГ.

там «все сложно»… мы когда начинаем говорить про какие-то пулы соединений и прочее, мы совершенно упускаем тот факт, что приклад изначально работает ровно так как описал ФЗ (т.е. как кому было бы неприятно, но факт остается фактом, что кто девушку платит, тот ее и танцует), да, ФЗ может быть не в курсе всей той ебли, которая может возникать, да, ФЗ можно где-то убедить, что сделать иначе будет куда лучше, но в целом на выходе будет так, что готовый приклад будет соответствовать ожиданиям ФЗ (он может где-то даже ожидаемо валиться, там какие-то обращения в поддержку пойдут и пр., но он условно будет работать)

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

Представим ситуацию: приклад что-то выполняет в БД и у него возникает потребность либо поДсмотреть данные как они были до транзакции (тут что-то можно сделать на уровне фреймворка, но не все), либо выполнить некую компенсацию, после транзакции - там и определенно нужно новое соединение, в неком corner case, когда размер пула - это ровно одно соединение, мы очевидно логически придем к выводу что мы получим мертвую блокировку, проблема в том, что эта проблема никак не решается на самом деле, ребята их HikaryCP все эти беды расписали: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing - я тут понимаю, что на LOR жава уважением не пользуется, но там не про жаву, там именно про проблемы с БД идет речь, нужно вдумчиво читать и потом думать. Для PostgreSQL проблема «решается» исключительно за счет того, что нужно просто забить на нее и херачить по 10 тысяч соединений - до большего ребята еще не доросли и, увы, не дорастут никогда.

borisych ★★★★★
()
Ответ на: комментарий от anonymous

там ровно как я и описал:

Есть еще решения от отечественного производителя: https://postgrespro.ru/docs/enterprise/16/connection-pooling - сделать более всратее нужно еще постараться

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

borisych ★★★★★
()
Ответ на: комментарий от borisych

Просмотрел что ты ссылку кидал, извиняюсь.

В остальном ничего не понял.

В чем разница если пул говно и не обрабатывает правильно клиентов или пг сожрал всю озу ворк_меммаксконекшнсчто-тоеще и не отрабатывает клиентов?

Почему если первый случай, то виноват пулпрокси, а если второй то база не виновата а виноваты клиенты?

anonymous
()
Ответ на: комментарий от anonymous

Почему если первый случай, то виноват пулпрокси, а если второй то база не виновата а виноваты клиенты?

конкретно PostgreSQL виноват всегда, к сожалению, это аксиома

В чем разница если пул говно и не обрабатывает правильно клиентов или пг сожрал всю озу ворк_меммаксконекшнсчто-тоеще и не отрабатывает клиентов?

в приличных СУБД вполне себе допускается идея, что какие-то спорадические запросы требуют больше ресурсов, чем того ожидалось, поэтому у них (приличных СУБД) есть пул памяти под плохие запросы, в PostgreSQL же все через жопу сделано: надо тебе больше памяти - дрочи диск, и насрать что ресурсы еще есть, можно влиять на это в том плане, что под /tmp можно ресурсы в памяти выделять, но оно выглядит на столько плохо на сколько оно есть.

borisych ★★★★★
()
Ответ на: комментарий от ggrn

У меня сейчас в клиентах ребятки на C#. По какой-то неведомой мне причине не хотят использовать C#-вые механизмы-ОРМы. И про SQL вообще думать не хотят. Видимо я им и нужен-то как такой ОРМ-с-глазами и мигратор.

Как-то так. Но тут всё зыбко. Всё может поменяться.

Toxo2 ★★★★
()
Ответ на: комментарий от borisych

Я бы может поспорил, но ты выглядишь как жирный оракловец, который в треде про постгрес (смотри оп пост) говорит только о том что пг говно.

Ты может и прав (я не дба и спорить не буду), но нахер тут твои простыни я не понимаю.

Они интересные, но не тут.

anonymous
()
Ответ на: комментарий от borisych

Если оставаться ближе к тебе топика, то мое мнение

Это, наверное,опечатка -> «тебе» == «теме».

На самом деле я только сейчас вчитался в саму тему. Изначально возбудился в общем на интересные мне ключевые слова.

Так вот - если оставаться ближе к теме топика, то мое мнение - вот именно как-то так и рождается в народе нелюбовь к ПГ, когда начинают тянуть в него всякую ерунду, для которой он изначально не предназначен. Я бы приложил максимум усилий, чтоб уговорить бэкэндщиков с этой ерундой воевать как-нибудь самим и другими средствами, нежели РСУБД.

Toxo2 ★★★★
()