Добрый вечер всем! Пришла задача оценить ресурсы. А у меня

опыта пока одна тестовая среда игрушечная. Может коллективный разум поможет... Собственно задача: Необходимо рассчитать требуемое количество ресурсов CPU/RAM/DISK IOPS для сервера/серверов под инстанс
(в конечном счете отказоустойчивый кластер) (RTO=5sec/RPO=0) Postgre для обработки нагрузки профиль которой ниже

Основной вопрос - хватит ли одного экземпляра postgre или шардирование неизбежно?
а если исключить нагрузку на чтение?


Информация по нагрузке:

Основная очередь:

вставка идет со скоростью до 3000 строк в секунду (до 300 коммитов в секунду)

размер записи основной очереди около 110 байт

дополнительная информация вставляется в несколько таблиц ее размер примерно 35K на операцию
вставка идет в пике 300 операций с секунду и примерно 10K строк в секунду

Чтение 10K RPS (RequestsPerSecond) со средним временем выполнения 0.1 сек, пример:

SELECT TABLE_ALIAS2.*
FROM TABLE TABLE_ALIAS1,TABLE TABLE_ALIAS2
WHERE TABLE_ALIAS1.EXMPL_ID = :EXMPL_ID AND TABLE_ALIAS1.EXMPL_F ='SM_VL'
and TABLE_ALIAS1.EXMPL_ID=TABLE_ALIAS2.EXMPL_ID
and TABLE_ALIAS1.EXMPL_NO=TABLE_ALIAS2.EXMPL_NO
and TABLE_ALIAS2.EXMPL_F ='SM_VL'
and NOT EXISTS (SELECT 1 FROM TABLE TABLE_ALIAS3 WHERE TABLE_ALIAS3.EXMPL_ID=QP.EXMPL_ID AND ... )
AND NOT EXISTS (SELECT 1 FROM TABLE TABLE_ALIAS3, TABLE2 TABLE2_ALIAS WHERE TABLE_ALIAS3.EXMPL_ID=TABLE_ALIAS2.EXMPL_ID AND ... )
AND NOT EXISTS (SELECT 1 FROM TABLE TABLE_ALIAS4 WHERE TABLE_ALIAS4.NO=TABLE_ALIAS1_NO and ...)
AND NOT EXISTS (SELECT 1 FROM TABLE TABLE_ALIAS5 WHERE TABLE_ALIAS5.XX=TABLE_ALIAS1.XX and ...)
FOR UPDATE SKIP LOCKED

Write 3K RPS (RequestsPerSecond) примеры запросов (распределение считать равномерным):

update TABLE T set x='XX',x_time=CURRENT_DATE,date=CURRENT_DATE,id='ID',code='CODE'
where id=:1 and num=:2 and no=:3 and no2=:4 and txt='TXT' and 0=(select count(0) from TABLE T1 where id=:5 and mod=:6 and no=:7 and no2=:8 and txt!='TXT2')

delete from TABLE where no=? and no2=? and no3=?

очередь разбирается до нуля периодически

также в БД хранится архив операций

Общий объем БД 110 млн операций 3.5ТБ

10к rps чтения со средним временем выполнения в 0.1 секунды это уже 1000 ядер) Вставкой на ваших объемах по сравнению с чтением можно просто пренебречь.

поясните, почему?

> (RTO=5sec/RPO=0) Нужна синхронная репликация, так? > хватит ли одного экземпляра postgre СУБД называется postgres. > или шардирование неизбежно? Шардирование при требованиях выше может быть и как-то "мимо"... > Основная очередь > дополнительная информация (Считая "на салфетке") Т.е. пусть всего 30 MB/s, так? 300 + сколько (на дополнительную информация) commit/s получается? Используемая сеть (network) должна быть способна выдать как минимум столько round-trips в секунду. > Чтение 10K RPS (RequestsPerSecond) со средним временем выполнения 0.1 сек, Эээ... что?! Во-первых, откуда тут уже взялось время выполнения? Во-вторых, секунда так не получается. ;) > Write 3K RPS (RequestsPerSecond) Опять-таки — объём чтения/записи в байтах, сколько commits/s? > также в БД хранится архив операций > Общий объем БД 110 млн операций 3.5ТБ А "горячих" данных сколько примерно? В любом случае — "железо" обязано всё указанное выдавать, PostgreSQL тут дело второе.

Мне кажется, тут где-то ошибка в исходных данных — откуда это вообще можно знать, если конкретного "железа" уже нет?

На вопрос почему 1000 уже человек выше ответил. Почему пренебречь - ну тут у меня уверенности стопроцентной нет, возможно не прав, но даже с большим количеством индексов на таблице вставка 3к строк объемом 110 байт в секунду вряд ли займет более 1-2 секунд процессорного времени. Отсюда на вставку 2 ядра, что против 1000 ядер на чтение - пренебрежимо мало. Но повторюсь, со вставкой возможно погорячился, нет сейчас под рукой тестовой тачки проверить

Кстати возможно есть какая-нибудь тачка с постгресом для proof-of-concept, на которой и объемы другие были. Но какое-то представление о времени ответа получить можно было.

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

RTO=5sec — это сразу забудьте про постгрес. Про MS SQL Server, кстати, тожэ забудьте. Берите IBM DB2 for Z/os. Отличное решэние, не первый десяток лет обеспечивает подобную надёжность. Там ещё и отличная websphete mq в качестве очереди, отличный DTM и вообще много опыта написания подобного уровня систем. За деньги, да. Цэнник решэния подобного уровня, понятно, начинается от $1M. PS Ах, да, возможно, что-то такое есть ещё у оракла. На рекомендованном партнёрами оборудовании. Но не то, чтобы там цэнник выходил дешэвле.

Хмм... неужели за 5 секунд не удастся переключиться на синхронную реплику и переустановить [какие-то] соединения?

Exadata норм

Шансы, что проблемы постгреса на исправном оборудовании исправятся от переключения на реплику — не 100%. Дажэ не очень велики, если хотя бы за местом на дисках следить.

Да это ясно... ну так при выдающейся "удаче" может провалиться любая стратегия DR. :( Просто как пример "удачи" (вспомнилось) — мне как-то рассказывали про "вылет" трёх дисков из RAID6 с интервалом в пару минут... а сисадмины как-то не на это рассчитывали почему-то. ;(

И да, скорее всего — если настроить какую-то автоматику, чтобы она таки переключала менее, чем за 5 секунд — то оно чаще будет переключать из-за false positoves, с шансами процэнтов 10 встать раком при таком переключении — просто потому, что все автопереключалки у нас тупые.

Да, это тоже вполне реальный риск, к сожалению. :(

С одной стороны да.... С другой стороны, если куча инжэнеров 50 лет тэстирует именно с этой цэлью... То нужно что-то выдающееся, чтобы завалить систему. (Например, отредактировать чужой патч и выкатить его в прод без тэстов...)

какой Raid?

Raid shadow legends, мобильная ммо рпг