mayton2019

Есть такая старая поговорка из тайм-менеджмента - "что СРОЧНО - то не важно".

Если есть некий источник который продуцирует записи со скоростью 10к в секунду и мы хотим писать их сразу (мгновенно) то наверное у нас есть такой-же потребитель который так-же быстро способен их потребить.

А есть вообще такой? Мне сложно себе представить. Если это биг-дата со стримингом - то там надо использовать не постгрес а другие системы. Kafka+Spark например. Но я не буду давать таких советов потому что люди обычно сидят на консервативных системах типа реляционок и хотят делать на них все. Просто им так удобнее.

Давайте немного арифметики. Если мы формируем 10к в секунду то за сутки у нас набегает 10000L * 60 * 60 * 24 = 864 000 000 или восемьсот миллионов строк. Это вот если загрузка будет постоянно такая.

Здравствуйте, мне в наследство досталась база где в основной таблице индексом является текстовое поле.

Это не является ошибкой. Возможно в дизайн закладывался текстовый ключ. Ну по крайней мере у тебя нет острой необходимости всё ломать сразу.

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

Странно всё это

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

верни лучше взад.

Что еще менялось кроме железа. Версия PG?

Вашему архитектору - передавайте большой привет. Возможно его фраза звучала в контексте. И без этого контекста мы слышим мысль воспроизведенную вами так как вы поняли. Возможно арх. вообще сетовал на то что вы их нигде не создаете. Другое зло вобщемто.

Ты скорее всего не понял смысл плана. План - это намерения что-то сделать. Но не обязательно он будет сканировать всю таблицу. Если найдет в 1 партишене - то остановится быстрее. Но план это не может показать т.к. у планировщика нет такой информации.

Не нужна тебе никакая промежуточная таблица. Соедини все 3 штуки в одну таблицу по Id и будет все прекрасно.

А если ты вручную запустишь вакуум - это влияет на LiveTuples / DeadTuples ?

Есть мысль что ты сам себя заблокировал. Работаешь в UI ?

Есть еще мысль что надо посчитать count сколько ты собираешся обновить. Может там - вся таблица обновляется.

Можно использовать inline views (или еще называют common table expressions)

with cp_view as (
 select cp.chat_id
 from chat_participants cp
 where cp.user_id = 1 and cp.is_deleted = false)
.....

Мне кажется что надо еще учесть квалификацию того кто будет это обслуживать. Если чел к примеру знает Kubernetes - то можно расчитывать на какой-то более динамичный план размещения сервисов по нодам.

Тоесть не так жестко привязывать сервисы к железкам. Да и идея импортозамещения - тоже важна. Как выше пишут.

Зачем делать reindexdb для всего подряд? Это-ж делается в аварийно-ремонтных работах когда точно известно что сегмент индекса поврежден.

Тут надо сначала смысл разобрать. Вот как ты себе понимаешь что магазин открылся в 22.00 а закрылся в 5.00 ?
Закрылся в 5.00 утра следующего дня? Работал всего 7 часов. Это один кейс. А другой кейс - если свапнуть время - то получается что работал 15 часов. Выводы? Свапать нельзя никак.

А вот когда смысл проверки мы поймем - тогда можно и код писать. В крайнем случае - хранимую функцию написать.

Судя по тексту ошибки - это нарушение констрейнта первичного ключа "assignment_pk".

Когда ты вставляешь что-то в таблицу с primary key то должен всегда проверять что ID уникален.

В данном случае этот запрос неверен. Выдает неуникальный сет IDs.

SELECT $1, task_id, item_id, NULL, completed, result, 'QUEUE', NULL
FROM assignments
WHERE assignments.id = $2

Топик тегирован "Базами Данных". Какими - чорт его знает.

Поэтому есть следующие коробочные решения. Cassandra, Redis, Amazon DynamoDb. Все они поддерживают дополнительное поле TTL и удаляют записи автоматически без участия разработчика.

По поводу подводных камней о которых пишет автор. Это всё очень плохо и почти не работает в боевых условиях. Пока бэкап данных делается в обычном плановом режиме - никто не знает о существовании всяких там левых файлов на сервере приложений. Грубо говоря все думают что состояние системы (state) лежит в базе и только в базе. Поэтому попытка размазать состояние системы по нескольким нодам вычислительной сети приводит к сложным и трудноуловимым последствиям.

Надо сортировать по расстоянию Левенштейна (levenshtein) от выражения "test" до поля email.

Из того что автор описал - у меня возникает архитектурный вопрос. Кто придумал - использовать JSON для данных которые часто обновляются? Это - антипаттерн. Вы какое железо не поставте - у вас будет плохой перформанс.

Вам необходимо все данные которые имеют реляционный (точечный) доступ убрать из JSON. По сути - развалить его на модель EAV или что-то вроде того (Relational Data (RD)). Обновления станут быстрее. А для отчотности - если вам так уж важен JSON - отдельные джобы которые будут переливать данные из RD в JSON или формировать его на лету средствами клиента. В этом случае у вас не будет накладных расходов даже на хранение.

Теги можно хранить в поле типа JSONB

Совершенно нет никакой мотивации к использованию uuid.

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

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