Есть вопрос касательно архитектуры следующей системы. Есть система,
которая должна уметь хранить большое или очень большое кол-во объектов
одного типа. Ориентировочное кол-во объектов — около 10.000.000.
Каждый объект может иметь свой граф состояний (машину состояний). Отсюда
следует что их надо постоянно поллить. В данный момент храню все объекты
в базе (BDB) и соотв. поллингом переключаю все состояния. Но по ресурсам
получается как то очень ресурсоемно.
Вопрос к сособществу. Как модно подобные задачки-то решать ?
Здравствуйте, _kostet_, Вы писали:
__>в базе (BDB) и соотв. поллингом переключаю все состояния. Но по ресурсам __>получается как то очень ресурсоемно.
Что именно тормозит? В первую очередь в голову приходит не трогать все объекты сразу, а как-нибудь предугадывать, в каких из них будет изменение состояния, а в каких нет.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, _kostet_, Вы писали:
__>>в базе (BDB) и соотв. поллингом переключаю все состояния. Но по ресурсам __>>получается как то очень ресурсоемно.
Кё>Что именно тормозит? В первую очередь в голову приходит не трогать все объекты сразу, а как-нибудь предугадывать, в каких из них будет изменение состояния, а в каких нет.
On 06/02/2011 11:20 AM, Кодёнок wrote: > Что именно тормозит? В первую очередь в голову приходит не трогать все объекты > сразу, а как-нибудь предугадывать, в каких из них будет изменение состояния, а в > каких нет.
тормозит как раз то, что приходится обходить все объекты
Первое что приходит на ум, это как вы правильно сказали, разделить как-то все
объекты на подмножества. Но как это сделать не приходит на ум, так как у
объектов некоторые переходы состояний зависят от времени т.е. типа "переключить
состояние с А на В по истечении 24 часов".
On 06/02/2011 12:54 PM, Sanik wrote: > а нотификации при смене состояний уже не модны?
наверно модны ))
но приложение однопоточное поэтому нотификации могуть быть посланы только
вызывающим потом самому себе. это все равно приводит к тому что надо перебрать
все объекты
Здравствуйте, _kostet_, Вы писали:
__>On 06/02/2011 11:20 AM, Кодёнок wrote: >> Что именно тормозит? В первую очередь в голову приходит не трогать все объекты >> сразу, а как-нибудь предугадывать, в каких из них будет изменение состояния, а в >> каких нет.
__>тормозит как раз то, что приходится обходить все объекты
__>Первое что приходит на ум, это как вы правильно сказали, разделить как-то все __>объекты на подмножества. Но как это сделать не приходит на ум, так как у __>объектов некоторые переходы состояний зависят от времени т.е. типа "переключить __>состояние с А на В по истечении 24 часов".
Не очень понятно что вам надо. Имея сигнал и граф состояний автомата, мы можем определить множество состояний автомата, из которых есть переход под действием этого сигнала. Выбираем объекты, которые находятся в таких состояниях, из них выбираем источник сигнала и меняем его состояние. Нужно разбить на множества по состояниям чтоб быстрей искать. Как то так.
Здравствуйте, _kostet_, Вы писали:
__>объектов некоторые переходы состояний зависят от времени т.е. типа "переключить __>состояние с А на В по истечении 24 часов".
Можно завести у каждого объекта свойство, когда у него “тикнет” ближайший таймер. Если это записи в БД, индексировать по этому полю, если нет, вести сортированный список. Если индекс/список слишкой большой (например, если у абсолютно всех объектов есть такие таймеры), можно дополнительно разбить на группы: ближайшие 5 минут, ближайшие полчаса, ближайшие сутки и каждые 5 минут/полчаса/сутки перебирать следующую группу и переносить объекты, время которых вот-вот подойдет.
Имея сигнал и граф состояний автомата, мы можем определить множество состояний автомата, из которых есть переход под действием этого сигнала. Выбираем объекты, которые находятся в таких состояниях, из них выбираем источник сигнала и меняем его состояние. Нужно разбить на множества по состояниям чтоб быстрей искать. Как то так. 
