Перейти к содержимому

Измерения

Результат теста относится к одному бинарнику, набору данных и стенду. Он не является общим заявлением о скорости, пределом ёмкости или соглашением об уровне обслуживания. Это приложение сохраняет идентичность исходников, методику и условия чисел, использованных в руководстве.

ГБ ниже означает десятичные байты. MiB и GiB используют степени 1024. RSS отражает резидентную память процесса и не включает данные, находящиеся только в файловом кэше операционной системы.

ID Назначение Исходник RadixDB Дата Оборудование и хранилище Основной источник
BENCH-01 Междвижковая проверка performance и footprint на 100M b648b2d3ea323cf5eb10417ab09d5eb3d5d01ecc 2026-09-06 AMD Ryzen 9 7950X; NVMe Apacer AS2280Q4U 2 ТБ; Btrfs; Linux 7.1.3-201.fc44.x86_64 Сравнительный отчёт 100M
BENCH-02 Финальный regression gate запросов 1.1 performance code tip 12ef5963 2026-09-08 Сохранённая база 100M на NVMe/Btrfs Отчёт проверки 1.1
BENCH-03 Текущая проверка 100M для 1.2 23bf35df011aae6816d77578be96074b02bc363c 2026-09-09 Канонический NVMe run на устройстве nvme1n1 Отчёт проверки 1.2
SOAK-01 Шесть часов correctness и recovery на ограниченном железе dd0bf75c9176bceb70ce8f1d2a07057610ec381b 2026-09-07 Intel Celeron 847, 1,10 ГГц; 2 logical CPU; 1,76 GiB RAM; HDD Toshiba MQ01ABD050 5400 rpm; ext4 Отчёт шестичасовой приёмки

Первые две строки являются performance evidence на NVMe. SOAK-01 является испытанием надёжности на деградировавшем HDD path и никогда не объединяется с ними для вычисления latency или throughput.

Набор торгового типа содержит ровно 100 000 000 строк и 120 связанных таблиц. Все участники получили checksum 100000000:49734600639880 и одинаковые cardinality запросов.

Baseline PostgreSQL 18.3 записан 2026-08-28 на том же стенде и наборе. Он прошёл свежее создание схемы, загрузку и построение индексов. Candidate RadixDB измерен 2026-09-06. PostgreSQL в этот день повторно не запускался.

В каждой серии запросов RadixDB один warm-up исключался, затем сохранялась медиана пяти измерений. В таблице приведена медиана трёх run-level medians. Первый verify run выполнялся после адресного DONTNEED для файлов базы, два следующих были cache-hot. page_cache_level равнялся 0, число storage workers выбиралось автоматически.

COPY PostgreSQL использовал synchronous_commit=off при отключённом autovacuum. Его время загрузки является ориентиром throughput, а не сравнением одинаковой durability с синхронными commits RadixDB. Footprint базы не включает больший каталог кластера PostgreSQL и WAL.

ID Измерение RadixDB PostgreSQL 18.3 Интерпретация
CMP-01 Логический объём базы 1 964 220 021 байт 16 126 596 799 байт RadixDB в 8,21 раза компактнее на этом наборе
CMP-02 Полное сканирование 100,299 ms 246,457 ms RadixDB быстрее в 2,46 раза
CMP-03 Чтение выбранных столбцов 23,189 ms 84,456 ms RadixDB быстрее в 3,64 раза
CMP-04 Группировка с HAVING 9,907 ms 24,948 ms RadixDB быстрее в 2,52 раза
CMP-05 Точечный поиск 0,490 ms 0,237 ms PostgreSQL быстрее в 2,07 раза
CMP-06 Диапазонный поиск 0,475 ms 0,269 ms PostgreSQL быстрее в 1,77 раза
CMP-07 JOIN с родительской таблицей 20,790 ms 12,574 ms PostgreSQL быстрее в 1,65 раза
CMP-08 UPDATE с откатом 52,568 ms 13,360 ms PostgreSQL быстрее в 3,93 раза
CMP-09 DELETE с откатом, mixed profile 3,180 ms 2,111 ms PostgreSQL быстрее в 1,51 раза
CMP-10 COPY 100M 429,087 s 100,858 s Ориентир throughput с разными durability settings
CMP-11 CREATE INDEX 132,690 s 81,595 s PostgreSQL быстрее в 1,63 раза

Результат неоднороден: RadixDB быстрее в scan, projected scan и aggregate и занимает существенно меньше места; PostgreSQL быстрее в lookup, JOIN, rollback, load и index build этого сравнения. Ни одна строка не является общей оценкой движков.

Финальная проверка выпуска не переименовывала старые числа. Она использовала performance source 12ef5963, неизменную базу 100M, один warm-up и пять измеряемых повторов в каждом из трёх заранее объявленных restart-hot runs. Runs с монотонным прогревом OS cache были отброшены до сравнения.

ID Случай Median candidate 1.1 Принятый baseline Delta
PERF-01 Aggregate 10,150 ms 9,907 ms +2,45%
PERF-02 Checksum 12,007 ms 11,638 ms +3,17%
PERF-03 Fact dictionary 572,626 ms 592,686 ms -3,38%
PERF-04 Full scan 105,224 ms 100,299 ms +4,91%
PERF-05 UPDATE rollback 42,994 ms 52,568 ms -18,21%
PERF-06 DELETE rollback 2,285 ms 3,180 ms -28,13%

Худшая указанная регрессия 4,91% осталась ниже заранее установленного коридора 1,20 раза. Все три run сохранили 100 000 000 строк, checksum 49734600639880 и access-path digest 499488e7eeca18a91a2ebb763473308e15d4e929a7c0770d933c9fd9bba084d4. Peak RSS равнялся 563 662 848, 566 497 280 и 551 399 424 байтам. Эти измерения принадлежат 12ef5963; последующие correctness hardening commits не выданы за тот же benchmark binary.

Для текущей базы исходников 1.2 повторена каноническая NVMe-проверка на 100 000 000 строк. Она сохранила checksum 100000000:49734600639880, не зафиксировала ошибок storage или resources и завершила измеряемый run за 11 870,421 ms. Cold-фаза выбора базы заняла 523,413 ms. Peak RSS составил 565,97 MiB, final RSS — 343,04 MiB, allocated database size — 1,83 GiB.

Этот run проверяет текущие исходники после изменений сервера, безопасности и надёжности 1.2. Его результаты не подставляются в прежнюю таблицу PostgreSQL: сравнение относится к другому бинарнику RadixDB и другой дате измерения.

SOAK-01 использовал 100 000 000 активных строк и лестницу 16, 32, 64, 128 и 256 клиентов. Фаза нагрузки длилась 21 600 000 ms; полный run вместе с seed и terminal evidence занял 27 427 411 ms.

ID Наблюдение Результат
SOAK-02 Операции 2 351 035
SOAK-03 Зафиксированные транзакции 98 668
SOAK-04 Проверки инвариантов / нарушения 2 100 / 0
SOAK-05 Graceful и SIGKILL reopen 2
SOAK-06 Peak server RSS 1 060 020 224 байта
SOAK-07 Final server RSS 206 327 808 байт

Run включал конкурирующую запись на диск и реальную ошибку шины ATA во время FLUSH CACHE EXT. Linux перезапустил SATA link и повторил flush. Прогресс возобновился, а финальные checkpoint, snapshot, restore и сравнение логического digest прошли. Это подтверждает наблюдавшийся путь восстановления, но не доказывает recovery при окончательной потере устройства, ложном подтверждении flush или произвольном отключении питания.

HDD намеренно был ограниченной и деградировавшей средой. Его latency и throughput не являются SLA продукта и не усредняются с результатами NVMe.

Новый публикуемый benchmark должен записывать SHA исходников, digests lockfile и бинарника, build profile, allocator, операционную систему, CPU, память, точную модель накопителя и файловую систему. Также сохраняются checksum набора, конфигурация участников, состояние cache, политика warm-up, число samples, способ агрегации и пути raw results.

Запускайте участников последовательно в изолированном benchmark root. Никогда не направляйте harness на production database. Повтор с другой durability, состоянием cache или hardware является новым результатом, а не ещё одним sample старого.

Измеренные профили памяти и footprint приведены в ограничениях, а текущие и исторические границы выпусков — в истории выпуска. Архив доказательств перечисляет все компактные отчёты и сопутствующие файлы, которые распространяются вместе с руководством.