цпу applier'a реплики. Лаг по всем замерам в продах и тп держится довольно хороший, журнал пишется построчно, это правда, но едет на реплику не совсем построчно. но свои 30-50к тпс оно выдает
Дело не в этом. Механизм репликации вообще может не заморачиваться записями журналов, отдельная нить может грязные страницы пихать в сетевые железки и дожидаться ответов в рамках raft-а.
так она ж и так отдельная
Нить или файбер?
relay-треды же поднимаются, которые просто журнал в сеть шлют и апрувы читают
Транзакция заканчивается после того, как получено достаточное количество апрувов?
В любом случае, журнал из отдельных специально сформированных записей, а не страниц, в условиях быстрой аппаратно ускоренной сети кажется рудиментом.
это же важно только при его отправке репликам за апрувами, все равно при сколько-нибудь серьезной нагрузке в wal летят пачки транзакций, которые пишутся за один write. ну и со стороны релея они вычитываются тоже в буфер шустрее, и летят в сторону реплики тоже пачкой
И тут сейчас набегут любители виртуализадции, куберов и software defined network и будет кровавое рубилово!
Я немножко не про то. Я про то, что между Application Server и диском есть слой, занимающийся преобразованием между представлением манипуляции данных и представлением хранения. Если бы его не было, пришлось бы работать на уровне страниц памяти.
для HFT разве что это важно
Если БД устроена как файл, отображённый на странички памяти, а грязные страницы заводятся сначала в журнале и, только, потом, после аков с диска и реплик, записываются в основной файл, то репликация волей-неволей будет вынуждена работать со страницами, иначе слишком сложно получается.
Нагрузка и wal несовместимы, диск это всегда оч медленно
Нет. Последовательная запись работает быстро. Зависит от файловой системы, но в теории можно писать и на сырую партицию, лишь бы шпиндель не был занят другими задачами.
О нет))) медленно даже на nvme
медленно - это сколько и по сравнению с чем?
С памятью конечно и потом с чекпоинтами
Обсуждают сегодня