Хочется оценить возможности использования PostgreSQL в одном из проектов, и хочется прояснить несколько вопросов о возможностях PostgreSQL.

Можно ли как-то настроить кластер PostgreSQL с разделяемым хранилищем? Аналогично как в SQL Server c MS Cluster?
То что я прочитал, не требует разделяемого хранилища, но при этом нагружает базу данных, что выглядит плохо.

Еще вопрос. Как PostgreSQL работает с большими базами и большими объемами памяти? Например, база данных размером 500 Гб, активная часть данных 200 Гб, 256 Гб ОЗУ, 32 ядра процессора. Как PostgreSQL будет работать при этих параметрах при 300+ открытых соединениях, при этом в каждый момент времени 20-30 соединений будут параллельно выполнять какие-то запросы?

Вопрос про надежность. Реально ли получить 24x6 надежность? При том что в течение этих 6 дней даже глубокой ночью имеется минимум несколько сотен активных пользователей, которые будут недовольны даже если база будет недоступна несколько секунд.

И вопрос про оптимизацию. И в MS SQL, и в Оракл имеется много возможностей по оптимизации запросов, при помощи различных хинтов. Как с этим обстоит дело в PostgreSQL?

MelkijandsmМожно ли как-то настроить кластер PostgreSQL с разделяемым хранилищем?
Зачем?

Потому что, согласно тому что читал, решения на основе синхронной репликации замедляют сервер где-то от 30% до 2-3 раз. Очевидно, что при высокой нагрузке на сервер его хочется разгрузить.

MelkijandsmЕще вопрос. Как PostgreSQL работает с большими базами и большими объемами памяти? Например, база данных размером 500 Гб, активная часть данных 200 Гб, 256 Гб ОЗУ, 32 ядра процессора. Как PostgreSQL будет работать при этих параметрах при 300+ открытых соединениях, при этом в каждый момент времени 20-30 соединений будут параллельно выполнять какие-то запросы?
Нормально, но не на дефолтном конфиге, разумеется.
Хотя конечно "какие-то запросы" - штука сильно растяжимая.

Запросы достаточно сложные, джойны 10-15 табличек, некоторые таблички содержат до 1 млрд записей. В среднем возвращают 100-200 записей и должны работать в пределах 50-100 мс. Некоторые запросы могут вытягивать по 150-200 Мб данных и должны работать не более 10-15 сек.

MelkijandsmВопрос про надежность. Реально ли получить 24x6 надежность? При том что в течение этих 6 дней даже глубокой ночью имеется минимум несколько сотен активных пользователей, которые будут недовольны даже если база будет недоступна несколько секунд.
На нормальном железе - да.

Есть ли примеры подобных решений на PostgreSQL для mission-critical систем?
И как при этом обходится вакууминг или как это называется?

MelkijandsmИ вопрос про оптимизацию. И в MS SQL, и в Оракл имеется много возможностей по оптимизации запросов, при помощи различных хинтов. Как с этим обстоит дело в PostgreSQL?
Хинты - это не про оптимизацию. Это про костыли.
Хинтов нет, костыли для граничных случаев есть.

Да нет, в некоторых случаях это необходимая часть решения. Когда разных типов запросов сотни, и под каждый не создашь свою структуру, а оптимизатор не справляется.
Нашел возможности PostgreSQL на эту тему: https://blog.2ndquadrant.com/hinting_at_postgresql/
Выглядит не очень, возможности есть, но маловато.

MelkijПо всем вышеперечисленным вопросам ответ ничем не отличается от других баз - нужен DBA.
Террабайтные базы 24/7 и под mysql можно крутить, если уметь. А если не уметь - то и оракл не поможет.
24/7 под mysql? Видимо у нас разные понятия о том что такое 24/7. Честный 24/7 под mysql ни разу не встречал.

Melkijandsmпропущено...

Потому что, согласно тому что читал, решения на основе синхронной репликации замедляют сервер где-то от 30% до 2-3 раз. Очевидно, что при высокой нагрузке на сервер его хочется разгрузить.
А сетевой диск бесплатно?

Какой сетевой диск если я говорю про разделяемое хранилище, SAN? Соединяется напрямую с серверами, по FC 10+ гбит и соответствующей скоростью, ставим туда SSD диски. Понятно что это дороже и чем сетевой диск и чем отдельные диски. Стоит это примерно от 20k$. Однако если хочется и надежность и производительность и есть готовность заплатить, то хочется наличия такой возможности.

MelkijСинхронная репликация - это ожидание подтверждения получения wal репликой. То есть только при записи. Аналогично сетевому диску запись отправить по сети и дождаться ответа. Но сетевой диск будет медленнее и на чтении тоже.

Чувствуется что не работали с хорошими хранилищами. Для сетевого диска пишете правильно, для разделяемого хранилища - полностью неверно.

MelkijandsmЕсть ли примеры подобных решений на PostgreSQL для mission-critical систем?
И как при этом обходится вакууминг или как это называется?
headhunter? Lamoda? Яндекс много где, в общем-то. Mission critical? Да.

Что там в Яндексе не знаю, а headhunter и Lamoda не впечатляют от слова совсем.
Занимался как-то базой данных для одного из сайтов, куда более посещаемого чем headhunter. И, в процессе, понял что не такие уж на деле высокие требования по доступности для веб-сайтов. Если система подзависнет на несколько секунд, никто и не заметит.
Есть ли примеры финансовых систем на PostgreSQL?

MelkijАвтовакуум настраивается агрессивно и отстреливаются аномально долгие транзакции, чтобы не мешали.

Как-то не очень звучит. Что такое аномально долгая транзакция в секундах? А если она нужна?

alexkirandsm,

авторМожно ли как-то настроить кластер PostgreSQL с разделяемым хранилищем? Аналогично как в SQL Server c MS Cluster?

Если нужна доступность можно без репликации сделать HA Cluster с общим хранилищем ( pacemaker, corosync )
Спасибо!
Хоть на какой-то вопрос нашел ответ.

И что там в PostgreSQL с параллелизмом?
Как он использует ядра процессора? Кеш операционки или собственный? Разделяемый кеш или нет?

Maxim BogukandsmИ что там в PostgreSQL с параллелизмом?
Как он использует ядра процессора? Кеш операционки или собственный? Разделяемый кеш или нет?

Если вы задаете такие вопросы вам надо начинать или с чтения книжек или с наема профильного специалиста в компанию (если вы действительно финансовую систему с 24x7 собираетесь на postgresql строить).

Никто не собирается финансовую систему с 24x7 реально делать на PostgreSQL. Задача, под которую на самом деле рассматривается postgresql, намного проще и не требует такого уровня надежности. Ну а приведенные параметры - это параметры реально работающей системы (на MS SQL), с которыми проще проводить сравнение чтобы понять возможности PostgreSQL.

Maxim BogukПотому что иначе тут придется вам рассказывать очень много всего.

Про параллельное выполнение запроса
1)до 9.6 - никак вообще
9.6 - для некоторых запросов
в 10.0 - для несколько большего набора запросов
в 11 будет еще для большего набора запросов...

Это, насколько понимаю, ответ на вопрос про параллелизм запросов.

Maxim BogukРазделяемый кеш или нет?
Расшифруйте вопрос.

Кеш данных один для всего PostgreSQL или разные запросы могут читать одни и те же данные в свои кешы?

MelkijОн от этого не перестаёт быть сетевым. SAN - storage area network . А ценники в 20к$ не впечатляют. К производительности, а вернее латентности, при этом большие вопросы. Как все авторы SAN считаете, что 5мс - это хорошее io service time?

Смотря как сконфигурировать. У нас почти все SAN-ы подсоединены напрямую к серверам, тем самым сетевыми не являются. 20k$ - конечно не много, это же только начало цены таких хранилищ.
5 мс для Io (чтение или запись) это много, особенно если SSD диски и есть аппаратный кеш на запись.

Melkijandsmпропущено...

Как-то не очень звучит. Что такое аномально долгая транзакция в секундах? А если она нужна?
См. любимый оракл, что случится когда транзакция висит слишком долго? Snapshot Too Old
Аномально долгая транзакция - это транзакция невозможной длительности для проекта. 10 минут, час, 6 часов - сколько нужно. Транзакция длиной в сутки на OLTP базе - зачем бы?
Причина почему в Оракл возникает Snapshot Too Old понятно, это можно регулировать.
А как с этим в PostgreSQL?

HawkmoonПредложил бы озаботиться премногоуважаемому ТС с его активностью в MSSQL-части форума для начала миграции озаботиться переходом "блокировочник->версионник".

Если, конечно, речь идет о миграции. Чтобы потом не было бы мучительно больно за бесцельно прожранный бюджет.
Хех. Проспали более 10 лет? MSSQL может себя вести и как версионник, и как блокировочник. Есть особенности, связанные с особенностями наложения блокировок на индексы при работе, но они все известны и понятны.