REDB изнутри, статья 1: 13 таблиц, на которых работает всё

В сфере искусственного интеллекта произошло заметное событие. grelikt 7 минут назад REDB изнутри, статья 1: 13 таблиц, на которых работает всё Средний 14 мин 160 . NET * PostgreSQL * Microsoft SQL Server * Базы данных * Open source * Туториал REDB SQLВ предыдущей статье я разобрал что умеет REDB на практике: code-first схемы, LoadAsync без Include, LINQ с оконными функциями, деревья, redb. Если не читали — начните с неё, она даёт общую картину.

Теперь начинаю цикл «REDB изнутри» — серия статей про устройство хранилища: как хранятся объекты и свойства, как работают схемы и кэш структур, как LINQ превращается в SQL, как устроены деревья, права, оконные функции. Всё с реальным SQL под капотом. Первая статья цикла — про саму базу данных.

Технические детали

Без понимания схемы таблиц всё остальное будет висеть в воздухе. Вся магия REDB делается в 13 таблицах. Никакого JSON-блоба, никакого NVARCHAR(MAX) для всего подряд — каждый тип данных в своей типизированной колонке.

Разберём как это работает и почему это не классический EAV. Почему не «EAV»Прежде чем смотреть на таблицы — важное терминологическое замечание. EAV (Entity–Attribute–Value) — это паттерн хранения данных, при котором строки таблицы выглядят так:object_id | attribute_name | value ----------|----------------|------- 42 | "FirstName" | "Alice" 42 | "Age" | "28" 42 | "Salary" | "85000" Всё в одной таблице, типы стёрты, имена атрибутов — просто строки.

Запрос «найди сотрудников с зарплатой > 80000» — это самоджойн или pivot. EXPLAIN выдаёт Seq Scan размером с диссертацию. REDB использует другую схему.

Отраслевые последствия

В values — не имена строками, а ссылки на structures (_id_structure bigint NOT NULL). Тип значения известен в момент записи. Для каждого C#-типа — своя колонка:_String text _Long bigint _Guid uuid _Double float _DateTimeOffset timestamptz _Boolean boolean _ByteArray bytea _Numeric NUMERIC(38, 18) _ListItem bigint -- FK → _list_items _Object bigint -- FK → _objects (ссылка на объект) Это ближе к RTTI (Run-Time Type Information): тип поля известен из structures.

id_type, и значение кладётся в правильную колонку. При чтении — CASE WHEN db_type = 'Long' THEN Long WHEN dbtype = 'String' THEN _String ... — один проход по строкам, никаких самоджойнов.

Разница принципиальная:EAVREDB (_values)Тип полястрока в attribute_nameFK → structures → typesХранение значениявсё в одну value text колонкув типизированную колонку (_Long, _String, ... )Фильтр Salary > 80000WHERE attribute_name='Salary' AND value::int > 80000WHERE idstructure = @struct_id AND _Long > 80000Индекс по значениюпо строке, cast на летупо типизированной колонке (partial index WHERE _Long IS NOT NULL)Поддержка массивовдополнительная таблица / JSONarrayparent_id + arrayindex в той же таблицеОбзор таблицПолная схема — 13 таблиц + 2 служебных, которые живут в отдельных SQL-файлах.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.