Ivan Brezhnev

Если нужен ТОЛЬКО ответ на вопрос есть или нет тенденция (тренд), то можно обойтись и без регрессии. Существуют специальные тесты. Их много.
Критерии серий (https://math.semestr.ru/trend/median.php )
Критерий Аббе-Линника (http://www.machinelearning.ru/wiki/index.php?title... )
Критерий Фостера-Стюарта (http://www.machinelearning.ru/wiki/index.php?title... )
Критерий Валлиса-Мура (https://thelib.info/matematika/66568-proverka-dina... )
Выбирайте.

Самое простое - nginx отдаёт статику. На больших объёмах делать это через Ноду неэффективно.
Посложнее - nginx позволяет управлять ходом запроса. Например, редиректить на https.
Ещё сложнее - можно настроить nginx, чтобы он умно балансировал запросы между несколькими бэкендами и автоматом блокировал слишком частые попытки подключения.

Nginx очень хорошо в промышленных масштабах делает определённую часть работы, связанной с http-запросом, поэтому ему эту часть работы и делегируют.

function shortNumber(val) {
  const abs = Math.abs(val);
  const prefixIndex = Math.log10(abs) / 3 | 0;
  return (
    (val < 0 ? '-' : '') +
    Math.round(abs / (10 ** (prefixIndex * 3))) +
    [ '', 'K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y' ][prefixIndex]
  );
}

Нижняя граница: (текущая дата - (Х+1) лет + 1 день)
Верхняя граница: (текущая дата - Х лет)

my_round(123,-2) = 100.

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

как сервер за столь короткое время умеет прошерстить базу данных, найти сообщения конкретного пользователя и отдать их

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

Что касается быстрой загрузки истории сообщений - то тут нужно сохранять сообщения таким образом, чтобы сообщения одного пользователя всегда были на одном и том же сервере (если используется шардинг). Тогда обычный SELECT из базы по user_id будет вполне себе быстро работать даже на огромной базе. Также таблицы можно еще партицировать, чтобы еще быстрее загружать последние сообщения в истории.

Что касается безопасности, если не использовать e2e шифрование, как вариант, можно использовать обычные RSA ключи. Например на сервере генерируем два ключа, открытый отправляем кленту, он шифрует им сообщение и передает сообщение на сервер. Вы на сервере его расшифровываете при помощи закрытого ключа. Для отправки сообщения клиенту, можно сделать тоже самое. Клиент также генерирует два RSA ключа и открытый ключ отправляет серверу. Когда серверу нужно доставить сообщение клиенту, он шифрует сообщение открытым ключём, который ему высылал клиент и отправляет ему.

Мне тоже интересно узнать другие варианты решения этой задачи, буду следить за этой темой :)

Хорошее дополнение по хранению сообщения и организации поиска от Ильи
Распределение нагрузки решается шардингом — получается много небольших БД вместо одной огромной. Скорее всего каждое сообщение разбивается по словам/частям слов и сохраняется в поисковый индекс типа слово—message_id и такой индекс строится для каждого пользователя и тоже шардируется. При поиске сначала получаем идентификаторы подходящих сообщений из поискового индекса, потом выгружаем сообщения из БД с сообщениями.

Дополнение от Stalker_RED
только не "сообщения одного пользователя всегда были на одном и том же сервере" а сообщения из одного чата/канала/группы (включая чаты, в котором всего два участника). То-же самое касается построения индекса.

f(x) = O(g(x)) при x→y — это так называемый символ Ландау.
И означает, что при x, достаточно близких к y, f(x)<k·g(x). Так что 2x или 1000x — извините, не важно.

Отсюда же запись O(log n) — ведь разные логарифмы отличаются на константу, которую символы Ландау съедают.

Чем символы Ландау интересны программистам?
1. Кэшами, быстрым процессором, «хитрым» программированием и прочим на больших наборах данных можно выиграть, например, в разы. Порядком сложности алгоритма — намного, намного больше.
2. Пока закон Мура действовал, объёмы данных росли экспоненциально — так что быстро доходило до того, что программу начинали использовать на наборах данных, для которых она просто не предназначалась.
3. Практически приемлемые алгоритмы обычно имеют небольшую сложность — например, до O(n³). И, например, линейный алгоритм за приемлемое время обработает миллионы элементов, n log n — сотни тысяч, n² — тысячи, n³ — сотни.
4. Программисты отлаживают на небольших наборах данных, которые можно обработать вручную. Так что разница между отладочными и боевыми данными бывает большая — а значит, порядок сложности должен влиять сильнее, чем остальные факторы.

Сложность обозначает, с какой скоростью растёт объём вычислений при увеличении объёма входных данных. В принципе, может получиться что-то наподобие O(2n+5n²+3nlog(n))
Но, так как нас интересует верхняя граница, то мы берём только максимальный член этой суммы, то есть O(5n²). А поскольку хотим получить только относительную скорость роста, то выбрасываем постоянный коэффициент, получая O(n²).
В вашем случае двух последовательных циклов O(2n) сокращается до O(n), что означает, что с ростом объёма входных данных объём вычислений растёт линейно.

В смысле, как читать? Слева направо, соблюдая порядок операций.

Вот первая формула r= ... - это значит, что значение переменной r вычисляется по выражению справа. Там участвуют переменные p, g, значения которых вам даны.

Там дробь, в числителе стоит сумма p и g. В знаменателе один плюс значение логарифма в квадрате от суммы корня pg+p и g^2. Расставьте скобки и получите (p+g)/(1+log(...)*log(...))

Аналогично вторая формула для y через p,g,r и z ( три из них вам даны, r вычисляется в предыдущем действии).

Возведение в квадрат - зависит от языка программирования. Или функция sqr(), или **2, или просто написать (выражение)*(выражение). lg() - вызов встроенной функции логарифма. Опять же, зависит от языка, как именно она называется у вас. Квадратный корень - функция sqrt().

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

Как бы это странно не звучало, но одно из главных преимуществ TypeScript - это ускорение разработки в несколько раз. Да, когда еще ничего нет - разработка незначительно замедлится, так как помимо логики нужно описать еще и типы. Но это только в начале. И это не только возможность писать большую часть кода с помощью автодополнения. Поддержка существующего кода занимает в десятки раз больше времени, чем его начальное написание. Стоит ли вложить несколько лишних часов на старте, чтоб сэкономить в последствии месяцы? Как по мне стоит.

Еще одним огромным плюсом является возможность проектировать на типах. Познав дзен TypeScript'а я перестал пользоваться UML, так как типы дают мне ту же наглядность, но при этом еще и сокращают время, так как типы - это уже код. Ну и источник правды остается один. Бизнес требования выраженные в типах не дают отклонится от них при написании логики, исключая возможность неправильной трактовки задачи. Перенеся задачу в типы, я могу обсудить ее с коллегами и исправить неточности еще до написания кода, что опять же сильно экономит время.

Ну и отвчечу на некоторые Ваши сомнения:

TSLint в VSCode прям жутко тугой

TSLint официально deprecated, вместо него стоит использовать плагин к eslint, заодно можете мой конфиг попробовать.

Типы? Есть JSDOC

JSDoc в плане типов не умеет и 10% того, что умеет TypeScript. Кроме того, никто в здравом уме не пишет JSDoc на приватную логику, а значит проверки типов там не будет. JSDoc не гарантирует корректность рефакторинга, а вот благодаря TypeScript я, опять таки, точно не забуду обновить JSDoc.

многие библиотеки nodejs не имеют типов

может лет 5 назад так и было, но сейчас встретить библиотеку без типов - скорее исключение. Если библиотека популярная, но не предоставляет типов, скорее всего их уже написал кто-то другой, достаточно просто установить одноименный модуль из npm скоупа types и все будет работать само.

Поддержка браузерами скомпилированного кода? Да какбы почти весь JS имеет поддержку 95%+, тот же Babel уже забыл когда использовал.

Вообще это не основная задача компилятора TypeScript, а опциональная возможность. И babel + preset-env с ней справляются гораздо лучше. И никто не мешает использовать их вместе. А еще думаю вопрос времени, когда кто-то напишет оптимизатор кода использующий информацию о типах из TS.

Примерно в каждой второй есть инстансы, на которые смотришь - и чешешь репу - а как называется тип этой переменной в @types/?

import {someObject} from 'some-library';

type TypeFromValue = typeof someObject;
const valueCopy: TypeFromValue = {
    ...someObject,
    type: 'overrides',
    with: 'type check',
};

и кстати, вот пример того что JSDoc типы не умеют.

//@ts-check

и почти везде останется бесполезный any.

P.S. удачи такие типы на JSDoc описывать
P.P.S. Еще прелести современного TypeScript невозможные у...

пофигу на чем, хоть всё на нативе.
тормоза - в реализации, а не технологии.

Предположение. CircularReference, в случае если много зависимостей, может вызывать подобные проблемы. Устраните циклические ссылки для товара на сервере.

Ребят, ну вы конечно интересные))

Если вы просто измените инструмент, с огромной вероятностью ничего не изменится

Что именно стремится к 0? Ответ сервера? Рендеринг компонентов? SSR ? Локализуйте проблему, проанализируйте, как можно её решать, если вдруг это действительно проблема фреймворка - посмотрите, нет ли аналогичной проблемы у других фреймворков.
У вас же под рукой целый devTools - Network, Perfomance, Memory, ... Полузуйтесь этим, ищите проблему)

Если хотите, можете скинуть ссылку, мне не лень попробовать понять, что именно у вас не так

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

На изображении квадратики размера 2x2, между ними один пиксель пустой. И по границам еще пустые пиксели. Если обрезать 1 пиксель справа и снизу, то получится, что каждой ячейке соответствует квадрат 3x3: или целиком белый, или с 4-мя черными пикселями в правом нижнем углу.

Соответственно, достаточно проверять пиксель с координатами 3*i+1, 3*j+1 для получения значения ячейки [i][j] (все индексы с 0).

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

Если изображение с артефактами сжатия, то можно брать среднее между 4-мя пикселями 3*i+x, 3*j+y (x,y=1..2) по всем трем компонентам (RGB) и смотреть, что оно сильно отличается от черного. Для этого делаете еще 2 вложенных цикла по x и y, там прибавляете значение цветов пикселя в переменную, потом делите на 12 и сравниваете, допустим, с 200. Если меньше - это черный квадрат, если больше - то белый.