Вопрос:
Я разрабатываю приложение, использующее нейронную сеть. В настоящее время я рассматриваю либо попытку включить его в реляционную базу данных на основе SQL (возможно, SQL-сервера), либо базы данных графа.
С точки зрения производительности нейронная сеть будет очень большой.
Мои вопросы:
- Влияют ли реляционные базы данных на производительность при работе с нейронной сетью по сравнению с базами данных графов?
- Какая технология с графическими базами лучше всего подходит для работы с большой нейронной сетью?
- Можно ли использовать геопространственную базу данных, такую как PostGIS, для эффективного представления нейронной сети?
Лучший ответ:
Это зависит от цели продвижения по модели.
- У вас есть фиксированная идея о неизменной структуре сети? Как карта Кохоннен. Или готовая модель.
- У вас есть несколько структур отношений, которые вам нужно проверить, чтобы вы могли перевернуть переключатель, чтобы чередовать различные структуры.
- Рассматривает ли ваша модель узлы как автоматические автоматы, свободно искать своих соседей? Где каждый автомат разрабатывает уникальные характерные значения общего набора параметров, и вам нужно проанализировать, как эти ценности влияют на их “выбор” соседей.
- У вас есть фиксированный набор параметров для фиксированного числа типов/классов узлов? Или существует node, который должен разработать уникальный диапазон атрибутов и отношений?
- Вам часто приходится обращаться к каждому node, особенно к тем, которые внедрены глубоко в сетевые уровни, для их анализа и корреляции?
- Является ли ваша сеть воспринимаемой или квантифицируемой в наборе состояний машин?
Отказ
Прежде всего, мне нужно признать, что я знаком только с картами Кохоннен. (Таким образом, я признаю, что меня высмеивали за Kohonnen как за начальный уровень всего, что было в нейронной сети). Вышеупомянутые вопросы являются следствием личных умственных эксплойтов, которые я на протяжении многих лет фантазировал после случайного и малообразованного чтения различные нейронные shemes.
Категория vs Параметр против атрибута
Можем ли мы классифицировать автомобили по количеству колес или тоннажа? Если количество или тонна колес являются атрибутами, параметрами или характеристиками категории.
Понимание этой дискуссии является важным шагом в структурировании вашего репозитория. Эта дискуссия особенно актуальна для болезней и векторов пациентов. Я видел реляционные схемы информации пациента, разработанные медицинскими экспертами, но, очевидно, без большой подготовки в области информатики, которые предполагают общий набор параметров для каждого пациента. С тысячами столбцов, в основном неиспользованных, для каждой записи пациента. И когда они превышают пределы столбцов для таблицы, они создают новую таблицу с еще тысячами разреженных столбцов.
-
Тип 1: все узлы имеют общий набор параметров и, следовательно, node можно смоделировать в таблицу с известным числом столбцов.
-
Тип 2: Существуют различные классы узлов. Существует фиксированное число классов узлов. Каждый класс имеет фиксированный набор параметров. Поэтому для каждого класса node существует таблица характеристик.
-
Тип 3: нет намерения прорезать узлы. Каждый node может свободно разрабатывать и приобретать собственный уникальный набор атрибутов.
-
Тип 4: существует фиксированное количество классов узлов. Каждый node внутри класса может свободно разрабатывать и приобретать собственный уникальный набор атрибутов. Каждый класс имеет ограниченный набор атрибутов, доступный node.
Прочитайте модель EAV, чтобы понять проблему параметров с атрибутами. В таблице EAV для node требуются только три столбца:
- node id
- имя атрибута
- значение атрибута
Однако при ограничениях технологии атрибут может быть числом, строкой, перечислимой или категорией. Следовательно, было бы еще четыре таблицы атрибутов, по одному для каждого типа значений, плюс таблица node:
- node id
- тип attriute
- имя атрибута
- значение атрибута
Последовательный/связанный доступ по сравнению с хэшированным/прямым адресом доступа
Нужно ли вам обращаться к отдельным узлам напрямую, а не перемещаться по структурному дереву, чтобы быстро добраться до node?
Вам нужно найти список узлов, которые приобрели определенный признак (набор атрибутов), независимо от того, где они расположены топологически в сети? Нужно ли выполнять классификацию (например, анализ основных компонентов) на узлах вашей сети?
Государство-машина
Вы хотите воспринимать регионы своей сети как набор государственных машин?
Государственные машины являются очень полезными объектами квантования. Квазитизация состояния машины помогает вам сформировать эмпирические сущности над множеством узлов, основанных на сходствах и связях окрестностей.
Вместо того, чтобы пытаться понять и отслеживать индивидуальное поведение миллионов узлов, почему бы не объединить их в области сходства. И отслеживать поток состояний этих регионов.
Заключение
Это моя рекомендация. Сначала вы должны начать использовать полностью реляционную базу данных. Причина в том, что реляционная база данных и связанный с ней SQL предоставляют информацию с очень либеральным взглядом на отношения. С SQL на реляционной модели вы можете запросить или сопоставить отношения, которые вы не знали.
По мере того, как ваши эксперименты продвигаются, и вы можете найти определенное моделирование отношений, более подходящее для репозитория сетевого графика, вы должны перенести эти части схемы в такой подходящий репозиторий.
В конечном состоянии. Я бы поддержал двухрежимную репо. Вы поддерживаете реляционное репо, чтобы отслеживать узлы и их атрибуты. Таким образом, вы храните динамически мутирующую структуру в репозитории сетевого графика, но каждый node ссылается на id node в реляционной базе данных. Где реляционная база данных позволяет запрашивать узлы на основе атрибутов и их значений. Например,
SELECT id FROM Nodes a, NumericAttributes b WHERE a.attributeName = $name AND b.value WItHIN $range AND a.id = b.id
Я думаю, что, возможно, hasoop можно использовать вместо традиционной базы данных сетевого графика. Но я не знаю, насколько хорошо адаптируется к динамически изменяющимся отношениям. Я понимаю, что хаоп хорош для однократного чтения. Однако динамическая нейронная сеть может плохо работать при частых изменениях отношений. Принимая во внимание, что сетевые отношения моделирования реляционной таблицы неэффективны.
Тем не менее, я считаю, что у меня есть только вопросы, которые вам нужно рассмотреть, а не дать вам определенный ответ, особенно с ржавыми знаниями по многим концепциям.
Ответ №1
Деревья можно хранить в таблице с помощью внешних ссылок. Я предполагаю, что только две вещи, которые нужно сохранить, – это топология и вес; оба они могут храниться в сплющенной структуре дерева. Конечно, для этого может потребоваться много рекурсивных выборок, которые в зависимости от вашей РСУБД могут быть больными для реализации изначально (таким образом, для достижения многих запросов SQL). Я не могу комментировать сравнение, но, надеюсь, это помогает с реляционной точки зрения:)
