d'Ivan

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

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

Хреновый запрос, однако. Мои мысли по поводу улучшений:
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)

Если данные по индексу уникальны, то теоретически одинаковы.На практике это зависит от оптимизаций в СУБД.
UNIQUE INDEX гарантирует что данные будут уникальны, а простой индекс - нет.

Возможно перегрев или проблема с блоком питания. Или что-то с драверами или настройками BIOS/UEFI.
Посмотреть /var/log/messages, /var/log/kern.log в моменты перед перезагрузкой.
Что выводится командой last reboot ?

Попробовать изменитьнастройки перезагрузки по умолчанию на false:

HTTP Range

nginx и rate limit:
https://www.nginx.com/blog/rate-limiting-nginx/

Проще всего, возможно, воспользоваться Google Sheets API:
https://developers.google.com/sheets/api/guides/co...
То есть считывать/записывать данные ячеек таблиц через HTTP.

Для T-SQL по-моему, TOP 10.
С использованием GROUP BY и ORDER BY .

Попробуйте последовать советам из
https://askubuntu.com/a/1108826
(упоминается https://forum.manjaro.org/t/solved-terrible-sound-...
)
Подробности по параметрам:
https://medium.com/@gamunu/enable-high-quality-aud...

Рекомендации:
1. сконвертировать в UTF-8:
iconv -f cp1251 -t utf-8 < original.csv > dest.csv
2. при импорте указать разделитель ;

Нужно начать использовать инструменты мониторинга и профилирования приложения на предмет потребления памяти и производительности. Для каждого ЯП они свои. Плюс есть инструменты для профилирования Linux. Однако я бы посоветовал переходить к ним лишь после тщательного анализа приложения средствами языка.

Поиск: e-commerce cms

Может ли Redis гарантировать сохранность данных и их доступность?

Я рассматриваю Redis как быстро восстанавливающийся из snapshot кэш. С некоторой вероятностью данные будут сохранены (негарантированно). Данные сбрасываются периодически в виде дельта.
https://redis.io/topics/persistence

Можно ли, к примеру не хранить данные вроде категорий в основной БД а всегда использовать Redis для их хранения?

Можно, но не советую использовать её как основную СУБД. Хотя она хорошо масштабируется, оперативная память намного дороже SSD. В результате нужно будет платить счета за сервера с большим объемом памяти со множеством экземпляров Redis.
https://stackoverflow.com/a/42677671

для чего редис вообще может пригодиться.

Для хранения данных, к которым нужен частый доступ: кэш из короткоживущих ключей.

Первый результат в Гугле:
https://stackoverflow.com/a/28686802

оставить открытую сессию tmux
или запустить с nohup