p
Писать можно больше (в строках), но для реляционной СУБД это странно, если проще то они про почитать больше. Хотите писать много - юзайте заточенные под это СУБД
а что странного в 80/20, где первое - запись, если речь про деньги?
Size: a a a
2020 January 16
KS
а что странного в 80/20, где первое - запись, если речь про деньги?
От задачи, у вас списания идут в несколько К rps?)
p
От задачи, у вас списания идут в несколько К rps?)
это из прошлого. там сначала hold, потом списание
SB
Это разные СУБД, разное железо и разные профили, тут не запрос к СУБД, а к сервису с его запросами (не одним) и его же оверхедом
Если честно, то очень удивило 80K RPS на PostgreSQL, у него же по процессу на соединение порождается. На каком-то докладе граждане из Postgres Professional рассказывали что если процессов больше 1К - то начинаются ощутимые проблемы. А у вас, если не секрет, при 80К RPS cколько одновременных соединений с БД открывается?
KS
Если честно, то очень удивило 80K RPS на PostgreSQL, у него же по процессу на соединение порождается. На каком-то докладе граждане из Postgres Professional рассказывали что если процессов больше 1К - то начинаются ощутимые проблемы. А у вас, если не секрет, при 80К RPS cколько одновременных соединений с БД открывается?
15
KS
это лимит в пуле на сервисе
KS
в постгресе лимит 100
p
в постгресе лимит 100
выглядит как "все данные в памяти"
SB
Т.е. если я не ошибся в расчётах, то один запрос отрабатывает менее чем за 0.2 ms ?
MZ
выглядит как "все данные в памяти"
не обязательно :)
SB
Хотя, я пропустил про UNLOGGED, пардон.
Data written to unlogged tables is not written to the write-ahead log, which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown.
Т.е. по сути это операции с кэшем, который в случае чего (crash or unclean shutdown) есть откуда пересоздать?
Data written to unlogged tables is not written to the write-ahead log, which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown.
Т.е. по сути это операции с кэшем, который в случае чего (crash or unclean shutdown) есть откуда пересоздать?
KS
Т.е. если я не ошибся в расчётах, то один запрос отрабатывает менее чем за 0.2 ms ?
Чуть больше, там несколько воркеров, но на постгресе лимит 100, баунсеров нет.
SB
Чуть больше, там несколько воркеров, но на постгресе лимит 100, баунсеров нет.
Интересно, спасибо за рассказ !
p
не обязательно :)
nvme ssd, возможно
DN
На сайте написано: "Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем", а по сути мы имеем "Крупнейшая профессиональная конференция для манагеров высоконагруженных систем" вот как-то так.
Откуда такие выводы? Масса технических докладов, есть даже вполне хардкорные
MZ
Добрый день. Интересно, что понимается под фразой "упёрся в производительность базы данных". На небольшом железе (аля 10-20 cores) постгрес вроде неплохо со всем справляется и упираться можно только в доступное железо. Когда 40+ cores с cpu pinning-ом и прочими бубнами, можно конечно и уперется в железо, а можно и во внутреннюю кухню (аля LWLock на buf manager или lock manager-е)
N
Если это 0.2, то тут нету чтения с диска . За 0.2 миллисекунлы с диска со шпинделем прочесть в среднем невозможно. Это значит , что чтение из памяти
p
Nikolay
Если это 0.2, то тут нету чтения с диска . За 0.2 миллисекунлы с диска со шпинделем прочесть в среднем невозможно. Это значит , что чтение из памяти
а если не шпиндель?
N
Если есть транзакции , то на одной железке можно порядка пару сотен транзакций на жёстких дисках в секунду и все. Это тоже из-за того ,что каждое обращение диска это порядка 4 миллисекунды.
N
200- 600 транзакцией в секунду и верхняя граница это скорее, если база батчинг использует при записи в логфайл.