vk
lol, быстро пробежал первую страничку опроса, удивился изнеженности молодых коллег "и это на канале называли долгим опросом", и тут выяснилось, что страница не одна, теперь ясно, что и не две.
Size: a a a
2019 November 10
AE
Согласен, что Постгресу не хватает ряда компонентов из-коробки. Но конкретно про пул для веб-воркеров стоит учитывать и распределённость самого Постгреса. Т.е. если у вас 1000 серверов лезут в одну базу (ой ли?), то и у базы должны быть реплики для чтения, возможно каскадные. Что умножает число возможных коннектов раз в 50.
N
Комитов на одном сервере нельзя сделать много т.к пишет один процесс на диск
N
И что значит iops в памяти ?
VO
ровно то же самое что и iops на диске.
в чем собственно сомнение и/или недоумениие?
в продакшен память с нулевой латенси пока не завозили и даже не обещают
в чем собственно сомнение и/или недоумениие?
в продакшен память с нулевой латенси пока не завозили и даже не обещают
PD
vladimir kunschikov
на хайлоаде 2017 был доклад от тех же постгрес-профешнл, как постгрес проигрывал монге на веб нагрузке - на запросах с распределением ципфа. как всегда был интересный доклад, как всегда на уровне, и тогда и было выражено вполне трезвое понимание важности адекватных реальным нагрузкам бенчмарков.
Хм, не помню. Там вроде бы на каком-то одном профиле нагрузки только и при весьма хитрых допущених (типа в PG транзакции оставили, а в Mongjo - как всегда).
PD
Nikolay
Комитов на одном сервере нельзя сделать много т.к пишет один процесс на диск
Ну, это не связанные вещи. Пишет WAL, насколько я помню, один процесс, но при этом транзакции проводятся (и формируется очередь для WAL) в разных процессах.
PD
Но, кстати, про проблемы в реализации современных СУБД, рассчитанных на архитектуру производительных SSD я бы доклад с удовольствием послушал.
Желательно про разные кейсы.
Пока все-таки архитектура СУБД в основном опирается на шпиндельные диски (исторически).
Желательно про разные кейсы.
Пока все-таки архитектура СУБД в основном опирается на шпиндельные диски (исторически).
VO
не вижу никаких причин делать на ssd принципиально иначе чем на шпиндильных дисках. собственно говоря ssd диск вполен можно считать как raid0 из нескольких шпиндельных дисков (для обычных консьюмерских -- из восьми, с seek 0.1 ms вместо 14, но примерно таким же трансфером (140МБ/с))
у постгреса соответсвующие соотношения тупо в конфиге прописываются, для оптимизатора запросов.
у постгреса соответсвующие соотношения тупо в конфиге прописываются, для оптимизатора запросов.
AE
не вижу никаких причин делать на ssd принципиально иначе чем на шпиндильных дисках. собственно говоря ssd диск вполен можно считать как raid0 из нескольких шпиндельных дисков (для обычных консьюмерских -- из восьми, с seek 0.1 ms вместо 14, но примерно таким же трансфером (140МБ/с))
у постгреса соответсвующие соотношения тупо в конфиге прописываются, для оптимизатора запросов.
у постгреса соответсвующие соотношения тупо в конфиге прописываются, для оптимизатора запросов.
Принципиально иначе и не делают. Но всё больше тюнят в новых местах, которые раньше влияли несущественно, а теперь тормоза диска это всё не маскируют.
Но конкретно в СУБД, имхо, это в основном ручки в конфигах. Основные архитектурные изменения делаются в самой ОС.
Но конкретно в СУБД, имхо, это в основном ручки в конфигах. Основные архитектурные изменения делаются в самой ОС.
VO
Принципиально иначе и не делают. Но всё больше тюнят в новых местах, которые раньше влияли несущественно, а теперь тормоза диска это всё не маскируют.
Но конкретно в СУБД, имхо, это в основном ручки в конфигах. Основные архитектурные изменения делаются в самой ОС.
Но конкретно в СУБД, имхо, это в основном ручки в конфигах. Основные архитектурные изменения делаются в самой ОС.
ну если в этом плане то оно вообще ничем не отличается от выщищения всякого говна при поднятии бвстродейсвия.
PD
Да вот не совсем так. Архитектура СУБД (write-ahead-log, один процесс записи в лог, попытки активное кэширование для уменьшения количество случайных чтений) - это наследство шпиндельных дисков.
Сейчас можно думать о принципиально других решениях, но это очень не просто.
Сейчас можно думать о принципиально других решениях, но это очень не просто.
PD
Ну зачем вообще WAL на SSD?
PD
При том, что на современные SSD, насколько я помню, еще и писать можно в кучу (больше, чем ядер) потоков одновременно.
AE
Ну зачем вообще WAL на SSD?
1. Поддержка целостности.
2. Репликация (у Постгреса, хз ещё у кого так).
3. Бэкапить с wal тоже удобно иногда. (Постгрес штатно только так и умеет.)
2. Репликация (у Постгреса, хз ещё у кого так).
3. Бэкапить с wal тоже удобно иногда. (Постгрес штатно только так и умеет.)
PD
Ну, понятно же, что все три задачи можно сделать не протягивая все в одно ушко WAL?
PD
Т.е. понятно, что современные СУБД все на этой идеологии - и для шпиндельных дисков это было круто. Но для SSD уже можно данные менять и сразу в нескольких местах, одновременно. Нет необходимости экономить на seek.
AE
Ну, понятно же, что все три задачи можно сделать не протягивая все в одно ушко WAL?
Для целостности (ACID) принципиально иметь именно один последовательный поток данных. Иначе рассинхронизация и каррапт.
AE
Чтобы это преодолеть, надо на уровне диска поддерживать сериализацию. А они afaik даже блоки нужного размера (под страницу бд) не поддерживают.
AE
Плюс есть всё ещё профит от записи кучи мелких изменений в разных местах в виде одного блока данных на диске. ССД тут как раз имеет слабость и каждое мелкое изменение (скажем, 100 байт) пишет в виде замены всего блока (16Кб или типа того).