d'Ivan

Вряд ли есть какое-то чудо-решение в масштабируемости системы. Из довольно банальных советов: правильно спроектировать БД под большие нагрузки, добавив необходимые индексы. Но все равно наступит момент, когда нагрузка будет слишком большой и тогда будут исчерпаны доступные соединения к СУБД, появятся какие блокировки, таймауты, крэши и прочая радость. Что даже dev ops не спасут от "сервер временно недоступен".
В облаках можно в некоторой степени автоматически масштабировать вычислительные ресурсы, но так можно внезапно разориться из-за атаки какого-то бота.

С JSON можно нормально работать в MySQL, только надо выбирать подходящие для поиска структуры данных, а не как в 1-м столбце (ассоциативный массив).
Каждый такой объект в 1-м столбце

{
        "age_to": "8",
        "gender": "children",
        "age_from": "4",
        "quantity": "400",
        "additionally": "no"
    }

надо хранить в отдельной записи для возможности поиска по ним.
В целом, искать нужно при помощи JSON Path Syntax (читать документацию), например так:

SELECT * FROM table WHERE column ->> '$.a.b' = 'bla-bla'

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

SEARCH: Боль в костях

Это уже полнотекстовый поиск.
Короче, нельзя просто класть любой JSON в СУБД и полагаться на её возможности. Нужно изначально проектировать БД для записи и чтения с разными видами запросов.

https://www.php.net/manual/ru/numberformatter.form...

Есть изотерический язык Piet. Можно взять его за основу.

NLTK поддерживает Snowball стеммеры, включая русский.

Нормально Си в качестве бэкенд использовать.
В качестве примера: Vishap's Oberon Compiler (voc). Вообще, Оберон (не Оберон-2) удобно рассматривать в качестве языка, который прост и у него есть приличное количество реализаций как с байткодом, так и на целевые платформы.
Можно еще WebAssembly генерировать, при помощи Cranelift IR.
Хотя иметь LLVM в зависимости не так уж и плохо.

Рекомендательные системы, как правило, необязательно выдают данные в реальном времени. Поэтому я предлагаю другой вариант работы с данными:
некоторый фоновый процесс будет получать какие-то метрики из API сервиса и будет временно хранить данные в Mysql в количестве, достаточном для пакетной отправки в ClickHouse. Другой процесс будет периодически производить запросы в ClickHouse, а результаты рекомендаций хранить в Mysql. Таким образом, все запросы из API сервиса можно обрабатывать обращаясь только к Mysql.

Из страницы HTML с CSS:
wkhtmltopdf/wkhtmltoimage

C, D, Rust, Modula-2, Oberon, Ada и другие. Можно также использовать C как целевой язык.
На C, исторически сложилось, больше кода и примеров, но это не означает, что на других нельзя писать ядро ОС и драйвера.
А системные утилиты и прочее в пользовательском пространстве проще писать уже на более высокоуровневых языках чем C.

Надо логи ошибок смотреть: /var/log/mysql/error.log для подробностей.
Может, есть поломанная таблица.
Исправлять далеко не всегда возможно. Тогда останется только восстанавливать из резервных копий.

Онлайн аудиоредактор

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

Хреновый запрос, однако. Мои мысли по поводу улучшений:
COUNT DISTINCT => COUNT(*), GROUP BY
EXISTS => LEFT JOIN
IN (SELECT ...) => INNER JOIN

Не гарантирую, что прав 100%.
А, вообще, такие запросы следует дробить. Такие сложные запросы - это признак плохого проектирования. Лучше воспользоваться дополнительными таблицами для хранения состояний.
Шаблон материализованного представления

.NET Standard описывает набор API-интерфейсов для различных версий.

Веб-сервисы:
https://www.diagrams.net/
https://drakonhub.com/drakon
Настольные программы:
yEd

Визуальный язык ДРАКОН - из самых прогрессивных, известных мне. Заложена интересная концепция для переосмысления построения диаграм. Есть различные реализации.

Solr умеет выводить подсветку найденных результатов в тексте. https://lucene.apache.org/solr/guide/6_6/highlight...
Sphinx Search/Manticore тоже, см. SNIPPET()

mysql>  CALL SNIPPETS('this is my hello world document text I am snippeting now', 'myindex', 'hello world', 5 as limit_words);
+------------------------------------------------+
| snippet                                        |
+------------------------------------------------+
|  ...  my <b>hello world</b> document text ...  |
+------------------------------------------------+
1 row in set (0.00 sec)