Представим, что у нас индикатор A — температура воздуха, и индикатор B — температура воды.
От них есть зависимости: индикатор "средняя температура воды", индикатор "средняя температура воздуха", а от них — средняя по больнице, и ещё 100000 других индикаторов. Все они persistent в бд и в memcache.
Пользователь в один момент времени следит за 3 случайно выбранными индикаторами. Обновления температур волы или воздуха приходят часто, и мы не можем попросить их подождать, пока мы оповестим всех подписчиков, их состояние стало dirty.
Как практически реализовать, что есть некая копия Merkle Tree, где сохранены серийные номера исходных индикаторов, и хэши зависимостей их. Что для показа 3 случайных индикаторов, быстро узнать не грязные ли они, и построить быстро дерево "грязных" dependable индикаторов в топологической сортировке, и поставить задачи на пересчет в очередь на исполнение?
Цимес- изменение базового индикатора отражалось одним изменением хэша, вместо оповещения 100000 подписчиков, и их 100000 флагов "dirty".
Здравствуйте, Тёмчик, Вы писали:
Тё>Как практически реализовать, что есть некая копия Merkle Tree, где сохранены серийные номера исходных индикаторов, и хэши зависимостей их. Что для показа 3 случайных индикаторов, быстро узнать не грязные ли они, и построить быстро дерево "грязных" dependable индикаторов в топологической сортировке, и поставить задачи на пересчет в очередь на исполнение?
Вот именно хеши нужны? Казалось бы, по графу зависимостей распространяется бит грязи, и всё. Можно сказать, что это однобитный хеш.
Тё>Цимес- изменение базового индикатора отражалось одним изменением хэша, вместо оповещения 100000 подписчиков, и их 100000 флагов "dirty".
Цимес дерева хешей в том, что размер хеша много меньше размера блока данных, во-первых, и пересчёт итогового хеша всего набора не требует забега по всему набору (потому что хеши блоков уже загодя посчитаны).
Для крошечных данных, типа температуры, хеширование выглядит избыточным.
Может быть, стоит заехать с другого края.
У нас есть первичные индикаторы, промежуточные и выходные.
Каждому первичному соответствует набор зависимых от него. При изменении индикатора — бежим по этому списку и прописываем в них признак грязи. И запускаем фоновый процесс перевычисления.
И наоборот, каждому выходному соответствует набор первичных зависимостей. Чтобы быстро ответить на вопрос, грязный ли выход, надо сравнить метку времени, когда он был вычислен, с метками времени последних обновлений первичных.
Тут всё упирается в две вещи.
Первое: сколько зависимых есть у каждого первичного индикатора. То есть, — есть ли смысл персонально их инвалидировать (потому что их мало, потому что граф зависимостей — более-менее логарифмически-деревянный), или проще инвалидировать граф целиком.
И в обратную сторону: сколько зависимостей у каждого выходного. Нужно ли смиренно ждать, пока они обновятся сами, или, в случае инвалидации выхода, инвалидировать все зависимости (кроме первичных) и пересчитать принудительно — только те, которые нас интересуют.
Второе: какие требования к доступности выходных индикаторов.
Нужно ли всегда отдавать строго актуальное значение либо "подождите, оно протухло", — тут мы рискуем при большом темпе обновлений никогда не получить ответ;
или же значение, актуальное за последний отчётный период (своеобразный режим антидребезга) — например, это делается так: раз в период состояние входных датчиков замораживается, и если оно отлично от предыдущего слепка, перевычисляются все зависимости, доходя до выходных, после чего выходные замораживаются и будут отдаваться пользователю в течение всего следующего периода;
или же можно вычислять зависимости по уже устаревшим данным, и это некритично — фактически, это просто задержки разной длины. И по графу бегут фронты обновлений, и даже, возможно, некогерентные.
Здравствуйте, Тёмчик, Вы писали:
Тё>... Все они persistent в бд и в memcache. Тё>... Тё>Цимес- изменение базового индикатора отражалось одним изменением хэша, вместо оповещения 100000 подписчиков, и их 100000 флагов "dirty".
Например так.
Каждая запись в бд увеличивает счетчик. Значение счетчика и есть уникальный хеш.
В чем вопрос? В том, как узнать что зависимое значение "грязное"? При вычислении зависимого значения записываешь наибольшее значение номера использованной записи при вычислении записи. При запросе значения указываешь минимальный номер записи. Можешь заодно завести индикатор "секундомер", чтобы знать возраст записи.
Ограничения: счетчик — не масштабируется, блокируя запись в бд.
Здравствуйте, Тёмчик, Вы писали:
Тё>Пользователь в один момент времени следит за 3 случайно выбранными индикаторами. Обновления температур волы или воздуха приходят часто, и мы не можем попросить их подождать, пока мы оповестим всех подписчиков, их состояние стало dirty.
Overengineering detected. Мы просто обновляем первичные индикаторы вместе с отметкой времени. А фоновый процесс пересчитывает зависимые (по отметкам времени) и оповещает пользователей. Пользователю все равно, изменилось значение 1 раз или 10 между оповещениями.
Перекуём баги на фичи!
