Файлы как графовая база данных
- title
- Файлы как графовая база данных
- type
- concept
- summary
- Markdown-файлы как узлы, wikilink'и как рёбра - почему обычный vault удовлетворяет семантике графовой базы данных
- tags
- pkm, graph-database, markdown
- parent
- llm-wiki-pattern
- sources
- filesystem-is-graph-database
- created
- 2026-04-09
- updated
- 2026-04-22
- lang
- ru
- translation_of
- files-as-graph-database
- source_updated
- 2026-04-22
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
Обычная директория с Markdown-файлами и wikilink'ами удовлетворяет структурным требованиям графовой базы данных: узлы (файлы), рёбра (ссылки) и опциональные метки (папки, теги во frontmatter). Чтобы запрашивать граф, не обязательно иметь графовую СУБД - нужен сам граф.
Сопоставление буквальное:
- Узел = один Markdown-файл, идентифицируемый по имени файла
- Ребро = wikilink
[[other-file]]в теле файла - Свойства узла = YAML frontmatter
- Тип / метка ребра = контекст вокруг ссылки или специальные поля во frontmatter вроде
parent:илиsources: - Индекс / таксономия = структура папок
От чего приходится отказаться по сравнению с полноценной графовой базой данных: нет индексированного обхода рёбер, нет языка запросов, нет гарантий ACID, нет многошаговых join'ов за константное время. Что взамен: любой инструмент на вашей машине уже умеет с этим работать. Grep становится движком запросов. Git - контролем версий. Obsidian - визуализатором. LLM с доступом к файлам - интерфейсом запросов на естественном языке.
Подход масштабируется лучше, чем можно ожидать. В filesystem-is-graph-database описано ~52k файлов, поддерживаемых таким способом. Схема держится потому, что большинство PKM-запросов - это не графовые запросы в смысле Cypher; они сводятся к "найди всё, что связано с X, и покажи мне содержимое". Ripgrep справляется с этим за миллисекунды. Настоящий многошаговый обход нужен редко; когда он всё же требуется, ограниченного поиска по связанным файлам с помощью LLM обычно вполне достаточно.
Главное архитектурное решение - сделать граф читаемым для инструментов, которые не знают, что это граф. Имена файлов должны быть уникальными, чтобы wikilink'и разрешались однозначно. Вложенность папок должна быть небольшой, чтобы основным способом навигации был переход по ссылкам, а не обход директорий. Frontmatter должен быть единообразным, чтобы его можно было разбирать без исключений для отдельных файлов.
Именно на это опирается llm-wiki-pattern и этот Second Brain в целом. Это перекликается и с obsidian на уровне соглашений: Obsidian как раз работает с файлами ровно так, поэтому vault'ы чисто переносятся между Obsidian и сценариями чистого CLI. Та же структура сохраняется и при публикации: digital-garden, опубликованный через quartz, сохраняет узлы, рёбра и frontmatter без каких-либо этапов преобразования.