Здравствуйте, Тёмчик, Вы писали:

Тё>Как практически реализовать, что есть некая копия Merkle Tree, где сохранены серийные номера исходных индикаторов, и хэши зависимостей их. Что для показа 3 случайных индикаторов, быстро узнать не грязные ли они, и построить быстро дерево "грязных" dependable индикаторов в топологической сортировке, и поставить задачи на пересчет в очередь на исполнение?

Вот именно хеши нужны? Казалось бы, по графу зависимостей распространяется бит грязи, и всё. Можно сказать, что это однобитный хеш.

Тё>Цимес- изменение базового индикатора отражалось одним изменением хэша, вместо оповещения 100000 подписчиков, и их 100000 флагов "dirty".

Цимес дерева хешей в том, что размер хеша много меньше размера блока данных, во-первых, и пересчёт итогового хеша всего набора не требует забега по всему набору (потому что хеши блоков уже загодя посчитаны).
Для крошечных данных, типа температуры, хеширование выглядит избыточным.

Может быть, стоит заехать с другого края.
У нас есть первичные индикаторы, промежуточные и выходные.
Каждому первичному соответствует набор зависимых от него. При изменении индикатора — бежим по этому списку и прописываем в них признак грязи. И запускаем фоновый процесс перевычисления.
И наоборот, каждому выходному соответствует набор первичных зависимостей. Чтобы быстро ответить на вопрос, грязный ли выход, надо сравнить метку времени, когда он был вычислен, с метками времени последних обновлений первичных.

Тут всё упирается в две вещи.

Первое: сколько зависимых есть у каждого первичного индикатора. То есть, — есть ли смысл персонально их инвалидировать (потому что их мало, потому что граф зависимостей — более-менее логарифмически-деревянный), или проще инвалидировать граф целиком.
И в обратную сторону: сколько зависимостей у каждого выходного. Нужно ли смиренно ждать, пока они обновятся сами, или, в случае инвалидации выхода, инвалидировать все зависимости (кроме первичных) и пересчитать принудительно — только те, которые нас интересуют.

Второе: какие требования к доступности выходных индикаторов.
Нужно ли всегда отдавать строго актуальное значение либо "подождите, оно протухло", — тут мы рискуем при большом темпе обновлений никогда не получить ответ;
или же значение, актуальное за последний отчётный период (своеобразный режим антидребезга) — например, это делается так: раз в период состояние входных датчиков замораживается, и если оно отлично от предыдущего слепка, перевычисляются все зависимости, доходя до выходных, после чего выходные замораживаются и будут отдаваться пользователю в течение всего следующего периода;
или же можно вычислять зависимости по уже устаревшим данным, и это некритично — фактически, это просто задержки разной длины. И по графу бегут фронты обновлений, и даже, возможно, некогерентные.