Pull to refresh

Comments 31

Еще очень бы хотелось, чтобы дожали давно зависшую тему с использованием IS NOT DISTINCT FROM при индексации. Это очень полезно, к примеру, при построении иерархии от корня, где Parent стоит NULL. Вот обсуждение: www.postgresql.org/message-id/6FC83909-5DB1-420F-9191-DBE533A3CEDE@excoventures.com

А мультимастер точно нужен, припоминаю что таи есть фунламентальные проблемы, которые не позволяют его сделать надёжным и универсальным?

может, проще вместо мультимастера сделать что-то, похожее на oracle rac (когда один инстанс базы запускается сразу на нескольких машинах и при поломке одной машины ничего плохого не происходит)?

Нужно дополнительно горизонтальное масштабирование на запись. То есть несколько инстансов умеющих запись.
С чтением и файловер худо-бедно в постгрес решается...

Мультимастер ни когда не добавляет масштабирования на запись.

Его добавляет только шардирование.

Мультимастер может быть скрещён с шардированием. Но масштабирование на запись будет добавлять при этом только шардирование.

Вопрос в том, кто за шардирование отвечает. Либо это на уровне разработки, либо на уровне БД.

Хотя бы намекните на инструменты "прозрачного" шардирования для postgresql.

Ну а на уровне приложения можно на любой бд шардировать...

Ну вообще, на данный момент есть CitusDB. Сам я его, правда, не трогал. Но судя по заверениям, даже транзакции меж шардами работают.

Рассматриваем сейчас Postgres как вариант для реализации одной системы. А не может ли кто-нибудь разъяснить, какие такие фундаментальные проблемы есть с этим у него?


Помнится, в начале 2000-х реализовывал одну систему на Sybase SQL Anywhere — так там у меня 4 узла реплицировались раз в 5-10 минут (двусторонняя репликация, индивидуальные настройки узлов) ПО МОДЕМАМ. И всё работало. Единственное, что пришлось предусмотреть в схеме БД — генерация первичных ключей с гарантией уникальности. А тут прошло почти 20 лет — и какие-то фундаментальные проблемы???

Дело не в постгресе, сама идея мультимастер репликации порочна чуток (давно читал, могу криво объяснять) — в реальности есть разрывы связи и не идеальная синхронизация времени, поэтому могу быть случаи когда acid'а не получится.
Но это конечно речь про асинхронную репликацию, хотя думаю синхронная никого и не интересует в данном случае.

Ну или за acid придётся заплатить произаодительностью, раза в два у некоторых решений.

Речь именно об асинхронной репликации. И именно в случае, когда нельзя допустить простоев узла при невозможности репликации из-за отсутствия связи.

В том решении на SQL Anywhere как раз было 4 территориально разнесённых розничных магазина одной компании. Естественно, они продолжали работать даже если вообще остановить репликацию. Использовался обмен файлами репликации, создаваемыми утилитой sql remote, за всё время работы (а работала система лет 5-7, точно не помню), был один (!) случай, когда что-то пошло не так и пришлось восстанавливать состояние репликации в узлах. Данные при этом потеряны не были.

Но, повторюсь, там изначально при создании системы схема БД создавалась с учётом данной специфики.

P.S. Да и сейчас для системы, которую собираемся делать, это одно из основных требований — её узлы должны оставаться работоспособными даже при отсутсвии связи между ними.

разумеется, если спроектировать базу так, что разные узлы не могут изменять одни и те же записи, то сделать мультмастер несложно.
только при такой архитектуре он не так уж и необходим: можно побить базу на несколько, и для каждой назначить единственного мастера.

Узлы (магазины) там могли изменять ВСЕ данные. Другое дело, что бизнес-кейс был такой, что репликации раз в 5-10 минут хватало на то, чтобы конфликтов репликации за всё время работы системы было меньше десятка.
Конечно же необходим failover из коробки (аналогично always on у MS SQL) без использования Patroni и сопутствующих.
Поддерживаю необходимость поддержать временные таблицы на реплике, in memory таблицы.
А неужели никого не напрягает отсутствие в PgSQL такой штуки как Asynchronous IO и Direct IO. Оно сто лет как есть в MySQL и Oracle, но в PgSQL увы нет и даже непонятно когда ждать.

Есть какая-то активность тут и оно же тут, но я думаю оно и в PgSQL v20 не будет реализовано.

Напрягать могут проблемы в производительности, а не отсутствие фич, не находящих отражение в SQL выражениях.

В SQL запросы отличаются от наличия AIO или Direct IO? Нет, запросы те же самые.

Т.е. правильно вопрос звучал бы "интересно, скоро ли смогут нормально прикрутить AIO/DirectIO, чтобы избавиться от двойного кэширования? Надеюсь, это даст существенную прибавку скорости".

И никого их эксплуататоров ПГ не напрягает процедура обновления мажорной версии? И связанное с этим обновлением рукоблудие? А необходимость иметь версии исполняемых файлов обоих версий — это тоже верх инженерной мысли?
В том же MySQL обновление кластера:


  1. обновил реплики;
  2. проверил состояние репликации;
  3. переключил мастера;
  4. обновил мастера.

Простой — на время переключения мастера, без какой-либо головной боли и дополнительных телодвижений. Процедура же обновления ПГ выглядит по сравнению с MySQL чем-то лютым… :(


А ещё — очень часто не хватает разделения логов по каким-нибудь критериям: ошибки подключения, общие ошибки, длинные запросы. О, длинные запросы! Вот реально именно их вынести в отдельный лог просто необходимо.

  1. Иногда чертовски не хватает аналога flashback queries, который достаточно давно есть в Oracle;
  2. 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-сессий — а никак.

Вопрос конечно насколько это критично, но вероятно да — отдельный инстанс чего-то и обращение к нему как-то, fdw какой.

А нормальная компрессия уже появилась разве?

Не хватает фильтрации данных на storage уровне.
тогда первый вопрос снимается, но второй остается
Не хватает фильтрации данных на storage уровне.

А можно пример, о чем именно идет речь?
Аналог storage индекса — предикат запроса фильтрует данные при сканировании.
Без этой фичи если запрос не попадает под патерн секционирования или в индекс, то идет фулскан
Тот же pivotal пытается сам впилить это сейчас в GreenPlum и обещает в 7ке. До этого правда обещал в 6ке )
Спасибо за ссылку. Полезная. Единственное минус который вижу что нужно создавать руками, а не создаются автоматически.
Sign up to leave a comment.