К корреляции применяются прям такие жёсткие временные характеристики по срабатыванию?

Это псевдо-риал тайм компонет. У тебя есть входной поток 10К ты обязан успеть обрабатывать 10 000 событий в сек. Корр. не может сказать: Эййй, погодите, я тут думаю, источники ждать не будут. В итоге где-то будет копиться очередель из событий, которая забьет либо память, либо диск.

Про многопоточность. Попробую на аналогии. Знаком с понятием session stickiness из Web?

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

Нет

Если коротко, то нет, объем памяти не решает проблему, он лишь отодвигает неминуемый конец. Ибо NUMA с ее ограничениями.

Если у тебя 200 прожорливых правил. Можно запустить два коррелятора, каждый из которых работает со своей 100 правил. При этом через каждый коррелятор нужно пропускать полный поток, включая выхлоп соседнего коррелятора, на случай вторичных корреляций. Поток параллелить нельзя, т.к. в случае с цепочкой A -> B есть шанс отправить A и B в разные параллели. Но в такой схеме на каждый коррелятор все же будет меньше нагрузки т.к меньше правил и инстансов накапливаемых корреляций. Все так или что упускаю? Стало любопытно)

Арксайт же сбацал себе распределенную корреляцию. Как раз потому что вертикальное масштабирование упирается в предел и ничего тут не поделаешь. Только я отстал от жизни и на практике её не видел.

Пусть есть цепочка: A (что-то там делаем, вычисляем подсетку, регулярки, работа состроками)->B (тоже что-то делаем). Пусть у нас есть многопоточный коррелятор, сделанный без изыска. Пришло событие А, сразу за ним приходит В оба попадают в шаренную память. Поток 1 хочет взять событие и поток 2 тоже. Как потоку 1 сказать потоку 2, чтобы он не трогал А, правильно – блокировкой (мьютексы/симафоры и все такое). Поток 2 ловит блок на А и переходит к В (потеряли время). Теперь поток 1 начал обрабатывает А, а поток 2 событие В. Пусть обработка А имеет большую сложность, чем B. В таком случае нам нужен кто-то третий, который получит ответ от потока 2 и дождется ответа от потока 1. Ура, вот мы потеряли еще время и получили нового участника корреляции, который также жрет память и такты проца.
Усложним задачу. Пусть обработка А требует записи в табличный список, а В чтения того, что записалось ранее. Если время обработки А и В разное, следовательно поток 2 будет вынужден ждать поток 1, т.е. получаем лок. Если у нас таких правил не 1, а сотни, мы впадем в постоянные локи и большую часть времени коррелятор будет ждать их снятия.
Вспомним что входящий поток нельзя уменьшить и вот мы получаем коррелятор, который весь в локах и копит очереди т.к. не справляется. И это я еще не рассматриваю ситуацию дед локов.

Это очень упрощенныое объяснение, думаю профессиональные разработчики меня поправят, если где наврал.

дьявол кроется в деталях, я могу и на SPARK с Ignite сделать распределенную корреляцию

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

++

Да, такое возможно, но для этого нужно делать планировщик выполнения правил. Это уже на github не скачать и на коленке силами одного студента не сделать. Нужно найти очень хорошего спеца или команду и посадить только на эту задачу. Кто готов выкинуть тонну денег просто чтобы сделать планировщик?

Еще чуток про производительность. Есть такой подход к разработке как lock-free, он помогает бороться с локами, но вот эти подходы надо знать и уметь. Для небольшого стартапа, решившего пилить свой коррелятор - это финансово неподъемная задача, не имеющая монетизации в оперативном и тактическом плане.

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

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

Ладно, я к тому, что внезапно начало казаться, что многопоточный коррелятор не такая космическая задача. Главное поток не пытаться резать. Наверное, дьявол действительно в деталях.

почти все задачи не являются космическими, особенно если заранее знать как их решать.

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