Множество небольших древовидных структур в базах данных SQL или NoSQL

Question

Я бы хотел хранить информацию об узлах в разных деревьях в базе данных.

Для начала будет более 20000 узлов, совместно используемых 500 деревьями, каждый узел будет иметь 5 числовых атрибутов. после создания каждому узлу требуется ссылка на все его непосредственные дочерние элементы, а не на другие узлы.

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

Я смотрел на модель смежности sql, которая, похоже, потребовала бы слишком много времени для построения каждой таблицы (чтобы сделать слишком много вызовов db), модель вложенного множества, которая возможна, но более сложна для расширения дерева, которое это то, что случится много, и это увеличивает сложность базы данных, что, как я вижу, может быть очень простой структурой и набором запросов.

Я также обратил внимание на MongoDb, но он, кажется, больше ориентирован на объекты типа JSON, и я использую java, и, возможно, перебил, а также HBase, который определенно просматривает перебор (преимущество заключается в том, что количество узлов становится огромным это может пригодиться, что возможно в будущем, и я мог бы увеличить время записи в БД, что также было бы преимуществом)

У кого-нибудь есть предложения, как мне поступить?

Превышают ли базы данных NoSql? они намного лучше хранят древовидные структуры? Это плохая практика, чтобы использовать их вместе с боковыми базами данных SQL?

Answer 1

если вы используете SQL Server 2008+, вы можете использовать новый тип данных HierarchyID , предназначенный для таких сценариев.

Answer 2

Если вы отбросите свойство (rgt - lft - 1) / 2 число выходных дочерних элементов во вложенных наборах и используете значения float для столбцов lft / rgt, вы можете вставить / обновить / удалить узлы за минимальное время.

Основная проблемапри этом, чтобы избежать проблем, связанных с точностью.Вы можете обойти последний, приведя к lft / rgt к числовому и обратно к плавающему, чтобы получить их каноническое представление.Пример с Postgres:

select (.1::float + .7::float) * 10::float;                          -- 8
select floor((.1::float + .7::float) * 10::float);                   -- 7
select floor(((.1::float + .7::float) * 10::float)::numeric::float); -- 8

Другая проблема достаточно проста в управлении и возникает, когда вам не хватает места: вам иногда нужно повторно индексировать часть или все дерево - это требует блокировки деревано это достаточно быстро, что вы можете сделать это, не влияя на нормальные операции.