Добрый день! подскажите где можно почитать про требования к ресурсам? конкретно для

каких объемов базы сколько нужно оперативки.
для разных типов использования базы.

> подскажите где можно почитать про требования к ресурсам? Мне кажется, или такие рекомендации сводятся к "чем больше, тем лучше — пока всё, что нужно, не влезет"? ;) > конкретно для каких объемов базы сколько нужно оперативки. С учётом того, что при тех же объёмах, данных и типах использования размер "то, что нужно" может отличаться на два-три порядка (в зависимости от того, как спроектирована база и насколько хорошо написаны запросы), ответить на этот вопрос невозможно, IMHO.

у пгтюн написано More information about "DB Type" setting: Web Application (web) Typically CPU-bound DB much smaller than RAM 90% or more simple queries Online Transaction Processing (oltp) Typically CPU- or I/O-bound DB slightly larger than RAM to 1TB 20-40% small data write queries Some long transactions and complex read queries Data Warehouse (dw) Typically I/O- or RAM-bound Large bulk loads of data Large complex reporting queries Also called "Decision Support" or "Business Intelligence" Desktop application Not a dedicated database A general workstation, perhaps for a developer вот откуда это ?

Это приблизительные описания типов БД. Если у Вас есть конкретная БД, то это помогает мало (см. про два-три порядка).

есть таблица которая ротируется в течении 3х месяцев: - всего примерно 1Г записей и порядка 1Т на диске - наполняются из 6 внешних ПГ со скоростью 1к записей в секунду - несколько запросов пользователей в секунду по первичному ключу - все старше 90 суток удаляется остальными таблицами пока можно пренебречь

> всего примерно 1Г записей и порядка 1Т на диске Это с учётом индексов? Да и вообще — может, проще будет показать \d, \dt+ и \di+ того, что относится к делу? > наполняются из 6 внешних ПГ со скоростью 1к записей в секунду Наполняются в каком порядке (произвольном? по первичному ключу? по времени?)? > несколько запросов пользователей в секунду по первичному ключу Опять-таки, к произвольным ключам? > все старше 90 суток удаляется А каким именно образом (ежедневно? или ещё чаще? или реже? просто DELETE или это партиционированная таблица (и DROP))?

все еще на стадии и разработки. сейчас таблицы очищены CREATE TABLE public.core_rawcheck ( created_at timestamp NOT NULL, updated_at timestamp NOT NULL, ui numeric(30) NOT NULL, c_number int4 NOT NULL, issued_at timestamp NULL, doc_number int4 NULL, payment_amount numeric(100, 2) NULL, id int8 NULL, CONSTRAINT core_rawcheck_pkey PRIMARY KEY (ui) ); >Наполняются в каком порядке (произвольном? по первичному ключу? по времени?)? логическая репликация >Опять-таки, к произвольным ключам? поиск по произвольным ключам. ключ очень уникальный 16ти байтовый инт собственно задача системы - выдать пользователю найден ключ или нет. >А каким именно образом (ежедневно? или ещё чаще? или реже? пока, ежедневно, несколько раз, порциями. я не знаю как ее партиционировать если у меня ключ разбиения не участвует в поиске ((

CREATE TABLE public.core_rawcheck ( created_at timestamp NOT NULL, Сразу см. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29 > логическая репликация Это вообще не отвечает на вопрос. ;) Суть моих вопросов в том, чтобы выяснить размер "то, что нужно", если что. И легче, когда записи поступают (и запрашиваются) хоть в каком-то порядке (по возрастанию времени или первичного ключа, например). От этого сильно зависит размер "то, что нужно" (того, чему лучше было бы быть в RAM). > поиск по произвольным ключам. ключ очень уникальный 16ти байтовый инт Хмм... но в таблице почему-то ui numeric(30)? > я не знаю как ее партиционировать если у меня ключ разбиения не участвует в поиске (( Эээ... ну и что? Партиционируют не для поиска, а чтобы улучшить maintenance, в норме. Т.е. можно было бы и по первичному ключу, если это поможет vacuum / analyze. И можно было бы рассмотреть возможность делать это по дате/времени, которое используется для принятия решения об удалении — можно было бы делать DROP / DETACH вместо DELETE. Но тут может быть проблема с ключом, безусловно (насколько важен именно такой?).

полностью еще не заполняли. размер высчитали на пальцах исходя из таблиц доноров. и скорость их заполнения. они в сумме наполняются 600-1000 записей в секунду данные летят рандомно. если я разобью посуточно - это решит проблему удаления да но поиск тогда будет в 90 раздельных партициях но вообще я тут подумал что тогда я могу запустить 90 паралельных поисков ))) насколько ПГ будет этому рад непонятно

> данные летят рандомно. Если вообще никаких закономерностей нет, то оптимальный размер RAM — это терабайт или даже больше. ;( Т.е. так у вас вся БД получается "горячей", нет? > но поиск тогда будет в 90 раздельных партициях Будет, а как же. Но если при этом производительность этих запросов будет приемлемой — so what? ;)

вот этого я и боялся услышать ))) размер базы = размер рам мне заказчик выделил всего 16Г с круглыми глазами типо "нахрена те столько памяти" » Если вообще никаких закономерностей нет только одна = дата вставки. собственно да можно сделать горячую суточную партицию и это точно сильно решит вопрос с удалением »Но если при этом производительность этих запросов будет приемлемой — so what? ;) вот тут интересно что быстрее запрос в 1 таблице по единому индексу или 10 паралельный запросов в 10 партициях кстати про партиции. есть уже в ПГ14 автосоздание партиций?

> только одна = дата вставки. собственно да можно сделать горячую суточную партицию Тогда это, всё-таки, другое дело. Зависит от того, как читается, конечно (если чтение любого дня равновероятно, т.е. первичный ключ не коррелирует с датой/временем, и запрашиваются произвольные — то да, вся таблица "горячая", как её ни раскладывай по partitions). > вот тут интересно что быстрее То, что сделает PostgreSQL, если Вы его адекватно настроите и выполните этот запрос. ;) Т.е. "заморачиваться" ручным разбиением и т.п. тут вообще не стоит, мне кажется. > кстати про партиции. есть уже в ПГ14 автосоздание партиций? Нет.

поиск свежего скорее более вероятен. -3 дня сильно более вероятен чем -50 дней думаю суточные партиции очень имеют место да а распределить поиск это уже кодом

> поиск свежего скорее более вероятен. Совсем другое дело, да. > а распределить поиск это уже кодом Я выше имел в виду, что лучше, чем сам PostgreSQL, Вы это всё равно почти наверняка не сделаете (а вот времени впустую можете потратить много, и к тому же несложно и "накосить" в реализации (так, что получатся некорректные результаты поиска)).