Имеет ли смысл использовать neo4j для индексации файловой системы - PullRequest
5 голосов
/ 21 июня 2011

Я работаю над клиентом резервного копирования на основе Java, который сканирует файлы в файловой системе и заполняет базу данных Sqlite каталогами и именами файлов, которые он находит для резервного копирования.Имеет ли смысл использовать neo4j вместо sqlite?Будет ли это более практичным и простым в использовании для этого приложения.Я думал, потому что файловая система - это дерево (или граф, если вы рассматриваете символические ссылки), может пригодиться база данных с пробелами?Схема базы данных sqlite определяет только 2 таблицы, одну для каталогов (полный путь и другую информацию) и одну для файлов (имя только с внешним ключом для содержания каталога в таблице каталогов), поэтому это относительно просто.

Приложениенеобходимо проиндексировать многие миллионы файлов, поэтому решение должно быть быстрым.

Ответы [ 3 ]

3 голосов
/ 22 июля 2011

Насколько я понимаю, одно из самых ранних применений Neo4j состояло в том, чтобы сделать именно это как часть системы CMS, из которой происходит Neo4j.

Lucene, сервер индексирования для Neo4j, позволит вам создавать любые индексы, которые вам могут понадобиться.

Вы должны прочитать об этом и задать их напрямую.

3 голосов
/ 21 июня 2011

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

0 голосов
/ 01 октября 2017

Я рассматриваю подобное решение для индексации хранилища данных в файловой системе. Замечание по поводу вышеприведенных запросов верно.

Примеры запросов наихудшего случая:

Для sqlite:

  • если у вас есть большое количество подкаталогов где-то глубоко в fs, ваша потребность в пространстве на sqlite не будет оптимальной: сохраните полный путь для каждой небольшой подкаталоги (например, подумайте о проекте кода)
  • если вам нужно переместить каталог, чем ближе к корню, тем больше работы вам придется сделать, так что это не будет O (1), как это было бы с neo4j
  • вы можете сделать многопоточность на sqlite для масштабирования?

Для neo4j:

  • каждый раз, когда вы ищете полный путь, вам нужно разбить его на компоненты и создать запрос шифрования со всеми элементами пути.
  • модель данных, вероятно, будет более сложной, чем две таблицы: все различные объекты, затем отношение dir-in-dir, отношение file-in-dir, отношение symlink

Привет, хидж

...