Добрый день! Подскажите пожалуйста подходящее хранилище для хранения множества очень маленьких типовых связаннных объектов.

Требования:
неограниченная вложенность
возможность циклических ссылок
возможность на лету изменять ссылки
большая скорость выборки(!), изменения и удаления (вставки не так важно)
API под Java или .Net.

В данном случае традиционные SQL не подходят, т. к. связи должны изменяться на лету в зависимости от внутренней логики (да, забыл написать. нейрон должен поддерживать простые изменяющиеся на лету внутренние алгоритмы в зависимости от входных-выходных параметров). Связей может быть больше одной, до 8. Таких нейронов ОЧЕНЬ много. Традиционные СУБД не потянут.

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

RXLЧем же они не подходят? Или вы реализуете нейронную сеть прямо в базе? ;)что-то близкое к этому. Т. е. требуется некий черный ящик, у которого есть вход и выход и который можно реализовать (поведение) прямо внутри него, не прибегая к различным извращениям снаружи.

RXLСтруктурно, нейронная сеть - это граф: набор узлов с их свойствами и направленные ребра со своими свойствами.
Да, только вот ребра имеют свойства динамически переопределяться, как и элементы. Т. е. по некоему условию ребро может быть разрушено или создано и направлено на совершенно другой узел (который, в свою очередь, должен иметь набор свойств, определяющих, что он готов принять ребро с конкретными свойствами).

RXLЧто вы имеете в виду под "изменяющуюся логику поведения в объект нейрона"? Изменение коэффициентов, перекоммутация связей, изменение числа нейронов?
все вместе.

RXL
Реализация прямо в базе - это и есть, извините, извращение. Хотя и реализуемое.

Т.ч. пока так и не понятно, в чем у вас трудности и в чем состоит вопрос.
В том что задача здесь вовсе не СУБДшная (SQL вообще не нужен, разве что на этапе доводки - битые сущности подчищать), но нужно некое хранилище с данным функционалом. Глупо натягивать что-то 100% объектно-ориентированное на классическую СУБД, тем более что это "что-то" вообще не содержит никаких данных по сути.

AlexsalogМожет нужно рассмотреть key->value СУБД. Ну там Mongo, Raven
о, гляну, спасибо.

RXL,

Имеются ввиду данные в классическом понимании. Функциональность классических СУБД все-таки на это рассчитана.

Можно конечно извратиться и сделать на SQL, только тогда при проходе сигнала КАЖДЫЙ элемент и КАЖДОЕ ребро будут лазать в какую-либо внешнюю надстройку для построения алгоритма своего поведения. Очень сомневаюсь, что это вообще будет шевелиться.

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

Считайте что я захотел создать Lawul Evil Chaotic Network, запустить и. потирая лапки, посмотреть что выйдет.

Грубо говоря, есть некий алгоритм построения конкретной сети. Есть прототип, написанный на .Net вообще без СУБД (все в памяти). Он работает. Но для достижения неких целей объектов должно быть существенно больше, а кроме того надо периодически сохранять состояния, для чего, очевидно, это решение не подходит. Да и скорость в данном случае не особо устраивает.

О, спасибо, вот это уже что-то

Я боюсь что тогда как раз и выйдет реализация того, что мне нужно. Там все далеко не так просто. Например я не могу разом гарантированно остановить работу всей сети.

Dimitry SibiryakovНу так выдумайте способ сохранять её состояние без остановки.

Ага, транзакции реализовывать. Круто.

Это в принципе невозможно, т. к. есть взаимная вложенность. Т. е. существуют ситуации когда A дергает B, а B дергает A до тех пор, пока не произойдет изменение маршрута.

точнее, a->b->c->a и т. д.

Я еще раз обьясняю, что это by design и окончание действия этого цикла зависит от поведения других элементов.

Сначала все что можно перепробую (может что-то из опенсорца подойдет к дописке). Круто это - свою СУБД писать.

авторСеть изменяется итеративно.
В том-то и дело, что это классическая сеть изменяется итеративно. А в моей есть асинхронные потоки. Не так как кто-то там вверху написал конечно, но есть.

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

Взаимодействуют естественно. и еще напрямую меняют структуру сети в некоторых случаях.

Нет, посмотрю, спасибо за наводку.

b099ardRandom_Goodman,
Можете сказать зачем вам нужна такая программа?
Чтобы зохавать весь мозг этих ваших интырнетов и поработить мир, естественно. Слава роботам!

Если серьезно, то хочу повертеть патентом перед Samsung. Может что выйдет. А для этого нужон не прототип, а хотя бы уже нормально работающая прога.