Комментарии 31
А мультимастер точно нужен, припоминаю что таи есть фунламентальные проблемы, которые не позволяют его сделать надёжным и универсальным?
Нужно дополнительно горизонтальное масштабирование на запись. То есть несколько инстансов умеющих запись.
С чтением и файловер худо-бедно в постгрес решается...
Мультимастер ни когда не добавляет масштабирования на запись.
Его добавляет только шардирование.
Мультимастер может быть скрещён с шардированием. Но масштабирование на запись будет добавлять при этом только шардирование.
Вопрос в том, кто за шардирование отвечает. Либо это на уровне разработки, либо на уровне БД.
Хотя бы намекните на инструменты "прозрачного" шардирования для postgresql.
Ну а на уровне приложения можно на любой бд шардировать...
Рассматриваем сейчас Postgres как вариант для реализации одной системы. А не может ли кто-нибудь разъяснить, какие такие фундаментальные проблемы есть с этим у него?
Помнится, в начале 2000-х реализовывал одну систему на Sybase SQL Anywhere — так там у меня 4 узла реплицировались раз в 5-10 минут (двусторонняя репликация, индивидуальные настройки узлов) ПО МОДЕМАМ. И всё работало. Единственное, что пришлось предусмотреть в схеме БД — генерация первичных ключей с гарантией уникальности. А тут прошло почти 20 лет — и какие-то фундаментальные проблемы???
Дело не в постгресе, сама идея мультимастер репликации порочна чуток (давно читал, могу криво объяснять) — в реальности есть разрывы связи и не идеальная синхронизация времени, поэтому могу быть случаи когда acid'а не получится.
Но это конечно речь про асинхронную репликацию, хотя думаю синхронная никого и не интересует в данном случае.
Ну или за acid придётся заплатить произаодительностью, раза в два у некоторых решений.
В том решении на SQL Anywhere как раз было 4 территориально разнесённых розничных магазина одной компании. Естественно, они продолжали работать даже если вообще остановить репликацию. Использовался обмен файлами репликации, создаваемыми утилитой sql remote, за всё время работы (а работала система лет 5-7, точно не помню), был один (!) случай, когда что-то пошло не так и пришлось восстанавливать состояние репликации в узлах. Данные при этом потеряны не были.
Но, повторюсь, там изначально при создании системы схема БД создавалась с учётом данной специфики.
P.S. Да и сейчас для системы, которую собираемся делать, это одно из основных требований — её узлы должны оставаться работоспособными даже при отсутсвии связи между ними.
разумеется, если спроектировать базу так, что разные узлы не могут изменять одни и те же записи, то сделать мультмастер несложно.
только при такой архитектуре он не так уж и необходим: можно побить базу на несколько, и для каждой назначить единственного мастера.
Поддерживаю необходимость поддержать временные таблицы на реплике, in memory таблицы.
Напрягать могут проблемы в производительности, а не отсутствие фич, не находящих отражение в SQL выражениях.
В SQL запросы отличаются от наличия AIO или Direct IO? Нет, запросы те же самые.
Т.е. правильно вопрос звучал бы "интересно, скоро ли смогут нормально прикрутить AIO/DirectIO, чтобы избавиться от двойного кэширования? Надеюсь, это даст существенную прибавку скорости".
И никого их эксплуататоров ПГ не напрягает процедура обновления мажорной версии? И связанное с этим обновлением рукоблудие? А необходимость иметь версии исполняемых файлов обоих версий — это тоже верх инженерной мысли?
В том же MySQL обновление кластера:
- обновил реплики;
- проверил состояние репликации;
- переключил мастера;
- обновил мастера.
Простой — на время переключения мастера, без какой-либо головной боли и дополнительных телодвижений. Процедура же обновления ПГ выглядит по сравнению с MySQL чем-то лютым… :(
А ещё — очень часто не хватает разделения логов по каким-нибудь критериям: ошибки подключения, общие ошибки, длинные запросы. О, длинные запросы! Вот реально именно их вынести в отдельный лог просто необходимо.
- Иногда чертовски не хватает аналога flashback queries, который достаточно давно есть в Oracle;
- Edition-based redefinition тоже бы очень хотелось видеть.
flashback не сложно написать, только ведь он не дальше последнего вакуума. С такими ограничениями он полезен?
он не дальше последнего вакуума— есть ещё UNDO_RETENTION параметр, который часто поможет для базы с «хорошей» настройкой (как минимум, правильно подобранный размер undo сегмента, метриками нагрузки, периодически проверяемыми AWR). Выручал так пару раз таблицы инвенторики, без предварительных настроек, в течение суток после ЧП (повезло, не было memory pressure).
Чуть позже ещё появился Flashback Data Archive, который можно гранулярно настроить для нужных таблицы. FDA уже даёт более жёсткие гарантии (и большую гибкость в настройке с поддержкой периода жизни архива, размера архива и т.п.). Тут уже на удачу не прокатит, конечно, нужна подготовка заранее.
Конечно, ограничений тоже хватает (DDL, затыки с lob раньше были), но получать такое из коробки очень полезно.
Если весь этот фарш можно быстро настроить и в postgres, буду благодарен на референсы)
Не понял про in-memory, вроде субд и есть инмемори пока всё в мемори вмещается, были сравнения где постгрес быстрее редиса был.
www.databasesoup.com/2015/02/running-with-scissors-mode.html
То это не совсем то, что хочется, поскольку распространяется сразу на всю базу (точнее, на весь инстанс PG). А представьте, что вам надо иметь во всей базе всего лишь одну табличку in-memory — например, токены активных web-сессий — а никак.
Не хватает фильтрации данных на storage уровне.
А нормальная компрессия уже появилась разве?
Есть заходы на эту тему с разных сторон:
afiskon.github.io/static/2017/postgresql-in-core-compression-pgconf2017.pdf
www.postgresql.eu/events/pgconfeu2019/sessions/session/2671/slides/263/Data_Compression_in_PostgreSQL_and_its_future_noscript.pdf
postgrespro.ru/docs/enterprise/9.6/cfs-usage
Вот принятый в v14 патч для TOAST:
commitfest.postgresql.org/32/2813
www.depesz.com/2021/03/22/waiting-for-postgresql-14-allow-configurable-lz4-toast-compression
Не хватает фильтрации данных на storage уровне.
А можно пример, о чем именно идет речь?
Без этой фичи если запрос не попадает под патерн секционирования или в индекс, то идет фулскан
Тот же pivotal пытается сам впилить это сейчас в GreenPlum и обещает в 7ке. До этого правда обещал в 6ке )
habr.com/ru/company/postgrespro/blog/346460
Чего «энтерпрайзу» в PostgreSQL не хватает