00:00:00Когда вы запускаете новый проект и вам нужна база данных, какой вариант первым
00:00:03приходит на ум? SQLite? Скорее всего, SQLite, верно? Она отличная, надежная,
00:00:09не требует настройки и является стандартом индустрии. Но когда локальных данных становится больше,
00:00:14а запросы усложняются, мы начинаем упираться в потолок возможностей
00:00:20однопоточного движка с блокировкой файлов. Но теперь появился новый игрок,
00:00:25который пытается решить эти проблемы. Это Stulab — база данных, написанная
00:00:31полностью на Rust. У нее только что вышел нативный драйвер для Node.js,
00:00:36показывающий впечатляющую производительность. Заявлено, что эта база в 138 раз быстрее SQLite.
00:00:43В этом видео мы заглянем под капот Stulab, разберемся, как она устроена,
00:00:50и проведем живой бенчмарк-тест. Будет интересно, так что погнали! Что же такое Stulab?
00:01:00По сути, Stulab — это встраиваемая OLAP-база данных (для аналитической обработки).
00:01:06Если вы привыкли к стандартным базам вроде SQLite или Postgres, то это OLTP-системы,
00:01:14оптимизированные для транзакций. Но Stulab работает иначе.
00:01:20Она создана для аналитических нагрузок и написана с нуля на Rust для сверхбыстрой обработки данных.
00:01:27Представьте себе портативность SQLite-файла, но с аналитической мощью
00:01:33уровня DuckDB или BigQuery. И самое крутое, что теперь ее можно использовать
00:01:39в Node.js благодаря нативному драйверу. Под нативным драйвером я подразумеваю
00:01:45не просто обычную обертку. Обычно, когда база написана на другом языке,
00:01:49вашему Node.js-приложению приходится общаться с ней через своего рода мост.
00:01:56Зачастую это означает конвертацию данных в JSON или другой формат, отправку
00:02:02через сокет и обратную конвертацию. Это называется накладными расходами на сериализацию,
00:02:08и это сильно убивает скорость. Stulab Node работает иначе: он использует NAPI-RS.
00:02:15Этот фреймворк позволяет скомпилировать Rust-движок в нативный бинарный файл,
00:02:21который загружается прямо в процесс Node.js. Никаких мостов и трансляторов.
00:02:27При запросе Node.js и Rust буквально делят одну память. Есть три причины,
00:02:33почему Stulab такая быстрая. Во-первых, MVCC (многоверсионность).
00:02:40В отличие от SQLite, где одна запись блокирует всю базу, Stulab позволяет
00:02:47нескольким читателям и писателям работать одновременно. Во-вторых, параллельное выполнение.
00:02:53Stulab использует планировщик Rayon. Когда вы запускаете тяжелый запрос, он не висит
00:03:00на одном ядре, а распределяется по всем ядрам вашего процессора. И в-третьих —
00:03:06стоимостный оптимизатор. Он не просто слепо выполняет SQL, а анализирует данные,
00:03:13оценивает стоимость разных путей и выбирает кратчайший. Именно это должно делать
00:03:19Stulab намного быстрее SQLite. Но давайте проверим, так ли это на самом деле.
00:03:25Для теста мы возьмем простой проект на Node.js и установим и Stulab, и SQLite.
00:03:30Один из главных козырей Stulab — операция count distinct. Мне очень любопытно,
00:03:37так ли это. Я подготовил скрипт, который создает in-memory версию обеих баз
00:03:43и таблицу продаж. Мы заполняем ее 10 000 строк случайных данных,
00:03:49где каждая строка — это продажа пользователем с ID от 0 до 1000 в определенной категории.
00:03:56Затем мы делаем пакетную вставку в обе базы и запускаем бенчмарк,
00:04:03вычисляя количество уникальных продаж для конкретного пользователя в категории,
00:04:10сравнивая производительность. Стоит отметить один досадный момент:
00:04:16на текущий момент установка пакета через менеджер не работает. Если запустить
00:04:22тест сейчас, выпадет ошибка об отсутствии нативной привязки. Автор проекта,
00:04:28видимо, забыл добавить бинарники или правильно их линковать. Поэтому мне
00:04:34пришлось собирать всё из исходников. Я клонировал репозиторий, запустил сборку,
00:04:39вернулся в проект бенчмарка и подключил локальную директорию как зависимость.
00:04:44Сейчас это неудобно, надеюсь, авторы это исправят. Тем не менее,
00:04:49теперь мы можем запустить тест. Давайте посмотрим на результаты.
00:04:54Как видите, операция count distinct в Stulab действительно быстрее, хотя и не так,
00:05:01как заявляли. Разница всего в 4 раза. А что если добавить еще один ноль
00:05:07к количеству данных и запустить тест на миллионе строк? Давайте попробуем.
00:05:12Даже на миллионе строк Stulab быстрее лишь в 6 раз, а не в 138. Но всё равно
00:05:20результат отличный. Это был тест count distinct. Я решил провести еще один
00:05:26бенчмарк для связки distinct + order by. Во втором тесте я настроил импорт
00:05:33логов с разными IP-адресами и кодами состояния, а затем попытался найти
00:05:39уникальные пары IP и кода, отсортировав их по IP (возр.) и коду (убыв.).
00:05:47После запуска мы видим, что Stulab всё еще обходит SQLite, но уже не
00:05:53в 14 раз, а всего в 1–1.5 раза. Так что цифры в рекламе кажутся мне завышенными.
00:06:01Тем не менее, Stulab действительно быстрее, что мы и подтвердили тестами.
00:06:08Справедливости ради, автор упоминает случаи, где SQLite всё еще впереди.
00:06:13В основном это касается операций с одиночными строками. Stulab же силен
00:06:19в аналитике и сложных запросах. Можно ли назвать Stulab «убийцей SQLite»? Пожалуй, нет.
00:06:26Они созданы для разных целей. SQLite остается надежной «рабочей лошадкой»
00:06:32для транзакций, а Stulab может стать вашим «гоночным болидом» для анализа данных.
00:06:38Сам факт наличия чистого Rust-движка, который можно подключить в Node.js через
00:06:45NAPI-RS — это круто. Владельцам проекта нужно лишь поправить NPM-пакет,
00:06:50чтобы нам не приходилось собирать его вручную. Вот и весь обзор Stulab.
00:06:55А что вы думаете? Стоит ли такой прирост перехода на новую базу, или вы
00:07:01останетесь верны проверенной SQLite? Пишите в комментариях. И друзья, если
00:07:06видео было полезным, поддержите нас лайком. Также не забудьте
00:07:11подписаться на канал. С вами был Андрис из Better Stack. Увидимся
00:07:17в следующих роликах!