теория
Теперь соберём картину целиком — и заодно поймём, почему «просто докинуть железа» не лечит.
Первое — про запись. В сезон нагрузка «Ярмарки» стала write-heavy: заказы льются потоком. B-дерево платит за каждую запись журналом, правкой страницы и обновлением всех индексов — это его врождённая цена. Движок под запись (LSM) тот же поток проглотил бы легче: копит в памяти и сбрасывает последовательно. Дело не в том, что «PostgreSQL плохой» — просто на этой конкретной таблице мы попросили чтеца много писать.
Второе — про память. Пока горячие данные (свежие заказы, открытые индексы) помещаются в — часть RAM, где база держит горячие страницы, — всё летает: и чтение, и запись идут по памяти. Но за сезон таблица распухла, и рабочий набор перестал влезать. А это обрыв, а не плавный спуск: каждое обращение, которое раньше попадало в RAM, теперь едет на диск случайным доступом — в самый медленный режим. Вот почему деградация не линейная, а резкая — система свалилась с полки.
Третье — честно про LSM, чтобы ты не убежал переписывать всё на него сегодня же. За дешёвую запись LSM расплачивается чтением: нужного ключа может не быть в свежем файле, и приходится заглядывать в несколько (); спасает , который мгновенно отвечает «здесь точно нет». Плюс та самая фоновая компакция ест диск и CPU. LSM не «быстрее» — он просто иначе раскладывает боль.
Вывод — тот же, что во втором модуле про OLTP и OLAP, только этажом ниже: быстрой базы «в вакууме» не бывает. Бывает движок и набор индексов, которые совпали — или не совпали — с твоим паттерном доступа. «Докинуть CPU» не спасает, потому что упёрлись мы не в счёт, а в диск и в лишнюю работу, которую сами же на запись и навесили.