Данных поступает много и все они апдейтят сущности с одинаковым ID, реже появляются новые ID. Апдейтить по кругу надо чем быстрее тем лучше

А что насчёт того, чтобы upsert в коде реализовать? Ну те для данных ввести понятие «версии». И каждый апдейт порождает новую версию данных. Старые версии в фоне чистим

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

Как вариант, но надо понимать что речь идёт где-то о миллионе строк каждые 10 минут

Да не проблема, шардим таблицу с данными до вида tableName_#version#, а в отдельной таблице храним мап вида pk - version

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

А при желании, ещё и компакшен/мерж навернуть

Хм, и правда, про секции я не подумал. А плодить и удалять таблицы с такой скоростью норм? Постгрес справляется с этим эффективно?

И хранить n последних версий тоже хороший бонус дает на случай какого бага или ещё чего

Вот тут не могу сказать со 100% уверенностью, но прототип бахнуть за день можно и посмотреть как оно

Ага, спасибо большое

Да незачто, напиши потом, завелось или нет) а то на первый взгляд модель ок, но подводные камни бывают разные)

Эт да)

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

Добрый день, можете подсказать с 2мя вопросами
1. Стоит вопрос в покупке нового сервера, который должен решить одну из проблем - поднять скорость работы нескольких сайтов на php (основной сайт примерно 35-40 rps в рабочее время). Стоит ли делать упор на частоту CPU? Или взять 2.6 ГГц, но за счет более новой платформы время ответа может сократится.
2. Попробовал перенести сессии на redis (в php.ini прописал адрес сервера), сайт стал работать по шустрей, но мониторинг ругается на фрагментацию памяти. Она меняется плавно от 1.8 до 2.5-3.1

да, это логично, но обновиться может все кроме ID, к сожалению, включая поля по которым есть индексы

Первый вопрос - классическая ошибка.
Невозможно ответить на него, не зная специфики работы сайта.
Вы бы сначала отпрофилировали, поняли где бутылочное горло, а потом уже решали что делать
Возможно, и сервер покупать не придется, а сделать пару индексов в БД/настроить нормально иннодб.
Какой сейчас load average? Сколько ядер? Сколько ядер на планируемом сервере? Кто сейчас ест процессор в основном?

Мне кажется частота не очень релевантна. Для серверных решений упор на количество ядер (многопоточность). Это раз. Опять таки если у вас просто "сайт" - то там нет математики сложной. Самая нагруженная часть это запрос к бд. Не сильно требовательный к процу (если есть индексы). Т.е. если у вас 2.6 ггц но 10-20 ядер, это будет лучше чем более быстрый, но меньшее количество ядер.

Сейчас 8 ядер (больше не дает сделать лицензия vmware), 34 ГБ ОП. Сама железка 10 CPUs x Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz ( на ней еще 3 не сильно нагруженные виртуалкаи) с включенным гипертрейдингом.
В данный момент нагрузка 0,89 1,25 1,43
Проц едят mysql и php-fpm

Сайт в основном это каталог продукции (с ним работают в основном наши контрагенты), но на него нагручено много функционала, от которого ни кто не откажется. Личный кабинет это отдельная тема. Сейчас основные притензии к каталогу, он долго грузится - 500-700 для обычного пользователя и по более для авторизованого, взависимости от включенного у него функционала. Самая боль для меня, что из-за этого функционала я немогу сделать нормально кеширование. Все должно быть практически онлайн.

Индексы в бд есть, вобще к бд притензий у меня нет. Потому что был у нас поиск на php который в некоторых моментах думал больше 1 минуты. В итоге психанул и за выходные тупо перенес все на golang в микросервис (в го я ноль, делал методом научного втыка). Теперь время ответа 50-200 мс. Структра бд и запросы не менялись.

Походу все пользователи решили свалить с сайта, когда я сюда написал))) сейчас нагрузка ни о чем