Все очень зависит от особенностей задачи, объема данных, требований к непрерывности и т.п.
Основные идеи по ускорению, после исправления ошибок в приложении (и исследовании вариантов заплатить за лучшее железо) само собой:
* пакетная обработка (в пределах одной транзакции или объединение тысяч операций в одной)
* партицирование, часто бывает так что все данные на время обработки не нужны, т.е. идеологически или даже средствами базы данных, можно отделить архивную базу (большую но практически не используемую) и оперативную... меньше база, быстрее обработка
Дальнейшие варианты нарушают непрерывность работы сервиса (не всегда это возможно), пусть и кратковременно
* временное отключение индексов, когда новых данных очень много и нагрузка из-за их количество значимей чем нагрузка на процессор и оперативную память, очень часто это дает наилучший прирост в скорости (однократно создать индекс на большой объем данных на порядок быстрее чем обновление индекса на каждую новую запись)
* перенос работы на более быструю машину, благодаря почасовым/поминутным облачным тарифам и продвинутым функционалом, можно автоматически поднимать заранее подготовленную машину, даже в том же датацентре (это ускорит передачу данных и скорее не добавит стоимость за трафик) переносить обработку на нее, а по окончанию возвращать назад.
Технически это можно реализовать как через скрипты резервного копирования так и репликацию файловой системы (та же btrfs предлагает быстрые и 'бесплатные' по ресурсам инкрементальные бакапы на основе снапшотов) или кластерные файловые системы. Осторожно, базы данных, особенно сложные, могут хуже работать (в разы) на cow файловых системах типа btrfs, но это вопрос исследований под данные и задачу.
* частный случай с предыдущим - перенести базу данных в оперативную память. sqlite работает в ней невероятно быстро (пример реализации, машина останавливается, у провайдера создается новая с тем же диском но большей оперативной памяти, выполняется нужная работа, временная машина удаляется, диск остается).
Как вариант - у меня был эксперимент, на ram диске соседней машины создавался образ файловой системы, этот файл публиковался с помощью nbd (это как iscsi только проще и быстрее), монтировался уже на целевой машине и туда переносилась база данных, это было во времена hdd и давало очень значимый прирост (вместо часов работы - минуты), теперь с ssd такой разницы можно не получить или для этого потребуется быстрее сети, не гигабитные), сразу скажу что сетевые файловые системы типа nfs/samba не рекомендуются, так как привносят кучу накладных расходов из-за возможности немонопольного доступа и просто из-за особенностей реализации (например fflush на nfs сильно замедляет работу по сравнению с локальной, так как работает по разному)
Еще один момент, когда база значительно превышает доступную ram, временная база может быть размещена в файловой системе с отключенным принудительным fflush (т.е. по просит дождаться синхронизации данных а ОС рапортует в тот же момент что все записалось, хотя это не так), реализуется это по разному, начиная с опций файловой системы ext data=writeback, отключения журнала и кончая интересных вариантов у виртуальных машин, такой конфиг может работать сравнимо с оперативной памятью, так как все оперативные данные будут закешированы, но само собой очень уязвим ко сбоям, любая аппаратная проблема или глюк ОС убьют данные максимально неприятным способом, но так как такая машина временная, это не проблема, ведь данные в нее копируются на время обработки.
---
все это к тому, что задачу можно решать таким образом, чтобы исключить или перенести узкое место по ресурсам в другое место, вплодь до кластерных решений (буквально поднимается целый кластер, он запускает обработку, работает считанные минуты и уничтожается)
Средний
Простой
