EnglishРусский Map
LLM Wiki Pattern

Файлы как графовая база данных

title
Файлы как графовая база данных
type
concept
summary
Markdown-файлы как узлы, wikilink'и как рёбра - почему обычный vault удовлетворяет семантике графовой базы данных
tags
pkm, graph-database, markdown
created
2026-04-09
updated
2026-04-22
lang
ru
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 без каких-либо этапов преобразования.