Существует ли в природе СУБД или иное средство, способное максимально быстро выполнить подобную операцию Postgresql 12.6. Как ускорить скрипт с update? Обновление 18 млн записей по юрлицам РФ ?

Время от начала изменения данных до его окончания с возможностью восстановления быстрого поиска должно быть минимально.

На слуху такие вещи как Kassandra, графовая БД, Elastic Search, тарантул. Что может помочь?

Огласите бюджет и характеристики помещения серверной.

(1) ты хотел сказать Дата центра ?

типичный подход новой школы

новая школа - дайте мне супер инструмент тогда сделаю эту хрень

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


к сожалению старой школы все меньше и меньше....

(0) Так там же вроде проблема была в том, что какой то дятел засунул данные, по которым нужно чего то вычислять, в JSON.
Кассандра-массандра выбирается в зависимости от задачи. Какая задача - неизвестно. Может нужны текстовые файлы и компилятор, а может просто запрос в Postgresql надо правильно написать.

(0) Для скорейшего изменения есть колоночные СУБД, например, wiki:ClickHouse
Там нет транзакций и UPDATE только пакетный. Зато всё быстро

(5) Спасибо! Беру на заметку.
(1) Предположим, если 1Тб SSD и 200Гб ОЗУ раздобыть что это даст?

(6) [1Тб SSD] если у тебя до сих пор HDD, то SSD решит проблему "узких" мест

GT.M или аналог https://platforms.su/platform/5261
Если не страшно окунаться в MUMPS.. :)
А так - grep, sed, awk, еще что-нибудь. Для структурированног о текста 18-20 млн. строк вполне должно хватить, комп только поприличней.

(8) [grep, sed, awk] хотите сказать, сунуть файлы ЕГРЮЛа на диск, а потом просто работать с ними обычными файловыми операциями без всяких СУБД?

(0) Автор, что не так с отдельными колонками поиска? Которые один раз надо заполнить из json и потом искать уже по ним?

(9) Почему нет? Попробовать же можно. Причем, каждый файл можно обрабатывать в отдельном процессе, по числу высокоэффективных ядер, если файлы большие.

(10) Они давал ссылку в (0) что "По одному ОГРН возможно несколько записей.".
Что мешает ему это выкинуть в отдельную таблицу SQL из JSON мне не ведомо.
Да и работает он на достаточно древнем PostrgreSQL 12.6, в более новых версиях, работа с индексами JSON значительно расширена, насколько могу это заметить.

(3) нет, старая школа это "у нас нет инструментов для решения задачи, значит будем делать инструменты, а задача потом"

JSON, равно как и XML, несовместимы с производительностью. Для производительности структуру БД надо приводить к нормальной форме согласно теории реляционных баз данных. Не должно быть никаких подлежащих парсингу блобов в полях.

Хм... Ну хорошо, найдете вы средство для расшива узких мест. Но вам ведь придется сначала влить 18 лямов записей в это средство, потом вернуть измененное назад в Postgres. Вы думаете, это будет лучше, чем в имеющемся Postgres перейти от JSON к колоночному представлению, например?

(14) Это точно - поля по которым идет поиск надо выносить из блобов. Я надеялся, что индекс сохранит значения этих полей и постгрес будет искать инфу в индексе, однако поделав простые селекты я понял, что это так не работает - все равно СУБД лезет в эту блобину.

А как насчет того, чтобы поставить задачу в компанию Постгрес Профессионал. Кстати - у Вас какая версия - стандарт или enterprise?

(16) Надо данные хранить нормализованно без блобов, а для выдачи в пользовательское АПИ c json формировать view. Тогда будет быстро и правильно.

(18) не всегда надо прям вообще все данные хранить нормализовано, иначе будет очень большие накладные расходы на их извлечение

если они не учавтсвуют в поиске, то иногда правильнее хранить их в блобе

(0) На слуху такие вещи как Kassandra, графовая БД, Elastic Search, тарантул ...тогда еще Redis добавь