rPman

1. Нужно искать отклонения не на графике, а на ряде чисел, из которых этот график строится.
2. Найти выбросы или отклонения от нормы можно найти при помощи классических статистических алгоритмов.
Главное сформулировать более чётко, что ты хочешь найти, ибо

отлонения показаний, которые выходят за пределы допустимых.

Можно решить при помощи простого условия "если замер n выходит за пределы диапазона допустимых значений, то сделать [что-то]", даже без привлечения статистики.

Если тебе нужно что-то более сложное, что нельзя решить при помощи классических алгоритмов - гугли anomaly detection

Не должно у вас изменение сущности в одном приложении влиять на сущность в другом.

Весь мир с ума сходит по микросервисам, убивается на распилке монолитов.
А у вас они уже есть, но вы хотите слепить из них обратно монолит.
У вас сейчас низкая связанность, а вы хотите ее повысить на пустом месте.

Какая проблема, чтобы Client сходил в Order, получил идентификатор созданного заказа и дернул Billing?
Зачем во всех этих трех сервисах делать тройное дублирование сущностей?

инженер-программист

Вот вам еще вариант - добавить к статьям обязательные поля (если вы пишите о событии):
Точная дата начала события
Место события (населенный пункт)
Список ФИО участников
Тип события (выбор из фиксированного списка)

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

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

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

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

Open Swoole – мощный супер-быстрый асинхронный PHP.
WebSocket'ы, корутины, высокая нагрузка.

Пример WebSocket сервера:

<?php

use OpenSwoole\WebSocket\Server;
use OpenSwoole\Http\Request;
use OpenSwoole\WebSocket\Frame;

$server = new Server("0.0.0.0", 9502);

$server->on("Start", function(Server $server)
{
    echo "OpenSwoole WebSocket Server is started at http://127.0.0.1:9502\n";
});

$server->on('Open', function(Server $server, OpenSwoole\Http\Request $request)
{
    echo "connection open: {$request->fd}\n";

    $server->tick(1000, function() use ($server, $request)
    {
        $server->push($request->fd, json_encode(["hello", time()]));
    });
});

$server->on('Message', function(Server $server, Frame $frame)
{
    echo "received message: {$frame->data}\n";
    $server->push($frame->fd, json_encode(["hello", time()]));
});

$server->on('Close', function(Server $server, int $fd)
{
    echo "connection close: {$fd}\n";
});

$server->on('Disconnect', function(Server $server, int $fd)
{
    echo "connection disconnect: {$fd}\n";
});

$server->start();

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

А раз не может быть на локальном компьютере, но все вендоры предлагают распознавание текста через облако, и только платно: Яндекс Облако и уже упомянутый гугл.
(И только платно, тк чужое железо бесплатным быть не может)

В принципе, кроме облака есть ещё бесплатный Vosk - его качество заметно хуже, чем у яндекса и гугла, но в во много раз лучше, чем в винде, и ты можешь в своём "голосовом ассистенте" предлагать пользователю выбор между несколькими движками (пусть сам оплачивает Yandex speech)

Кстати, у яндекса не такие уж и дорогие тарифы - 16 копеек за 15 секунд распознаваемой речи.
https://cloud.yandex.ru/docs/speechkit/pricing#rul...
За время демо-периода можно бесплатно много часов распознавать.

Фактически когда мы говорим Linux - мы подразумеваем не саму ОС а ядро. Ядро физически лежит в каталоге

/boot

и это единая точка в системе где можно говорить именно о весии ядра. На все остальное - версия ядра не распространяется. Версии утилит и пакетов и приложений - могут быть любые. И может быть миллионы
их сочетаний вместе с ядром. Это кстати иногда отвечает на вопрос почему у некоторых пользователей
баг воспроизводится а у некоторых - нет.

FreeCAD . скрипты на Python.

У open.Ai есть свой API. Найдите, прочтите документацию, реализуйте функцию в боте, которая будет работать с этим API. Можно, кстати, у того же чатбота попросить помощи.

На скриншоте LoadAverage около 8 при 48 ядрах и полно свободной памяти, то есть сервер не нагружен, если при этом приложение работает медленно, можно предположить, что оно ожидает чего-то. Может оно обращается к внешнему API которое медленно отвечает?

Рекомендую проверить настройки DNS и убедится, что используется локальный кеширующий DNS сервер, а не публичный - дело может быть в том, что публичные DNS серверы тротлят если к ним часто обращаются, так что если приложению надо обращаться к внешнему API оно будут часто резолвить имена, что приведёт к задержкам.