Size: a a a

Чат конференции HighLoad++

2019 November 10

PK

Phil Kulin in Чат конференции HighLoad++
Yuran
Кажется, PostgreSQL для очередей не очень хорошо подходит :).
Там есть SELECT FOR UPDATE SKIP LOCKED. Что делает Postgres очень вкусным для очереди. Например финансовых транзакций. Есть на эту тему даже очень хороший доклад моего тезки на какой-то конференции. Лет пять назад.
источник

Y

Yuran in Чат конференции HighLoad++
Phil Kulin
Там есть SELECT FOR UPDATE SKIP LOCKED. Что делает Postgres очень вкусным для очереди. Например финансовых транзакций. Есть на эту тему даже очень хороший доклад моего тезки на какой-то конференции. Лет пять назад.
Наверняка это на много параллельных запросов масштабируется довольно плохо из-за необходимости держать локи на одни и те же строки. Но если конкурентность таких запросов невысокая и в целом операций вроде UPDATE/DELETE немного, то норм.
источник

PK

Phil Kulin in Чат конференции HighLoad++
Yuran
Наверняка это на много параллельных запросов масштабируется довольно плохо из-за необходимости держать локи на одни и те же строки. Но если конкурентность таких запросов невысокая и в целом операций вроде UPDATE/DELETE немного, то норм.
Нормально там все масштабируется. С чего там несколько локов? Считай это а просто фильтр выборкт и возможность обрабатывать в парралель
источник

p

pragus in Чат конференции HighLoad++
Phil Kulin
Я вон недели две назад отказался пихать данные в k/v в угоду кастомному ma[]map[] на Go в программе в три строчки. Потому что все k/v всё хорошо, но pprof мне подсказывает....
От чего отказался?
источник

PK

Phil Kulin in Чат конференции HighLoad++
pragus
От чего отказался?
В первую очередь от болта. Но подумав и от всего остального. Ты знаешь эту историю. Неясно зачем переспрашиваешь
источник

Y

Yuran in Чат конференции HighLoad++
Phil Kulin
Нормально там все масштабируется. С чего там несколько локов? Считай это а просто фильтр выборкт и возможность обрабатывать в парралель
Ну если ты хочешь разбирать такую очередь, скажем, в 500 потоков, то у тебя потенциально может быть ~500 одновременных запросов в одну и ту же таблицу, которые хотят залочить одни и те же данные. В случае с PostgreSQL такое количество одновременно выполняющихся запросов сложно себе представить, но даже 50 таких запросов может быть вполне достаточно, чтобы конкурентность за одни и те же строки была достаточной, чтобы всё встало колом.

Частично эта тема затронута (для MySQL, правда) в этой статье: https://habr.com/ru/company/badoo/blog/204028/, а также вот тут: https://youtu.be/kCHndVErINg?t=1222
источник

p

pragus in Чат конференции HighLoad++
Phil Kulin
В первую очередь от болта. Но подумав и от всего остального. Ты знаешь эту историю. Неясно зачем переспрашиваешь
А, болт. У меня в памяти осело только про тот код что ты показывал и болт.

Но мне кажется что без довольно изощрённых костылей любая бд на memory mapped files на go будет не очень.

Тем более, у тебя там запись, а не чтение
источник

PK

Phil Kulin in Чат конференции HighLoad++
Yuran
Ну если ты хочешь разбирать такую очередь, скажем, в 500 потоков, то у тебя потенциально может быть ~500 одновременных запросов в одну и ту же таблицу, которые хотят залочить одни и те же данные. В случае с PostgreSQL такое количество одновременно выполняющихся запросов сложно себе представить, но даже 50 таких запросов может быть вполне достаточно, чтобы конкурентность за одни и те же строки была достаточной, чтобы всё встало колом.

Частично эта тема затронута (для MySQL, правда) в этой статье: https://habr.com/ru/company/badoo/blog/204028/, а также вот тут: https://youtu.be/kCHndVErINg?t=1222
Спасибо. Это интересно
источник

Y

Yuran in Чат конференции HighLoad++
Возможно, конечно, в PostgreSQL этот запрос не будет пытаться залочить одни и те же строки, а будет как-то более грамотно (как?) сериализовать доступ к таблице, но тогда мне об этом интересно было бы послушать, т.к. очередями на базах данных я занимался довольно много в своей жизни :).
источник

PK

Phil Kulin in Чат конференции HighLoad++
pragus
А, болт. У меня в памяти осело только про тот код что ты показывал и болт.

Но мне кажется что без довольно изощрённых костылей любая бд на memory mapped files на go будет не очень.

Тем более, у тебя там запись, а не чтение
В моей задаче в принципе бд не нужна. На диске. Там из исходника поднятие всегда обгонять будет любую запись. В итоге запись вообще не нужна. Это кстати хорошая микроистория про "огдядись, может тебе это не надо". Я думаю про лояльное к gc btree, чтобы *.domain можно было матчить, но это позжу
источник

PK

Phil Kulin in Чат конференции HighLoad++
Yuran
Возможно, конечно, в PostgreSQL этот запрос не будет пытаться залочить одни и те же строки, а будет как-то более грамотно (как?) сериализовать доступ к таблице, но тогда мне об этом интересно было бы послушать, т.к. очередями на базах данных я занимался довольно много в своей жизни :).
Рекомендую кстати тогда найти презентацию @dphil
источник

p

pragus in Чат конференции HighLoad++
Phil Kulin
В моей задаче в принципе бд не нужна. На диске. Там из исходника поднятие всегда обгонять будет любую запись. В итоге запись вообще не нужна. Это кстати хорошая микроистория про "огдядись, может тебе это не надо". Я думаю про лояльное к gc btree, чтобы *.domain можно было матчить, но это позжу
Зачем тебе btree?
источник

PK

Phil Kulin in Чат конференции HighLoad++
pragus
Зачем тебе btree?
Я же написал - чтобы *.domain прогонять
источник

p

pragus in Чат конференции HighLoad++
Phil Kulin
Я же написал - чтобы *.domain прогонять
Что именно делать? Имхо, тебе оно все равно не надо
источник

PK

Phil Kulin in Чат конференции HighLoad++
pragus
Что именно делать? Имхо, тебе оно все равно не надо
Я хочу, чтобы поддомены соазу показывались. Prefix scan. Но пока пофиг да
источник

KD

Kirill D in Чат конференции HighLoad++
Phil Kulin
Я же написал - чтобы *.domain прогонять
Обратный radix, lol
источник

PK

Phil Kulin in Чат конференции HighLoad++
Kirill D
Обратный radix, lol
Или так да
источник

p

pragus in Чат конференции HighLoad++
Phil Kulin
Или так да
Это лучше всего
источник

PK

Phil Kulin in Чат конференции HighLoad++
pragus
Это лучше всего
обратное я могу сделать на ходу. radix да, но писать сам не буду
источник

PD

Phil Delgyado in Чат конференции HighLoad++
Yuran
Я не утверждаю, что PostgreSQL — плохая СУБД. Мне она нравится, но довольно странно видеть от разработчиков (или от сообщества) попытки доказать всему миру, что PostgreSQL лучше, чем MongoDB, приводя такие слайды. Преимущество PostgreSQL прежде всего в его зрелости, хорошей производительности, наличии схемы, и т.д., но уж точно не в том, что на каком-то сценарии работы, который, как вы сами признали, никто не использует, он показывает производительность в 25 раз выше.

Если уж на то пошло, то PostgreSQL, например, не подходит для типичной веб-нагрузки (речь про PHP+PostgreSQL) когда к базе может открываться и закрываться сотни или тысячи соединений в секунду. Для MySQL и MongoDB это не проблема, но для PostgreSQL нужно использовать pgBouncer, который своих проблем добавляет.

Я говорю про то, что, по моему мнению, PostgreSQL сообществу стоило бы более тщательно готовить доклады и знать преимущества и недостатки других СУБД, и как они применяются в реальности, чтобы не портить себе же репутацию такими слайдами.
А зачем открывать сотни коррекций в секунду? Это просто неправильный метод работы с любой базой.
источник