d'Ivan

Попробуйте по инструкции
https://www.rosehosting.com/blog/how-to-fix-broken...

Q. Как строить СУБД и искать по ней?
A. Поиск: СУБД рецепты ингредиенты

Q. Как искать по "включить ингредиенты" и "исключить ингредиенты"?
A.

SELECT наименование FROM ингредиенты
WHERE наименование IN ('морковь', 'картофель') AND наименование NOT IN ('сахар', 'мука')

Q. Как построить пользовательский интерфейс?
A. Поиск: tutorial angular react Flutter

Каждому микро-сервису необходима разная информация по фильму.

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

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

Надо бы прояснить отчего несогласованность и прочие проблемы. Иначе как можно помочь, не зная проблемы?

Паттерн Event Sourcing говорит о том, что все изменения состояния приложения должны быть представлены как последовательность событий.
Я не знаю какой брокер сообщений используете вы, но для возможности реконструировать всю последовательность изменений заново в каждом микросервисе, нужно изначально хранить их в каком-то центральном журнале событий. Apache Kafka весьма подходит для этих целей.
Если не Kafka, то нужно обеспечить возможность отправлять одно и то же событие по нескольким каналам, чтобы каждый из микросервисов смог получить всю необходимую информацию.
Изменения в СУБД должны происходить атомарно, чтобы избежать несогласованности данных.

Шаблон источников событий
https://martinfowler.com/eaaDev/EventSourcing.html
https://microservices.io/patterns/data/event-sourc...

Не работаю с node.js, но в документации dotenv приведен пример:

node -r dotenv/config your_script.js

В этом скрипте можно обрабатывать аргументы для запуска различных сценариев и пользоваться process.env.DB_PASS и прочими секретами.
Помимо прочего, файлы .env не предназначены для production. Вместо них нужно использовать переменные окружения, которые в Windows устанавливаются по-своему.

Если вручную проверять онлайн, то https://fotoforensics.com/

Судя по iotop, работает MariaDB. Причём, в совокупности, запросы интенсивно работают на запись, а не на чтение. Возможно, для создания временных таблиц.
Если это shared hosting, то тут особо и нечего делать. Разве что предложить арендаторам хостинга улучшенную версию их ПО.
Я сомневаюсь что дело лишь в одном запросе, приведенном в вопросе.
В первую очередь, я бы провёл анализ медленных запросов (slow query log).

Если задача практическая, то Multi-Part Zip поможет разбить файлы на множество томов.
Можно даже само-распаковывающийся архив создать.

Ну а если академическая, тогда гуглить Bin packing problem.

https://www.linkedin.com/pulse/embedded-engineers-...
https://targetjobs.co.uk/careers-advice/job-descri...

В вашем случае может проще поехать к клиенту с диском 5+ ТБ.
https://habr.com/ru/company/kingservers/blog/316660/

Добавлено
Если данные дедублицировать (ZPAQ и пр.), то неисключено, что они могут занимать существенно меньшее место и тогда эти дедублицированные данные можно отдать через FTPS/HTTP-сервер.

Движок dokuwiki такое не позволяет, насколько мне известно.

Попробовать создать дамп mysqldump с опциями --opt --quick затем| gzip > dump.sql.gz
Можно установить утилиту pv и тогда будет видна скорость получения данных и объём переданных данных.

mysqldump ... | pv | gzip > file
желательно перенаправить на отдельный накопитель.

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

https://devcenter.heroku.com/articles/error-codes#...

No code has been pushed to this application. To get rid of this message you need to do one deploy. This is not an error, but we give it a code for the sake of completeness.

Можно писать монолит и на Go, только надо будет гуглить множество различных решений, поскольку из коробки мало чего готового.
Проще взять развитый веб-фреймворк (RoR и др.), в котором всё что необходимо уже есть. Так быстрее разработка пойдёт.

Хранить Библию можно построчно (стих=строка).
Допустим,
Бытие 1:3

И сказал Бог: да будет свет. И стал свет.

На иврите

וַיֹּאמֶר אֱלֹהִים, יְהִי אוֹר; וַיְהִי-אוֹר

Можно представить в виде Книга Глава:Стих
Глава:Стих (chapter:verse) могут быть представлены (закодированы) как буквенными, так и численными значениями, в зависимости от языка.
Если не нужно проходить по порядку глав-стихов, то достаточно хранить в СУБД 3 колонки: bible_version, book, verse_reference.
bible_version - Синодальный перевод
book - Бытие
verse_reference - 1:3

https://en.wikipedia.org/wiki/Chapters_and_verses_...