mayton2019

Мысли.

1) У тебя есть требование периода 10 секунд. Но нет требования синфазности. Тоесть можешь
получать цены со сдвигом примерно в 10/11 секунды.

00:00:00.00 - Market 01
00:00:00.90 - Market 02
00:00:01.80 - Market 03

2) Вряд-ли все биржи будут поддерживать одинаковый сетевой протокол и одинаковый план обновления.
Рассмотри вариант MQ если таковой будет. Подпишись на события.

Кириллица или прочая кодировка - это не проблема Active Directory скорее всего.
Но это может быть проблемой для того программного обеспечения которое
использует AD как LDAP сервис, получая из него свои сведенья.

Надо тестировать весь софт который в организации взаимодействует с AD.

Данная формула
f(2024) + f(2023)) / f(2022))
написана правильно (as is) но является как-бы троллингом вычислительной системы.

В числителе и знаменателе считаются факториалы чисел с разрядностью больше чем RSA ключи.
От десятки и выше каждый множитель добавляет 2 десятичных знака к проивзедению и в конце
где вы ведете учет последних множителей идут 2000*2001*2002 и так далее. Каждое умножение
добавляет 3 нуля. Миллионы-миллиарды-триллионы и так далее.

Rsa97 пишет про это в комментарии. Собственно он и ответил на вопрос как это считать. Сократив
ненужные вычисления.

Python-у очень тяжело считать такие числа. Это - как майнинг. И самое смешное что математически,
формула очень сильно упрощается если по закону сокращения дробей.

Можно попробовать механизм регулярок

SELECT ....... WHERE REGEXP_LIKE(tranz_acct , '.*(99449872|23424232).*')

но сравни производительность в обоих случаях. Обычно регулярки не могут использовать индекс.
Поэтому будет FULL_TABLE_SCAN. В случае с like выражениями у тебя есть шанс пойти
в план с INDEX_SCAN но нужно пересмотреть саму задачу. Откуда цифры.
И можно ли во всех кейсах выделить общий префикс например.