Здравствуйте.

Вот если взять бинарники вашей СУБД и просто посмотреть символы функций внутри них, то очень много выдает названий с префиксом LLVM.
Увидеть это легко, даже просто просмотром бинарника по F3 в MC, или nm.
(на скрине вывод команды nm -g vsql_server | grep -w T | grep LLVM)
Складывается устойчивое ощущение, что внутри своей СУБД вы используете движок LLVM для выполнения своего байткода.
Таким образом:
1. вы используете импортную компоненту, без которой СУБД работать не может. и ее легко подвести под санкции. и саму эту компоненту вы вряд ли контролируете на уровне собственного форка.
2. возможно из этого движка LLVM вы иcпользуете JIT. я видел критику движков JIT в том, что они могут вносить недетерминированное поведение в исполнении кода, т.е. время выполнения одинакового кода может быть различным, а это не приемлемо для СУБД. (тем более если заявляется о ее нацеленности на выдающуюся производительность).

Что-то здесь не то.

# запускаю базу
# база при запуске создала конфиг с дефолтными параметрами

$./vsql_server
Warning 2026-02-18 19:49:30.368129: Cannot open "soqol_config.yml" configuration file, generating configuration file with default parameters.
Info 2026-02-18 19:49:30.368481: Service data directory: '/agenda/soqol/soqol/bin'
Info 2026-02-18 19:49:30.368692: Amount of service memory auto-configured, edit config file for better value.
Info 2026-02-18 19:49:31.906322: Assigned memory is locked successfully
Info 2026-02-18 19:49:31.933109: SYSTEM INFORMATION:
Info 2026-02-18 19:49:31.935644: vm memory size: 2048 MB
Info 2026-02-18 19:49:31.935733: run_rq_count: 8 numa_total: 1 lcpu_total: 8
Info 2026-02-18 19:49:31.935755: numa0 logic cores: 8
Info 2026-02-18 19:49:31.935775: LCPU MASKS
Info 2026-02-18 19:49:31.935812: numa: 1 core: 1 lcpu: 1
Info 2026-02-18 19:49:31.935834: numa: 1 core: 2 lcpu: 2
Info 2026-02-18 19:49:31.935854: numa: 1 core: 3 lcpu: 3
Info 2026-02-18 19:49:31.935872: numa: 1 core: 4 lcpu: 4
Info 2026-02-18 19:49:31.935885: numa: 1 core: 5 lcpu: 5
Info 2026-02-18 19:49:31.935906: numa: 1 core: 6 lcpu: 6
Info 2026-02-18 19:49:31.935919: numa: 1 core: 7 lcpu: 7
Info 2026-02-18 19:49:31.935932: numa: 1 core: 8 lcpu: 8
Info 2026-02-18 19:49:31.935954: NUMA CONTAINS
Info 2026-02-18 19:49:31.935965: numa0 lcpu_run: 8
Info 2026-02-18 19:49:31.935980: vsql_server version = 3.2.0-night260130
Info 2026-02-18 19:49:42.724547: Session memory: 2048 KB
Info 2026-02-18 19:49:42.724891: vsql_server is ready to receive commands

# стоплю базу
$ ^C
Info 2026-02-18 19:49:45.380770: shutdown started
Info 2026-02-18 19:49:46.190059: vsql_server shutdowned

# вижу дефолтный подозрительный параметр

$ grep "jit" soqol_config.yml
jit_memory: 128MB

# меняю параметр на ноль (ну раз он не нужен по дефолту)

$ sed -i 's/jit_memory: 128MB/jit_memory: 0MB/g' soqol_config.yml

# проверяю

$ grep "jit" soqol_config.yml
jit_memory: 0MB

#запускаю базу

$./vsql_server
Error 2026-02-18 19:51:23.991233: SOQ-23310: option service.jit_memory value out of bounds
Error 2026-02-18 19:51:23.991610: Error -23310 happened while "soqol_config.yml" configuration file was processed.
Panic 2026-02-18 19:51:23.992056:/builds/linter/via/vsql_server/src/service.c:716: service_init returned error -23310
Aborted (core dumped) ./vsql_server

Странно, что нельзя ноль поставить.
А как джит включается в конфиге или для конкретного запроса?

1. Можете ли дать полный список функционала в базе Сокол, который реализован через LLVM? Если полностью убрать LLVM из базы, то какой функционал пропадет в базе?

2. LLVM - это не дело вкуса, а дело официально заявленных компонент в базе Сокол. На текущий момент Вы поставляете бинарники базы с этой крупной компонентой, эта компонента должна быть заявлена в документации и в реестре ПО Минцифры.
Вместо этого Вы пишите ( https://reestr.digital.gov.ru/reestr/1123306/ ):
"Система управления базами данных SoQoL полностью разработана специалистами компании РЕЛЭКС. СУБД не основана на продуктах с отрытым исходным кодом и не использует стороннее программное обеспечение."
Как минимум это выглядит как введение в заблуждение регулирующих органов, инвесторов и пользователей. Вы предоставили в реестр ПО Минцифры недостоверные сведения.

3. Вот в документации Сокол написано:
"система основана на дисковом хранилище вида B-Tree".

Я запросил ИИ дать список деградаций для такой архитектуры. Ответ от ИИ:

"Специфика деградации классического B-tree (где данные хранятся и в листьях, и во внутренних узлах) заключается в том, что оно более «хрупкое» при росте объема данных по сравнению с B+tree.
Вот список конкретных видов деградации:
1. Падение коэффициента ветвления (Fan-out)
Это фундаментальная проблема B-tree при хранении строк.
Суть: Поскольку данные строк (payload) лежат во внутренних узлах, для навигационных ключей остается мало места.
Результат: Вместо того чтобы указывать на 100–200 дочерних узлов, узел указывает всего на 5–10. Дерево становится аномально высоким. Каждое чтение требует на 2–3 обращения к диску больше, чем в B+tree.
2. Деградация кэширования (CPU Cache & RAM)
Суть: В B+tree верхние уровни (только ключи) компактны и почти всегда лежат в L1/L2 кэше процессора или в RAM.
Результат: В B-tree внутренние узлы «жирные» из-за данных строк. Кэш забивается полезной нагрузкой, которая вам в данный момент не нужна (вы просто проходите мимо этого узла к другому). Эффективность кэширования падает в разы.
3. Нестабильное время ответа (Latency Jitter)
Суть: В B+tree путь до любой строки всегда одинаков (высота дерева
). В B-tree строка может быть найдена на первом уровне, а может на десятом.
Результат: Чем больше дерево фрагментируется, тем сильнее «скачет» время выполнения запросов. Предсказуемость производительности теряется.
4. Тяжелое расщепление узлов (Costly Page Splits)
Суть: Когда страница переполняется, её нужно делить.
Результат: В B-tree расщепление внутреннего узла — это сложная операция, которая требует перемещения не только ключей, но и тяжелых данных строк. Это блокирует бóльшие поддеревья и вызывает резкие «затыки» (stalls) при записи.
5. Катастрофическая деградация Range Scans
Это самая известная «болячка» B-tree.
Суть: В B+tree вы нашли начало диапазона в листе и просто идете вбок по списку. В B-tree вам нужно постоянно делать рекурсивный подъем к родителю и спуск к соседу.
Результат: С ростом объема данных количество переходов между уровнями растет экспоненциально. Поиск диапазона из 1000 строк превращается в тысячи операций логического чтения вместо одной-двух.
6. Проблема «пустых пятен» при удалениях
Суть: Удаление из середины B-tree сложнее, чем из листа. Часто оно требует перемещения ключа из листового узла вверх на место удаленного.
Результат: Возникает сложная фрагментация. В дереве появляются «дыры», которые трудно переиспользовать новыми данными, если их размер чуть больше, чем был у удаленных. Дерево начинает занимать на диске гораздо больше места, чем реально весят данные."

В чем смысл разработки такой СУБД в 2026г. ?
Oracle и Posgresql хранят строки в неупорядоченном виде.
Производительность в тестах, на которые Вы все время акцентируете внимание - это потемкинские деревни, после нескольких недель работы база будет "наедаться" всеми этими деградациями, и все эти результаты тестов могут обнулится.

А вот и подтверждение моей информации про JIT.

>> я видел критику движков JIT в том, что они могут вносить недетерминированное поведение в исполнении кода, т.е. время выполнения одинакового >> кода может быть различным, а это не приемлемо для СУБД. (тем более если заявляется о ее нацеленности на выдающуюся производительность).

$ vsql_console -h SOQOL:SOQOL@localhost
vsql_console version = 3.2.0-night260130
vsql> select /*+ JIT_CODEGEN */ 1+1;

1+1
----------
2
Query OK, 1 row processed <76 msec>

vsql> select /*+ JIT_CODEGEN */ 1+1;

1+1
----------
2
Query OK, 1 row processed <0 msec>

vsql> select /*+ JIT_CODEGEN */ 1+1;

1+1
----------
2
Query OK, 1 row processed <0 msec>

Здесь я запускаю базу и потом в клиенте делаю последовательно 3 одинаковых запроса. Делаю через JIT. Время первого запроса значительно больше других. Вот это и есть недетерминированность (то, что я и хотел увидеть). Но ИИ говорит, что на больших объемах данных JIT может дать прирост производительности.

В реестре есть требование о предоставлении достоверных сведений (при отправке заявления Вы ставите об этом галочку), и есть ответственность за предоставление недостоверных сведений.
И речь идет не про компиляторы, а про то, что бинарники Сокол имеют в своем составе статически слинкованные крупные (десятки мегабайт) зависимости. Но при этом заявляется как конкурентное преимущество: "СУБД не основана на продуктах с отрытым исходным кодом и не использует стороннее программное обеспечение". И сейчас Вы сами признаете данный факт. Для Оракл основным видом таблиц является тип таблица-куча. Другие же типы (IoT) на практике используются крайне редко.
Из знакомых мне СУБД к верхнему технологическому эшелону я бы отнес прежде всего базы с таблицами-кучей: Oracle, Postgresql, Altibase.
Все остальное - это либо нижний, либо специфично-нишевые решения, потому что все с кучей проблем по возможным деградациям.

Я понимаю, что в первом случае идет компиляция, а во втором и третьем - выполнение готового.
А должно ли так быть? Удобно ли это для прикладной системы, для пользователей?

/***************************/
/***************************/
/***************************/
А вот еще наблюдение:

1-я сессия:

# запуск базы2-я сессия:

# запуск ltrace3-сессия

# запросы в клиенте базы без JIT и с JITПервый запрос отработал мгновенно. Второй - полностью висит и не выполняется (пока работает ltrace во второй сессии). После киляния ltrace запрос с JIT отработал и написал Query OK, 1 row processed <237229 msec>.

Давайте внедрим это где-нибудь в проде.
А вот например в Вашей компании РЕЛЭКС.

Тогда прошу пояснить какой функционал в базе выполняется через LLVM?
Сейчас получается, что выполнение jit-запросов. Есть еще что-то к этому?
Компиляция и выполнение процедур/функций/триггеров?
Есть ли возможность получить бинарную сборку Сокол без LLVM? (какой функционал СУБД тогда не будет работать по сравнению с сборкой где есть LLVM).