Технический материал всегда можно дорабатывать бесконечно, и в итоге так ничего и не опубликовать - особенно когда работа ведётся в одиночку. Поэтому прошу воспринимать эту статью как «живой» документ: она развивается, дополняется и пока ещё не завершена.

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

Быстрые переходы:

• Предыстория

• Приоритетные платформы и экосистемы

• Что такое RavenDB?

• Путь и история создателя RavenDB: от создателя до учителя

• Как личность автора отражается в архитектуре

• Путь к созданию RavenDb

• Из каких слоёв состоит RavenDB

• Движок Corax

• Движок Voron

• Движок Voron и B-Tree

• Архитектурная модель и принципы

• Производительность и оптимизация RavenDB

• Как RavenDb выполняет запросы?

• Все дороги ведут к RQL

• Индексы и интеллектуальная обработка запросов

• Почему создание статических(РУЧНЫХ) индексов ограничено

• Безопасность данных как встроенная характеристика

• Архитектура Безопасности RavenDB - Setup Wizard и простота

• Архитектура Безопасности RavenDB - Автоматическая Генерация/Ротация Let’s Encrypt сертификатов

• Архитектура Безопасности RavenDB - Сертификатная система логина

• Архитектура Безопасности RavenDB - Аудит

• Интеграции и гибридные архитектуры

• Клиентский API

• Масштабирование, шардинг и распределённость

• CAP Theoreme в RavenDB

• Репликация в RavenDb

• Как RavenDB сохраняет ACID-гарантии в распределённом кластере

• Как RavenDB избегает Rollback

• Богатый встроенный функционал

• Кэширование и конкурентность

• Система уведомлений об обновлении и патчах; Автообновления БД

• Система уведомлений о производительности и предложения её улучшения

• Применение в индустрии и масштаб реальных систем

• JetBrains Rider и тестирование производительности на проекте RavenDb

• Как проводились тесты и сравнения?

• RavenDB vs MongoDB - архитектурные различия, транзакции, индексы, производительность и эксплуатация

• RavenDB vs MongoDB - ACID как фундамент VS ACID как надстройка

• RavenDB vs MongoDB - оптимистичная модель VS многоуровневых блокировок

• RavenDB vs MongoDB - master‑to‑master VS primary-secondary

• RavenDB vs MongoDB - автоматическая адаптация VS ручной настройки

• RavenDB vs MongoDB - предвычисление VS постоянного пересчёта

• RavenDB vs MongoDB - Blittable JSON VS BSON

• RavenDB vs MongoDB - Шардинг и простота VS сложности

• RavenDB vs MongoDB - Интеграции и ETL; встроенные возможности VS сторонних решений

• RavenDB vs MongoDB - Полнотекстовый поиск; встроенный движок VS интеграции с Elastic

• RavenDB vs MongoDB - Безопасность; простота VS сложности

• RavenDB vs MongoDB - Практический опыт; Rakuten Kobo

• RavenDB vs MongoDB - Итоговое различие философий

• RavenDB vs Couchbase - архитектура, производительность и опыт Rakuten Kobo

• RavenDB vs Couchbase - что значит обслуживать десятки миллионов устройств?

• RavenDB vs Couchbase - подготовка тестового набора данных: 1.35 миллиарда документов

• RavenDB vs Couchbase - Загрузка данных

• RavenDB vs Couchbase - почему Couchbase требует терабайты?

• RavenDB vs Couchbase - производительность запросов

• RavenDB vs Couchbase - Отказоустойчивость

• RavenDB vs Couchbase - Стоимость инфраструктуры

• RavenDB vs Couchbase - Почему Rakuten Kobo выбрала RavenDB

• Итог

Идея разобрать работу баз данных появилась у меня довольно давно. Однако ближайшая мысль возникла после разговора с другом, который работал Senior‑разработчиком (де-факто техлидом) в одной крупной беттинговой компании. Параллельно он занимался своим проектом и рассказывал о нем, где самостоятельно внедрял индексацию для ускорения работы системы.

Однажды он поделился этими наработками с коллегой Senior разработчиком - и тот даже на базовом уровне не понимал, как устроены индексы. Вроде бы можно ответить просто: «используй Dictionary». Да, можно подойти к вопросу серьёзно и начать изучать реальные движки - тот же Elasticsearch, Neo4j на Java, или хотя бы посмотреть, как это делают зрелые системы, но стоял вопрос о самой простой реализации и человек ответить не смог.

Со временем я заметил, что многие мои знакомые из крупных компаний сталкиваются с тем же: глубину вещей почти никто не понимает. И часто - не потому что не хотят, а потому что это не требуется. Собеседования превратились в скрипты: выучил - прошёл. А если в реальной задаче что‑то непонятно, можно разобраться по ходу дела и в этом нет ничего плохого, однако до боли забавно.

Все пересказывают одни и те же заученные ответы. А особо щепетильные интервьюеры придумывают искусственные проблемы и ждут, что кандидат угадает их внутреннее решение - чтобы найти «того, кто мыслит так же». Ничего нового, и уж точно ничего вдохновляющего. P.S: это подводка к моей ранее опубликованной статье.

Чет от о всех и везде Клоунада

И вот на фоне всех этих разговоров у меня возник вопрос: неужели на такой мощной платформе, как C# и .NET, нет собственной базы данных?

Оказалось - есть. И имя ей RavenDB.

С этого момента у меня появилась цель: написать материал о RavenDB, но постоянно сталкивался с дилеммой - одна большая статья получается слишком тяжёлой, а серия статей рискует превратиться в бесконечное дописывание.

Полного объёма материала я пока не собрал, но уже успел неплохо разобраться в этой базе данных. Чтобы двигаться дальше, я заранее публикую свои заметки(может таким образом появятся люди, что тоже начнут делиться своим опытом) - и они будут постепенно расширяться. RavenDB мне действительно понравилась: работать с ней интересно, а возможности впечатляют. Я хотел бы видеть её чаще в production‑средах, особенно в Российских компаниях, где она могла бы занять достойное место среди современных решений для хранения данных. С полной уверенностью могу сказать: эта база данных прочно вошла в мой кругозор и я не собираюсь выпускать её из поля внимания. Сам создатель и его детище RavenDB настолько запали мне в душу, что стали для меня не просто инструментом, а настоящим источником вдохновения

Oren Eini, что создал RavenDb, уже много лет ведёт свой блог на собственном портале ayende.com - это его личная площадка, где он документирует технические идеи, эксперименты, архитектурные решения и собственный профессиональный путь. Мой рассказ о нём во многом основан именно на его статьях, опубликованных на этом сайте: они дают редкую возможность увидеть, как он мыслит и какие инженерные принципы считает важными.

Этот раздел стоит начать с главного наблюдения: наиболее глубоко и полно в RavenDB реализована поддержка C# и платформы .NET. Под «полной поддержкой» здесь подразумевается не просто наличие официального клиента, но и максимальная функциональность, обширность примеров, объём обучающих материалов и детальность документации. И это логично, учитывая историю и технологический стек самой базы.

Если открыть официальную документацию RavenDB и пройтись по её разделам, легко заметить базовый фундамент экосистемы - это C#, Java и Node.js. Именно для этой тройки приведено наибольшее количество примеров, демонстраций API, архитектурных рекомендаций и практических сценариев.

Следом за ними идут Python и PHP: они также имеют официальные SDK и регулярно встречаются в материалах базы знаний.

Опираемся на хождение по документации

Этот приоритет легко считывается по структуре контента, даже если вы не работаете с Java, Node.js, Python, C++, GO или PHP напрямую.

Подтверждение этому вычисляется и по новостям компании: например, в статье от 27 июля 2026 года команда прямо говорит о развитии и поиске специалистов под подобные клиенты, что полностью совпадает с картиной в документации. Приоритетное внимание к этим платформам логично: именно они формируют целевую аудиторию RavenDB и генерируют основной поток коммерческих лицензий.

А вот готовые примеры для Go, Ruby, C++ или R в официальной документации найти уже практически невозможно. Судя по объёму документации и примеров, поддержка этих экосистем либо находится на базовом уровне, либо в значительной степени опирается на решения сообщества.

Однако, если опираться на материал опубликованной статьи, можно заметить, что в “первый тир” поддержки сегодня фактически попадают Go и C++

RavenDb

RavenDB - это высокопроизводительная документно-ориентированная/многомодельная NoSQL‑база данных с открытым исходным кодом, созданная как распределённая платформа для обработки онлайн‑транзакций, хоть и основное предназначение быть документной-ориентированной. Cпециализирующая на обработке онлайн-транзакций (OLTP). С момента своего первого запуска в 2009 году система полностью основана на транзакциях (ACID, а не BASE). С самого начала RavenDB была задумана как система, где целостность данных и надёжность транзакций являются не дополнительной опцией, а фундаментом архитектуры.

RavenDB используется для хранения критически важных бизнес‑данных, таких как медицинская информация и финансовые транзакции

Одним из сильных сторон RavenDB является её отсутствие жёсткой схемы - и это касается не только хранения данных. RavenDB обладает мощными возможностями для работы с динамическими данными и пользовательским контентом.

Если вы когда-либо работали с MongoDb - то RavenDb вам покажется очень удобным и знакомым по методике работы. Те же коллекции, документы, базовый метод моделирования в том числе строится вокруг корневых агрегатов.

Поскольку RavenDB написана на C#, её документация и примеры в первую очередь ориентированы на разработчиков, работающих с C# и .NET. Это делает изучение внутреннего устройства базы особенно увлекательным: вы не только сможете глубже понять, как она устроена, но и получите удовольствие от её использования в повседневных бизнес‑задачах. Работа с RavenDB ощущается естественно и органично для экосистемы .NET, что превращает её применение в практичное и приятное занятие.

C#

Если вы хотите познакомиться с RavenDB без установки и настройки, можно открыть живую демонстрационную версию, развёрнутую самими разработчиками - полноценный интерфейс RavenDB Studio, доступный прямо в браузере.

UI RavenDb

Хотите почитать книгу? Держите

RavenDb Inside

Хотите почитать документацию? Держите

Хотите изучить, как выглядит интегрированная RavenDb в приложение? Смотрите примеры

Просматривая интервью - я неожиданно узнал, что RavenDB весьма популярна в Америке: как в Северной, так и в Южной. Об этом прямо говорит её создатель, Oren (Oli) Eini. В Европе и Азии она тоже встречается, пусть и не так массово. Причём используется RavenDB давно и в самых разных сферах - включая банковский сектор.

Если посмотреть рейтинг на DB‑Engines, RavenDB находится примерно на 100‑м месте. И это действительно впечатляет, учитывая, что в списке более 400 систем управления базами данных. Для продукта, который не является массовым, но ориентирован на сложные корпоративные задачи, это очень достойная позиция. RavenDB предлагает богатые возможности, зрелую архитектуру и вполне конкурентные преимущества - ей есть что предложить разработчикам и бизнесу.

RavenDb в DbEngines

Сам Oren Eini - человек с необычной биографией. В его профессиональном пути были не только годы работы программистом, но и совершенно неожиданные профессии, например служба в тюремной системе. Программированием он увлёкся давно, знает множество языков и всегда стремился разбираться в технологиях глубже, чем большинство.

Oren Eini

И важно начать с того, что RavenDB была далеко не его первым проектом. До неё он был активным контрибьютором в NHibernate - одном из самых известных ORM в .NET‑мире. Кроме того, он создал целую линейку инструментов под брендом Rhino. Например:

NHibernate

• Rhino Mocks - один из первых фреймворков для моков в .NET, появившийся задолго до Moq и NSubstitute.

• Rhino Service Bus - лёгкая шина сообщений для распределённых систем, созданная до массового распространения MassTransit и NServiceBus.

• RaccoonBlog - собственная платформа для его блога Ayende, которая служила живым примером использования RavenDB.

И это лишь часть его проектов - многие из них стали фундаментом, на котором позже выросла RavenDB.

Если в наших краях RavenDB пока не получила широкой известности и о самом Oren Eini знают немногие, то в других частях света его экспертиза ценится настолько, что его просят рецензировать книги . Один из примеров - просьба оценить книгу и он написал рецензию на данную просьбу: Review: Getting Started with LevelDB.

Getting Started with LevelDB

Oren Eini - не просто создатель базы данных, он активно делится своим опытом и показывает, как устроены БД изнутри. На GitHub у него есть полноценная книга‑проект, где он шаг за шагом обучает созданию собственной базы данных на языке C.

Этот проект называется libgavran - и в нём вы буквально создаёте минималистичную БД с поддержкой WAL, транзакций, страничного хранения и других фундаментальных механизмов. Это не просто учебник: это практическая мастерская, где каждая глава - новый слой реального сторедж‑движка.

libgavran project-book

Особенно интересно то, что многие идеи в книге выросли из его более ранних статей о внутреннем устройстве БД. Поэтому, читая libgavran, можно увидеть знакомые концепции, которые он подробно разбирал в своём блоге - от структуры страниц до реализации журналирования.

Статьи на Ayende

🔗 Репозиторий для тех, кто хочет понять, как работает движок хранения, это один из лучших практических ресурсов.

Так же в своей книге о RavenDb, Oli Eini четко подчеркивает, что все же впервую очередь в душе он остается разработчиком. Он прекрасно понимает все проблемы таких ребят, как мы дорогие читатели.

Если внимательно читать его материалы, становится очевидно: Oren - сторонник чистого объектно‑ориентированного кода и последовательный противник триггеров и хранимых процедур. В нескольких статьях он прямо называет подобные конструкции “evil code”, подчёркивая, насколько неприятно ему работать с логикой, спрятанной внутри базы данных. Это хорошо видно в его постах

• “My first trigger”

• “Triggers & auditing – take 2”

• “NoSQL, meh”

Красота даже в самом репозитории

Из книги о RavenDB мы узнаём, что Oren Eini, пришедший из мира, ориентированного на Microsoft, начал написание книги о RavenDb ещё в 2014 году и многократно переписывал её.

Первоначальная цель в разработке RavenDb заключалась в создании системы, которая сочетала бы ACID‑гарантии с отсутствием жёстких ограничений реляционных схем, но при этом сохраняла привычные модели работы с данными.

Создателю хотелось получить решение, которое будет одновременно быстрым, простым в установке на production‑сервер и способным работать круглосуточно без необходимости оплачивать постоянное сопровождение.

На дизайн RavenDB сильное влияние оказала книга Release It!, которую Oren Eini настоятельно рекомендует - именно она помогла сформировать подход к надёжности и устойчивости системы.

Release It!

Эти взгляды позже напрямую повлияли на архитектуру RavenDB, где он сознательно отказался от скрытой серверной логики в пользу прозрачных механизмов - патчей, ETL и подписок.

В видео‑интервью c Rodrigo Branas создатель RavenDB Oren Eini рассказывает, сколько времени команда вложила в создание качественного пользовательского интерфейса. По его словам, работа над UI заняла годы - и это заметно: интерфейс RavenDB действительно один из лучших, что мне доводилось видеть среди баз данных.

UI RavenDb

Причина проста: Oren Eini ставит удобство разработчика в центр всей философии RavenDB. Он много раз писал, что если у базы данных нет хороших инструментов, то она останется нишевой и неудобной. В одной из статей он критикует SQL Management Studio за перегруженность и неудобство - “SQL Management Studio”. И это хорошо объясняет, почему RavenDB получила современный, продуманный UI, который снижает порог входа и делает работу с документной БД интуитивной.

UI Sql Management Studio

Говоря о том, как Oren Eini относится к конкурентам, то здесь заметен не фанатизм и не попытка «топить» другие технологии, а вполне здравый, инженерный подход. Например, есть статья, которая на первый взгляд выглядит как критика MongoDB, но внутри оказывается совсем другим - это попытка защитить саму идею документной модели и показать, как люди неправильно используют NoSQL‑базы. Речь о статье

• Why You Should Never Use MongoDB

В ней он объясняет, что проблема не в MongoDB как продукте, а в том, что разработчики не умеют применять её. То есть он критикует не конкурента, а неправильные архитектурные решения.

Бестолковость

Такой же подход заметен и в интервью с Rodrigo Bananas: Oren прямо говорит, что уважает создателей PostgreSQL. Это важный момент - он не противопоставляет RavenDB другим базам, не пытается доказать, что «его БД лучше всех». Он подчёркивает, что разные системы решают разные задачи, и уважение к чужой работе - часть профессиональной культуры.

Уважение

Вдохновение на создание собственной БД он черпал из CouchDB, что не скрывается и открыто видно в его статье

• Designing a document database В статье поднимается список архитектурных вопросов, которые нужно решить при создании документной базы данных; он показывает, что простая идея документного хранилища скрывает множество сложных инженерных решений.

CouchDb

Интересно, что RavenDB изначально имела другое название и начиналась как экспериментальный проект DivanDB. Ранние прототипы создавались на разных языках (точной информации нет), а в качестве движка хранения использовался ESENT. Именно DivanDB стал отправной точкой, на которой Oren Eini проверял идеи документной модели, прежде чем они эволюционировали в RavenDB.

ESENT (Extensible Storage Engine) - это встроенный в Windows низкоуровневый транзакционный сторедж‑движок, который Microsoft использует во множестве систем: Active Directory, Windows Search, Exchange, Windows Update и других.

Если коротко: ESENT - это полноценная ACID‑база данных уровня key‑value/record‑store, встроенная прямо в Windows.

Designing A Document Database Storage

Hidden Windows Gems Extensible Storage Engine

ESENT Engine

Этот движок использовался в RavenDB довольно долго, пока проект не дорос до момента, когда ESENT перестал удовлетворять требованиям. Потребовалась кроссплатформенность, возможность глубокой модификации, масштабирование и более высокая производительность - а такие задачи невозможно решить, оставаясь внутри ограничений чужого движка. Логичным шагом стало создание собственного сторедж‑движка, и так появился Voron.

Voron Engine

На дворе 2009-2010 года. Oren Eini выбрал C# не случайно: ему нужна была высокая скорость разработки, современная экосистема и удобный язык, который позволяет быстро строить сложные системы. При этом он неоднократно писал, что продукты Microsoft ему не всегда нравились, а решения Oracle вызывали у него откровенное раздражение. На фоне всех доступных вариантов C# оказался наименее проблемным и наиболее продуктивным выбором, сочетая мощь платформы .NET с комфортом разработки.

Собственного текстового поискового движка Corax тогда ещё не существовало, поэтому на ранних этапах было принято практичное решение - интегрировать Lucene.NET в качестве индексатора

Apache Lucene .NET Logo

Если открыть исходный код RavenDB, можно увидеть девять ключевых слоёв, из которых состоит вся система:

SRC проекта RavenDb

1. Corax - исходный код нового поискового движка Corax, который RavenDB разработала как замену Lucene.

2. Raven.Client - это клиентская библиотека RavenDB, которая позволяет .NET‑приложению подключаться к серверу RavenDB, выполнять запросы, работать с документами, индексами, патчингом, потоками, операциями и всем API базы данных.

3. Raven.Embedded - встроенная (embedded) версия RavenDb, предназначенная для запуска RavenDB внутри вашего приложения, без отдельного сервера, без установки, без сети и без администрирования. Raven.Embedded удобен для WPF, Avalonia и тд тому подобное.

4. Raven.PAL - это Platform Abstraction Layer RavenDb. Он нужен, чтоб RavenDb могла работать кросплатформенно с Windows, Linux, MacOS. Там описана работа с файловой системой и инструментами OC, чтобы БД корректно отрабатывала везде. Используется язык “C” в нем и через [DllImport] импортируются функции в язык “C#” в разных слоях приложения.

5. Raven.Server - это основной сервер RavenDB, то есть полноценная серверная СУБД. Принимает запросы от клиентов, обрабатывает их и тд.

6. Raven.Studio - веб‑интерфейс администрирования RavenDB, написанный на React. Позволяет управлять базой данных визуально.

7. Sparrow - содержит базовые структуры данных, низкоуровневые оптимизации(SPAN, Memory, SIMD, Hashing), парсеры, сериализаторы. Их использует RavenDb для работы и в особенности они используются в Corax/Voron. Это фундамент.

8. Sparrow.Server - серверное расширение Sparrow, содержащее утилиты и примитивы, которые нужны именно Raven.Server для выполнения тяжёлых системных операций, как пример подойдут криптографические примитивы.

9. Voron - собственный движок хранения данных. Он отвечает за все, что связано с физическим хранением данных на диске, управления страницами, журналированием, транзакционностью и durabillity.

Зависимость проектов RavenDb, сделано через NDepend

Зависимость проектов RavenDb, сделано через NDepend

По сути, часть внутренних слоёв RavenDB названа в едином стиле - в честь птиц, что создаёт собственную “орнитологическую” экосистему имен:

1. Corax - латинское название рода врановых.

2. Sparrow - воробей.

3. Raven - ворон по‑английски.

Такая архитектура выбрана не случайна и имеет объяснение. Чтоб лучше понять эти слои я вам настоятельно рекомендую почитать его книгу по созданию БД, ведь она нацелена на практическое понимание осуществляемых работ Базы данных. Вконце-концов она не большая.

В качестве небольшого примера я сделаю отсылку на книгу.

Corax - это внутренний компонент RavenDB. Он не поставляется отдельно, не имеет собственного логотипа, бренда, сайта

Если вы когда‑то работали с Lucene, то появление Corax не должно сбивать вас с толку - базовые принципы у этих движков очень похожи. Я не собираюсь глубоко погружаться во внутренности Corax, но хочу объяснить фундаментальные вещи, чтобы вы понимали, как он работает и почему он появился.

И прежде чем говорить о Corax, нужно разобраться с вопросом: что такое Lucene?
Lucene - это поисковый движок для работы с текстом. Его верхнеуровневый принцип работы достаточно прост, и лучше всего он раскрывается на примере Elasticsearch, который построен поверх Lucene и демонстрирует весь его потенциал. Да, Lucene используется и в других системах - например, в Neo4j, но именно Elasticsearch показывает, насколько мощным может быть движок, когда вокруг него выстроена специализированная архитектура.

Lucene - это официальный проект Apache Software Foundation, распространяемый под лицензией Apache 2.0.

Логотип Apache Lucene

Lucene и Corax используют принцип Pipeline - он фундаментален для всех движков полнотекстового поиска. В процессе работы активизируется цепочка фильтров, где каждый шаг преобразует текст в более структурированную форму, пока он не станет частью inverted index.

1 Токенизация - первый шаг т.е задача тут превратить строку текста в последовательность токенов.

Пример: "Corax is a fast search engine"
Результат: ["Corax", "is", "a", "fast", "search", "engine"]
Токенизация не просто split по пробелам, она включает: 
удаление пунктуации, выделение чисел, выделение 
составных слов и тд.

2 Анализаторы - нормализация, фильтры, стемминг

После токенизации токены проходят через цепочку анализаторов.
Примером нормализации могут служить:
[1] приведение к нижнему регистру, допустим "Hello" -> "hello"
[2] Стемминг т.е приведение слова к основе(корню), допустим: "running" -> "run"
[3] Удаление часто встречающихся слов: the, a, an, is, on, at, of

3 Построения термов - превращение токенов в термы.

После анализа токены становятся термами - нормализованными единицами поиска.
Пример: "Corax is a faster engine than Lucene"
Результат: ["corax", "fast", "engine", "lucene"]

4 Формирование постинг‑листов - связь термов с документами

Постинг‑лист - это структура вида:
term → [docId1, docId7, docId42, ...]

5 Запись в Inverted Index - финальная структура поиска.

Inverted index - это структура term -> posting list
Пример:
"corax" → [docId 1, docId 5]
"engine" → [docId 1, docId 7, docId 42]
"fast" → [docId 1, docId 9]
"lucene" → [docId 1, docId 42]

Работа Apache Lucene

В отличие от Lucene, который вычисляет и хранит структуры данных в памяти, Corax хранит их на диске. В результате Corax использует значительно меньше памяти и устраняет длительное время выполнения «холодных» запросов.

Voron не является самостоятельным продуктом. Он полностью интегрирован в RavenDB и существует только как её внутренний движок хранения.

Voron Engine

Как отмечает Oli Eini, создание движка хранения данных - одна из самых простых частей в разработке СУБД. Если вы понимаете, как работает B‑Tree, то вы уже знаете 60-70% того, как устроена база данных. Алгоритм B‑Tree был описан ещё в 1970‑х, и с тех пор его фундаментальные свойства остаются неизменными.

B-Tree

Но настоящая сложность базы данных - не в хранении, а в том, как она используется. Эини подчёркивает, что ключевыми качествами хорошей БД являются:

• удобные инструменты,

• прозрачное использование,

• минимизация когнитивной нагрузки на разработчика,

• и главное - создание ценности для бизнеса, а не необходимость разбираться в том, как работает система внутри.

Именно поэтому движок хранения - лишь фундамент. Настоящая инженерная сложность начинается там, где база данных должна быть удобной, предсказуемой, надёжной и простой в использовании.

При этом B‑Tree остаётся невероятно мощной структурой: она позволяет эффективно работать с сотнями и тысячами терабайт данных, обеспечивая логарифмическое время доступа и устойчивость к росту объёма данных.

Сам Voron имеет 250 .cs файлов и 68_000 строк кода т.е изучить его на первый взгляд не сложно. Однако… Создание движка хранения на “C” и “C#” не одно и тоже.

У Орена Эини действительно была экспериментальная архитектура Naver - небольшой учебный сторедж‑движок, который он писал в блоге, пытаясь воспроизвести идеи LMDB в C#. Первоначально он рассматривал Naver как возможную основу для будущего движка хранения RavenDB, но довольно быстро стало ясно, что это лишь экспериментальная площадка, а не реальный кандидат на продакшен‑использование.

Подробной документации по Naver нет: это не продукт, а серия блог‑постов, где Орен исследовал низкоуровневые техники работы с памятью, layout страниц, указатели, B‑Tree и MVCC. Однако именно в этих экспериментах он столкнулся с тем, насколько непросто реализовать низкоуровневое управление страницами в C#, особенно если пытаться повторить модель LMDB, где всё основано на прямом доступе к памяти через mmap.

В итоге многие идеи из Naver - такие как memory‑mapped доступ, работа со страницами, copy‑on‑write и структура B‑Tree - действительно легли в основу Voron, но сам Naver в RavenDB не используется. Это был шаг на пути к созданию полноценного движка хранения.

LMDB - минималистичный, транзакционный, memory‑mapped движок хранения, построенный на B‑Tree и MVCC. Он невероятно быстрый и надёжный, и стал архитектурным вдохновением для Voron в RavenDB.

Движки хранения

Орен подробно описывает этот переход в статье: Voron’s implementation: Managed memory mapped database–getting to C memory model

Встроенный движок хранения RavenDB Voron - был создан специально для повышения производительности при росте конкурентности. Он использует архитектуру MVCC, чтобы писатели не блокировали читателей и наоборот. При конкурентных записях RavenDB может объединять несколько параллельных операций в одну дисковую операцию, значительно снижая затраты на I/O и существенно повышая производительность. RavenDB была ACID‑совместимой по умолчанию с самого начала - целостность данных всегда была ключевой ценностью RavenDB.

MVCC

Для чтения RavenDB масштабируется прямо пропорционально количеству узлов в системе, поскольку нет необходимости в блокировках или других механизмах управления конкурентностью, которые тратят ресурсы.

RavenDB использует технологию Write Ahead Log и MVCC для обеспечения полной ACID‑защиты. Она хранит дублирующиеся версии изменённых данных только до тех пор, пока существуют активные транзакции, которым может понадобиться доступ к старым данным. Как только такие транзакции завершаются, пространство, занимаемое старыми значениями, может быть немедленно перераспределено. Нет необходимости в VACUUM или постоянном обслуживании. Объём пространства, используемого под метаданные, минимален и обеспечивает хороший баланс между производительностью и использованием диска.

Voron поддерживает только один процесс записи (но может быть несколько процессов чтения). Наличие всего одной транзакции записи упрощает обработку операций записи.

Для достижения высокой производительности RavenDB использует слияние транзакций поверх модели единой записи Voron. Такой подход обеспечивает значительное повышение производительности, особенно в условиях высокой нагрузки.

Кроме того, Voron поддерживает асинхронную фиксацию транзакций.

Из Документации Voron

Ссылка

Начиная с RavenDB 4.0, Voron не имеет ограничений при работе в 32-битном режиме.

Именно сочетание нового storage engine и переработанной системы индексации стало одной из ключевых причин существенного прироста производительности RavenDB 4.0 - и всё это произошло ещё до появления собственного поискового движка Corax.

Write Ahead Log

Как ранее выражался Oren Eini: если вы знаете, как работает алгоритм B-Tree, то уже на 60-70% понимаете, как устроена база данных. И, судя по устройству Voron, это утверждение действительно недалеко от истины.

В основе storage engine Voron лежит дерево как фундаментальная структура организации данных. Это хорошо видно даже при изучении тестов: практически повсюду встречается вызов CreateTree() - то есть создание дерева.

FastTests

Более того, дерево непосредственно встроено в модель работы транзакций Voron: транзакция получает доступ к дереву, выполняет через него операции чтения и записи, а затем фиксирует внесённые изменения через Commit().

SlowTests

Тесты Voron условно разделены на два основных класса:

• FastTests - выполняются очень быстро, обычно за миллисекунды. Они проверяют базовую корректность и поведение структур данных, не работают с большими объёмами данных и не ориентированы на измерение производительности.

• SlowTests - выполняются значительно дольше, иногда секунды или минуты. Они используют большие объёмы данных, проверяют более сложные сценарии и позволяют обнаруживать редкие ошибки, которые могут не проявляться в быстрых тестах.

И что особенно показательно - CreateTree() постоянно встречается и в FastTests, и в SlowTests. То есть дерево является не каким-то отдельным механизмом, используемым лишь в нескольких подсистемах, а базовым примитивом, вокруг которого построено большое количество логики Voron.

Дебаг теста

Поэтому, если смотреть на Voron через его исходный код и тесты, вполне можно сделать вывод:

• «B-Tree является одним из краеугольных камней архитектуры Voron и фундаментальной структурой, на которой построена значительная часть его persistent storage. При этом Voron не сводится исключительно к B-Tree: вокруг деревьев существуют механизмы управления страницами, транзакций, MVCC, journal, scratch space и Raw Data Section. Но именно дерево выступает одним из главных строительных блоков всего storage engine»

Важно не путать пользовательские индексы с внутренними индексами Voron. Последние используются самим storage engine для базовых операций, например поиска документов по ID, и поддерживаются транзакционно вместе с данными. Пользователь ими не управляет.

Пользовательские индексы работают иначе: они обновляются асинхронно и хранятся в Voron, что обеспечивает их надёжность и восстановление после сбоев.

В основе RavenDB лежит архитектура, ориентированная на устойчивость, предсказуемость и отсутствие простоев. Мульти‑мастер‑кластер позволяет каждому узлу принимать записи и реплицировать их другим узлам, обеспечивая непрерывную работу даже при отказе части инфраструктуры. В документе это сформулировано так: «постоянный нулевой простой для клиентов, даже если один из серверов выходит из строя, благодаря высокой доступности в мульти-мастер‑кластере».

Multi Master System

Транзакции в RavenDB работают как внутри одного узла, так и между узлами кластера. Это означает, что изменения нескольких документов могут быть выполнены в одной транзакции, и RavenDB гарантирует, что они либо полностью попадут на диск, либо будут полностью откатаны. Более строгий режим - кластерные транзакции, использует консенсус Raft, обеспечивая повышенную согласованность, хотя и с большей задержкой. Стандартный режим транзакций выполняется на предпочтительном узле, после чего изменения асинхронно и атомарно реплицируются на остальные узлы группы.

Системы RavenDB основаны на кооперативном взаимодействии клиентов и серверов. Сбой сервера не вызывает никаких специальных действий в кластере - клиенты уже знают список узлов‑преемников и немедленно переключаются на следующий сервер. Временные ошибки просто перенаправляют трафик на другие узлы, и конечное приложение не замечает ничего, кроме нескольких запросов, которые могут быть немного медленнее обычного.

За кулисами RavenDB отслеживает состояние узла и его восстановление. Опыт показывает, что полная потеря узла - редкость, поэтому RavenDB по умолчанию стремится обеспечить живучесть системы и дождаться возвращения узла.

RAFT

Сбой узла RavenDB не рассматривается как приоритетная операция, что позволяет DevOps бесшовно выполнять поочерёдные обновления узлов. Обновление кластера - рутинная операция, где узлы отключаются по одному, чтобы команды DevOps могли выполнить обслуживание, а затем вернуть узел в кластер.

RavenDB ожидает, что узлы будут выходить из строя, и обрабатывает это спокойно и прозрачно. Превращая сбой узла в «не‑событие», RavenDB даёт операционным командам возможность рассматривать узлы как горячие резервные. Вы можете отключить узел в любой момент, по любой причине, и ничего серьёзного не произойдёт.

RavenDB демонстрирует выдающуюся производительность «из коробки». В документе приводится показатель: «150K записей / 1M чтений в секунду на обычном железе». Это достигается благодаря сочетанию нескольких ключевых технологий.

Источник

Первая - нативный формат хранения Blittable JSON. Он был создан специально для RavenDB, чтобы минимизировать накладные расходы на обработку документов. Blittable позволяет RavenDB не десериализовать JSON‑объекты при чтении из постоянного хранилища, что экономит огромное количество памяти и CPU. В книге сказано: «Blittable может обрабатывать данные без полного парсинга документа в объектную форму, что значительно снижает стоимость большинства операций».

Вторая - использование страничного кеша операционной системы вместо собственных подсистем кеширования. RavenDB обращается к документам так, чтобы максимально эффективно использовать поведение ядра ОС, которое лучше знает состояние всей системы. Это делает RavenDB «командным игроком», который делит ресурсы системы, а не конкурирует за них.

Третья - само‑оптимизация. RavenDB адаптируется под нагрузку и характеристики оборудования, автоматически выбирая оптимальные стратегии выполнения запросов, обновления индексов и распределения данных.

Само-оптимизация

RavenDB подходит для работы на маломощных устройствах. На сайте приводится показатель: «около 20K запросов/сек на Raspberry Pi или ARM64». Это делает RavenDB подходящей для IoT‑систем, распределённых сенсорных сетей и автономных устройств.

Rasberry PI

Когда запрос поступает в RavenDB, его анализирует Query Optimizer, который определяет, какой индекс использовать. На этот случай есть 2 варианта:

• Динамический запрос т.е RavenDb самостоятельно подберет или создаст подходящий индекс.

from Orders where .....

• Запрос с указанием индекса т.е мы сами должны передать название индекса

from index "Orders/ByCompany" where ...

Источник

В отличие от SQL, где порядок написания запроса существенно отличается от логического порядка его обработки, RQL RavenDB намеренно построен таким образом, чтобы порядок операторов в запросе хорошо соответствовал логике его выполнения.

RQL - декларативный язык поверх индексов, и RavenDB стремится к тому, чтобы структура запроса отражала реальный pipeline.

SQL - реляционный язык, где фактический порядок выполнения (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY) отличается от того, как это пишется.

Источник

Ключевая особенность RavenDB: каждый запрос выполняется через индекс. Полного сканирования коллекции т.е full scan нет.

Индексирование выполняется в фоне, а запрос, которому требуется новый индекс, может дождаться его построения. При этом запросы, для которых уже существуют подходящие индексы, продолжают выполняться независимо.

После появления нового индекса RavenDB также может удалить ставшие ненужными старые индексы.

В традиционных составных индексах порядок полей имеет большое значение - в RavenDB нет. Поля индексируются независимо, поэтому один индекс может обслуживать разные комбинации условий, а RavenDB объединяет необходимые результаты при выполнении запроса.

Для числовых полей RavenDB также хранит разные представления значения - например, string, double и int64, что позволяет выполнять запросы с различными типами сравнения без необходимости вручную проектировать отдельные индексы.

Источник

Query Optimizer старается использовать уже существующие индексы, избегая создания новых без необходимости.

RavenDB по умолчанию использует асинхронную индексацию, сознательно отделяя запись документов от работы индексов.

Запись не блокируется ожиданием обновления индексов, а запросы не обязаны ждать завершения индексирования. Индексы работают независимо и обновляются в фоне. Это позволяет уменьшить конкуренцию за ресурсы и повысить производительность системы, особенно при высокой нагрузке на запись.

RavenDB по умолчанию не гарантирует, что запрос увидит самые свежие данные в индексе - потому что индексы обновляются асинхронно. Но если приложению нужна строгая согласованность, оно может явно потребовать дождаться обновления индекса.

Иными словами, RavenDB предлагает выбирать компромисс между скоростью и свежестью индексированных данных, вместо того чтобы платить максимальную стоимость синхронности для каждого запроса и каждой записи.

Изучая документацию и книгу по RavenDB, вы увидите, что для работы с запросами предусмотрены три уровня абстракции:

• LINQ/Query - высокоуровневый API со строгой типизацией и поддержкой IntelliSense.

• DocumentQuery - более гибкий низкоуровневый Fluent API для программного конструирования запросов.

• RQL (Raven Query Language) - декларативный язык запросов (похожий на SQL), дающий прямой контроль над тем, что отправляется серверу.

Все три подхода в конечном счете транслируются в RQL и выполняются на стороне сервера. Это позволяет при необходимости легко «спуститься» с LINQ/Query до DocumentQuery или выполнить запрос на RQL напрямую.

Разработчики RavenDB придерживаются этой концепции впринципе во всех клиентских SDK. Высокоуровневый слой называется LINQ в C# (в силу особенностей платформы .NET) и Query в SDK для других языков. Нижестоящие уровни - DocumentQuery и RQL остаются неизменными везде.

Документация

Подход LINQ/Query построен поверх DocumentQuery, а DocumentQuery преобразуется в RQL-запрос, который и отправляется на сервер. Все эти уровни созданы для того, чтобы упростить повседневную разработку, но при этом дать вам инструмент для решения сложных и нестандартных задач.

Книга

Практический совет, который могу дать звучит так:

1. Начинайте всегда с LINQ/Query - это быстро, безопасно и покрывает 90% задач.

2. Если интерфейс требует конструктор фильтров, где условия собираются на лету - переключайтесь на DocumentQuery.

3. LINQ запрос или Document Query превращается в нечитаемую кашу из трюков с типами, либо нужна сложная проекция/агрегация с вычислениями - пишите RQL напрямую.

Oren Eini здесь отвечает, что в целом они имеют ± одну стоимость работы. От того, что вы напишите это “чисто” вряд-ли повлияет на итоговую работу.

Ответ Орена

Если вы боитесь и переживаете касаемо правильности своего RQL запроса, то можете вначале его проверить в RavenDB Studio, она имеет просто прекрасный RQL Code Assistant.

За счет предоставления контекстно-зависимого автозавершения и проверки синтаксиса в реальном времени.

Во время ввода запроса в Studio функция RQL Code Assistance будет выполнять следующие действия:

• Предусмотрение автозаполнения (Ctrl+Space) для коллекций, полей документов, индексов, функций, ключевых слов и операторов, относящихся к текущему контексту запроса.

• По мере написания запроса обновляет предлагаемые варианты, отображая допустимые значения для следующей части.

• Постоянно проверяет синтаксис и выделяет ошибки с помощью предупреждающих значков и подробных сообщений при наведении курсора.

Пример 1

Пример 2

Пример 3

Все запросы в RavenDB выполняются через интеллектуальные индексы. Когда поступает запрос, оптимизатор определяет, можно ли ответить на него с помощью существующего индекса, и при необходимости модифицирует и оптимизирует определение индекса на лету. Если подходящего индекса нет, RavenDB автоматически создаёт его. Если индекс не используется, RavenDB удаляет его через определённое время: «30 минут до idle, 72 часа до удаления».

Авто‑индексы RavenDB обучаются на поведении запросов и адаптируются под реальные сценарии использования. Это освобождает разработчиков и администраторов от необходимости вручную проектировать индексы для каждого возможного случая. Когда индекс создан, RavenDB использует предварительно вычисленные результаты, что снижает время выполнения запросов более чем на 99,9%.

Индексы

Для агрегирующих запросов RavenDB создаёт авто‑индексы агрегирования. Поскольку агрегирование является нативной частью RavenDB, разработчикам не нужно поддерживать сторонние компоненты для выполнения агрегатов - RavenDB делает это автоматически, за кулисами, обеспечивая свежие данные в запросах.

Разработчики могут создавать статические индексы, которые выполняют сложные вычисления над данными при каждом их изменении. Такие индексы особенно полезны для AI/ML‑моделей и тяжёлых агрегатов. В отличие от авто‑индексов, статические индексы не удаляются автоматически. RavenDB предоставляет механизм Index Cleanup, который анализирует использование индексов и предлагает объединить или удалить те, что не нужны.

Indexing Perfomance

Обновление индексов происходит вне транзакции обновления документа, что делает операции записи значительно быстрее. RavenDB также объединяет несколько изменений в одну операцию обновления индекса, снижая нагрузку на систему. Параллельные запросы могут либо читать текущее состояние индекса, либо ждать его актуализации - это позволяет балансировать между скоростью и точностью.

В RavenDb хорошо поддерживаются пространственные(на основе географических данных) запросы. Так же можно находить документы не по их собственным данным, а по данным связанных документов.

В RavenDB предусмотрено несколько уровней доступа, однако на практике чаще всего используются два: Database Admin и Read/Write.

Ограничение на создание статических (ручных) индексов для пользователей с правами Read/Write продиктовано требованиями безопасности. Проблема заключается не в самом индексе, а в коде, который выполняется при его построении. Статический индекс позволяет задать логику, которую сервер RavenDB будет исполнять в процессе индексации документов.

Следовательно, если разрешить обычному пользователю создавать статические индексы, он фактически получит возможность запускать произвольный серверный код с завышенным уровнем привилегий. Именно поэтому право на создание таких индексов есть только у пользователей с ролью Database Admin.

Дока

Важно: Пользователь с уровнем доступа Read/Write может свободно выполнять запросы и использовать уже существующие индексы, но лишен права создавать новые статические индексы вручную.

В большинстве случаев вам не придется задумываться о ручном создании статических индексов, поскольку в RavenDB встроена мощная система автоматической индексации, которая берет эту работу на себя.

Когда вам понадобятся именно таки РУЧНЫЕ индексы(ПРИМЕР):

• Сложные агрегации (Map-Reduce)

• Полнотекстовый поиск (Full-Text Search) - гибкая настройка анализаторов, нечёткий поиск (Fuzzy Search), подсветка совпадений (Highlighting).

• Поиск по нескольким коллекциям (Multi-Map индексы)

• Сложные пространственные (Spatial) запросы

• Индексы по Time Series и Counters

Опять же простые сценарии автоиндексация закрывает сама т.е без индексов, написанных руками. С ручными индексами вам придётся столкнуться где-то в 10% случаев.

Дока

RavenDB безопасна по умолчанию. Она использует индустриальные стандарты защиты: шифрование данных «в транзите» и «на диске», сертификаты X.509, TLS 1.2+, а также механизмы предотвращения неправильных конфигураций. В документе подчёркивается: «Индустриальный стандарт безопасности, включая шифрование данных «на диске» и «в транзите», которое относительно просто применять… встроенные постоянные резервные копии».

TLS

Если база данных настроена так, что принимает внешние подключения без корректной конфигурации безопасности, RavenDB блокирует запуск и требует от администратора исправить ситуацию. Это предотвращает случайное открытие данных в интернет. При этом разработчик может спокойно работать локально без сложной настройки безопасности - RavenDB позволяет запускать систему на loopback‑интерфейсе без аутентификации, пока база не выходит наружу.

По умолчанию RavenDB в незашищённом режиме слушает только localhost. Это сделано для безопасности, чтобы администраторы случайно не выставили RavenDB в сеть без аутентификации. Если попытаться настроить URL, отличный от localhost, при отключённой аутентификации, RavenDB вернёт страницу ошибки с объяснением и инструкциями. Можно явно указать RavenDB, что это осознанное решение (например, если сеть изолирована и безопасна). Для этого требуется дополнительный шаг подтверждения.

RavenDB использует X509 клиентские сертификаты для аутентификации. Преимущество сертификатов в том, что они не привязаны к конкретному пользователю. Они представляют доступ, предоставленный приложению или роли. Обычно сертификаты выдаются именно на уровне приложения/роли, что делает модель аутентификации более естественной.

X.509 Certificate

Настроить RavenDB безопасно - просто (хотя сделать это простым было совсем непросто). После настройки RavenDB сама заботится обо всех аспектах защиты данных. Данные в транзите шифруются, клиенты и серверы проходят взаимную аутентификацию.

RavenDB шифрует все данные и индексы с использованием 256‑битного шифрования. Данные расшифровываются «на лету» по мере необходимости и хранятся в памяти только на время активной транзакции.

256 bit Encryption

Орен Еини в своей книге пишет, что объяснять безопасность он будет из того, что вы вообще ничего незнаете о ней. Я постараюсь в свою очередь выцепить оттуда интересные фрагменты и в упрощенной форме вам их донести не зарываясь в детали и так же указать на документацию.

Существуют разные типы сертификатов, которые можно использовать. Среди них

• Проверка домена (DV, Domain Validation)

• Подпись (Code Signing)

• Расширенная проверка (EV, Extended Validation)

• И многие другие.

В контексте RavenDB нас интересуют только DV-сертификаты, которые позволяют убедиться, что сервер, с которым вы общаетесь, действительно является тем сервером, за который вы его принимает.

Настройка RavenDB в защищённом режиме - довольно простой процесс. Вы можете сделать это самостоятельно, указав необходимые параметры конфигурации и напрямую развернув RavenDB.

Однако можно воспользоваться мастером настройки (setup wizard), чтобы запустить систему. Это упрощает процесс настройки защищённого экземпляра RavenDB, поскольку мастер настройки берёт на себя все необходимые детали.

Setup Wizard

Чтобы устранить значительную часть сложности такой конфигурации, RavenDB самостоятельно берёт на себя детали, связанные с обновлением DNS-записей и генерацией сертификата. Команда RavenDB управляет набором доменов верхнего уровня, из которых пользователям выделяются поддомены; RavenDB использует эти поддомены для создания сертификатов.

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

Срок действия сертификата ограничен. Let's Encrypt выдаёт сертификаты максимум на 90 дней. С операционной точки зрения это означает, что сертификаты необходимо периодически заменять.

Но не беспокойтесь: так же, как RavenDB автоматически генерирует сертификаты во время первоначальной настройки, RavenDB также самостоятельно обновляет сертификаты, когда это необходимо (причём с большим запасом по времени, чтобы избежать каких-либо проблем).

Let's Encrypt

RavenDB берёт на себя обновление сертификатов, распространение новых сертификатов на остальные узлы кластера и координацию их замены. Замена выполняется на работающей системе, без простоя, после того как все узлы получат новый сертификат благодаря Setup Wizard.

Если во время этого процесса возникнут какие-либо проблемы, RavenDB уведомит команду эксплуатации, чтобы у неё было достаточно времени для их устранения. RavenDB также будет регулярно повторять попытку, чтобы временные ошибки не смогли заблокировать процесс.

Однако за это приходится платить. Чтобы сделать процесс максимально простым и бесшовным, RavenDB использует api.ravendb.net для прохождения DNS challenge от Let’s Encrypt и обновления DNS-записей, указывающих на ваш сервер.

Этот сервис предоставляется пользователям RavenDB бесплатно. Однако для критически важных систем создатели RavenDb рекомендуют, чтобы команда эксплуатации самостоятельно контролировала этот процесс.

Сам сертификат генерируется на вашей машине, а не на машине, принадлежащей RavenDb. Но поскольку вы не владеете доменным именем своего кластера, для внесения изменений вам придётся взаимодействовать с api.ravendb.net.

RavenDb не занимается предоставлением хостинга и не предлагает круглосуточную поддержку по вопросам вроде: «Мне нужно изменить IP-адрес сервера на этом узле».

Для production-систем рекомендуется запускать RavenDB, используя собственную DNS-инфраструктуру и собственные сертификаты.

Создатели RavenDB тщательно спроектировали структуру доменных имён по умолчанию таким образом, чтобы получение сертификата для домена вашего кластера невозможно было осуществить незаметно - факт выдачи сразу отразится в публичных журналах Certificate Transparency.

CT Logs

Встроенная система аутентификации и авторизации RavenDB построена на X.509-сертификатах.

Может возникнуть соблазн рассматривать сертификат как простую замену пары логин/пароль - просто ещё один способ аутентификации пользователя. Орен рекомендовал избегать такого подхода.

Вместо этого думайте о предоставлении доступа к кластеру (и конкретным базам данных внутри него) на уровне приложения, а не на уровне отдельного пользователя.

Допустим у вас есть микросервисы и вы используете паттерн database-per-service. Отсюда вам лучше для каждого микросервиса создать отдельный сертификат.

Проблема подхода, основанного на безопасности отдельных пользователей, заключается в том, что ваши пользователи не обращаются к данным напрямую (и не должны этого делать). Вместо этого они взаимодействуют с вашим приложением, внутри которого принимаются решения о соблюдении бизнес-правил, валидации и авторизации с учётом полного понимания предметной области и логики приложения.

Попытка перенести в базу данных решения об авторизации на уровне бизнес-логики (например, правило «только руководитель сотрудника может выполнить Approve для VacationRequest») может привести к значительному усложнению как приложения, так и базы данных, а также создать утечки данных.

Дока

В системе существует три уровня доступа, хотя для большинства ваших задач обычно применяются только два. Наиболее часто используемые уровни:

• Cluster Administrator - это вы. Административный сертификат кластера, созданный во время первоначальной настройки, является одним из примеров. Он имеет доступ ко всему и может выполнять любые операции. Это аналог root в Linux.

• User - это сертификат, которому необходимо явно назначить разрешения для конкретных баз данных. Он ограничен только теми разрешениями, которые ему предоставлены.

• Operator - аналогичен Cluster Administratorпо масштабу, но ограничен в плане операций, которые он может выполнять в кластере. Operator уровень доступа обычно используется только в облачных средах.

ОБРАТИТЕ ВНИМАНИЕ:

• Даже если подписывающий сертификат сервера истёк (и впоследствии был заменён), RavenDB продолжит принимать административный клиентский сертификат до тех пор, пока сам клиентский сертификат не истечёт.

• Чтобы RavenDB принял клиентский сертификат как действительный, он обязательно должен быть зарегистрирован в кластере.

• RavenDB предупреждает о сертификатах, срок действия которых скоро истечёт (как о сертификатах кластера, так и о клиентских сертификатах). Однако вам всё равно следует заранее разработать план, обеспечивающий регулярную ротацию сертификатов.

Дока

Важно понимать в RavenDb, что журнал аудита привязан к тому узлу, на котором произошло исходное действие. Поэтому аудит не следует воспринимать как единый централизованный журнал всех подключений ко всему кластеру.

RavenDB записывает в журнал сам факт подключения, а не каждый выполненный запрос. Сделано это прежде всего из соображений производительности и практичности.

Если бы в журнал записывался каждый запрос, объём аудит-логов мог бы стать огромным, а работа с ними - значительно сложнее, как объясняет Орен.

Дока

Поэтому в журнале аудита можно найти, например:

• Время установки TCP-соединения

• Сертификат, использованный клиентом

• Соединение было отклонено, как недействительное

• База данных создана или удалена (со всех узлов или с одного узла)

• Был создан или удален индекс

• Добавление или удаление строки подключения

• И ТД.

Дока

Таким образом, аудит позволяет понять кто подключался к серверу и с какими правами, но не является журналом всех операций, выполненных клиентом после подключения.

ОДНАКО!

Вы можете самостоятельно использовать прокси сервер, чтобы регистрировать и запросы.

Дока

RavenDB интегрируется с широким спектром технологий: реляционные базы данных, OLAP‑решения, Kafka, RabbitMQ, PowerBI, Grafana, Elasticsearch.

Для реляционных систем RavenDB предоставляет мастер миграции SQL, который создаёт шаблон документов на основе таблиц. Автоматические ETL‑процессы позволяют реплицировать данные из RavenDB в SQL‑базы и обратно. RavenDB часто используется как write‑behind cache для реляционных систем или как часть полиглотной микросервисной архитектуры.

Для аналитических задач RavenDB имеет родной OLAP‑ETL, который автоматически передаёт изменения данных в дата‑лейки и OLAP‑хранилища.

ETL

Интеграция с Kafka и RabbitMQ двунаправленная: RavenDB может получать события из очередей и преобразовывать их в документы, а также публиковать события, сформированные из документов.

PowerBI может выполнять RQL‑запросы напрямую, что позволяет строить отчёты на основе интеллектуальных индексов RavenDB.

Power BI

Elasticsearch может использоваться как внешний поисковый кластер, и RavenDB предоставляет ETL для передачи данных в него, включая возможность отправлять только релевантные поля или агрегированные данные.

Клиентский API, как и вся RavenDB, стремится «просто работать». Для этого он основан на конвенциях - заранее принятых политик. Они определяют, например, какое свойство хранит идентификатор документа или как сериализовать сущность в документ.

RavenDb Conventions

В большинстве случаев вам не придётся менять конвенции. Создатели RavenDb вложили много усилий, чтобы это было редко нужно. Но предугадать все сценарии невозможно, поэтому API допускает кастомизацию.

Полный список доступных конвенций и их эффектов приведён в документации. Стоит хотя бы бегло ознакомиться, чтобы знать, какие возможности есть.

RavenDB поддерживает прозрачный шардинг, полностью скрывая его детали от разработчика. Документы распределяются по бакетам, которые назначаются серверам. При сохранении документа RavenDB вычисляет хеш его идентификатора и определяет бакет автоматически.

Особенность RavenDB - возможность «якорения» документов через символ $ в идентификаторе. «Хеш‑функция использует только часть после $… документы окажутся в одном бакете». Это позволяет хранить связанные документы вместе, что ускоряет запросы, индексирование и работу с агрегатами.

Перешардирование т.е перемещение бакетов между серверами - выполняется без остановки системы. Оркестратор скрывает распределённость и обеспечивает единый интерфейс для клиентов, так что приложение видит базу данных как цельную систему, даже если она распределена между множеством серверов.

Исходя из книги Inside RavenDb пишется система использует одновременно протокол консенсуса и протокол gossip, создавая два уровня коммуникации между узлами кластера.

gossip Protocol

Теорема CAP (теорема Бревера) утверждает: имея три свойства т.е

• согласованность

• доступность

• устойчивость к разделению сети

Система может выбрать только два. Невозможно обеспечить все три одновременно.

На практике, поскольку все реальные системы подвержены сетевым разделениям, остаётся выбор: быть CP (consistent + partition tolerant) или AP (available + partition tolerant). Разные базы данных выбирают разные подходы.

RavenDB выбрала быть и CP, и AP, но на разных уровнях:

• кластерный уровень - CP всегда согласован, но может быть недоступен при разделении сети;

• уровень базы данных - AP всегда доступен, даже при разделении, но обеспечивает eventual consistency.

В RavenDb используется алгоритм Raft и он имеет внутренню реализацию под названием Rachis.

CAP Theoreme в RavenDB

Архитектура RavenDB сильно вдохновлена статьёй Dynamo. Один из ключевых принципов - записи важны. Если пользователь пишет данные, система должна их сохранить. Поэтому RavenDB использует мульти-мастерную репликацию и всегда принимает записи.

Иными словами: даже если большинство кластера недоступно, пока работает хотя бы один узел, мы можем выполнять чтение и запись.

Amazon DynamoDb

Кластерные операции включают:

• создание новой базы данных,

• мониторинг состояния других узлов.

И вот что происходит, если мы выбрали кластерный уровень и столкнулись с network проблемой?

Мы, как пример, НЕ СМОЖЕМ:

• назначить задачу резервного копирования,

• развернуть новые индексы,

• изменить конфигурацию базы данных.

Если присмотреться ничего пугающего, это обычно не повседневные операции. Это одноразовые действия:

• создание индексов

• настройка рассписания бэкапов

• создание базы данных

• Добавление узлов в кластер и т.д.

Однако фоновые операции, как subscribtion и ETL не смогут продолжаться, пока кластер не восстановиться. Для этого требуется, чтобы большинство узлов могли общаться друг с другом.

Более интересные случаи включают ситуацию, когда узел отделился от остального кластера вместе с некоторыми (но не всеми) клиентами. В этом случае разные клиенты имеют разные представления о том, с кем они могут общаться. Поэтому каждый клиент способен выполнять failover независимо от кластера.

Можно настроить балансировку нагрузки на чтение между всеми узлами группы. Можно даже учитывать время отклика и заставить каждый клиент предпочитать самый быстрый узел.

Вы можете выполнять запись на любой узел группы базы данных, и эта запись будет сохранена и реплицирована на все остальные узлы группы.

Когда узел выходит из строя, кластер обнаруживает это и понижает его статус.

Сделано с умом

RavenDB использует асинхронную, многовекторную, конфликт‑устойчивую репликацию, построенную вокруг Change Vector и Raft‑консенсуса. Она не похожа на стандартные решения представленные на рынке СУБД.

Каждый документ имеет Change Vector - векторные часы. Репликация работает не по принципу «перешли всё», а по принципу:

• Узлы сравнивают версии документа и принимают решение, что нужно реплицировать. Об этом подробнее главой ниже, где рассказывается, как избегаются RollBack транзакции.

RavenDB не отправляет документы по одному - она формирует репликационные пакеты:

Размер пакета и его содержимое определяются RavenDB на основе: объёма данных, количества документов, скорости репликации, других внутренних факторов.

1. обычно один пакет = одна транзакция;

2. если транзакций много, пакет может содержать несколько;

3. если узел отставал, пакет может быть большим.

Это снижает накладные расходы и ускоряет догоняние.

Узел не ждёт подтверждения от других узлов. Он просто отправляет данные, а принимающий узел применяет их в своём темпе.

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

Replication

Вы должны понимать принцип, который присущь любой БД и он звучит так - Pay‑to‑play: Многие возможности RavenDB работают по принципу «платишь только если используешь». Если вы не включаете какую‑то функцию, вы не платите за неё производительностью.

Распределенные системы это всегда сложно.

Транзакции в RavenDB - не распределённые. Каждая транзакция выполняется и подтверждается на одном узле, локально, как обычная ACID-транзакция. Никакого two-phase commit между узлами нет.

Книга

Для сравнения: популярная MongoDB использует 2PC (Two-Phase Commit) для транзакций, затрагивающих документы на нескольких шардах. RavenDB сознательно идет по другому пути.

Согласованность в кластере достигается не за счёт распределённой транзакции, а за счёт того, как эта уже завершённая транзакция потом реплицируется

• Атомарность батча репликации. Все изменения, сделанные в рамках одной клиентской транзакции (SaveChanges()), реплицируются на другие узлы одним неделимым батчем. Другие узлы никогда не увидят “половину” транзакции - либо применились все изменения сразу, либо ни одного.

• Асинхронность (Temporal Staleness). Репликация происходит в фоне - уже после того, как клиент получил подтверждение записи. Это создает временную неактуальность данных на соседних узлах, аналогичную отставанию индексов.

• Ревизии для сложных случаев. Если документ обновляется в двух транзакциях подряд до завершения репликации первого изменения, включенные ревизии гарантируют, что полная история изменений корректно доедет до всех узлов без потери промежуточных состояний.

Документация

RavenDB не пытается сделать транзакцию распределённой (это дорого и снижает доступность). Вместо этого он делает саму репликацию атомарной единицей - переносит проблему консистентности с уровня “как договориться между узлами перед записью” на уровень “как гарантированно и целиком доставить уже свершившуюся запись на все узлы”.

Механизм ревизий решает три ключевые задачи:

• Аудит данных - история всех изменений документа: кто, когда, что менял.

• Восстановление после повреждения/ошибки - если документ случайно перезаписали неправильными данными, можно откатиться к предыдущей ревизии.

• Согласованность или ревизии для защиты от гонок. Если документ обновляется в двух транзакциях подряд до завершения репликации первого изменения, включенные ревизии гарантируют, что полная история изменений корректно доедет до всех узлов без потери промежуточных состояний.

Как выглядит ч1

Как выглядит ч2

Как выглядит ч3

В RavenDB есть механизм Change Vector, который является реализацией vector clocks в распределённой СУБД.

Этот механизм фиксирует версию документа на каждом узле и позволяет точно определить:

• какая копия документа новее,

• какие изменения уже реплицированы,

• где возник конфликт,

• как его корректно разрешить.

Change Vector в VS Code

Если сравнивать с аналогами, например с MongoDB, то там отсутствует полноценный механизм векторных часов. В случае расхождения данных MongoDB использует rollback: узел откатывает операции, которые оказались «неправильными» после выбора нового primary.

Это означает, что разработчик обязан самостоятельно обрабатывать последствия rollback - возможную потерю данных, расхождение состояния и необходимость ручного восстановления.

RavenDB идёт другим путём: она не откатывает данные при конфликте, а фиксирует обе версии документа и предоставляет вам возможность:

• Автоматически разрешить конфликт по выбранной стратегии.

• Вручную объединить данные.

• Сохранить обе версии для анализа.

Таким образом, Change Vector даёт RavenDB более надёжную и предсказуемую модель работы в распределённой среде, где конфликты - не исключение, а нормальная часть жизни системы.

Важно понимать, что Rollback это не «механизм», а аварийная ситуация, которую другие СУБД вынуждены решать так.

Механизм векторных часов (как Change Vector в RavenDB) известен давно, но внедрить его в полноценную СУБД сложно, дорого и на худой конец далеко не всем подходит.

Как выглядит в UI

Это даёт:

• отсутствие потери данных,

• детерминированное поведение,

• причинно‑следственную консистентность,

• предсказуемые конфликты, а не аварии.

RavenDB поставляется с обширным набором встроенных возможностей, которые в других системах требуют сторонних компонентов: быстрые агрегирования, ETL, Hub/Sink‑репликация, полнотекстовый поиск, тайм‑серии, ревизии документов, event sourcing, управление памятью, автоматическое кеширование, шаблоны Identity Map и Unit of Work.

«Функции, которые обычно приходится подключать извне… уже являются частью RavenDB». Это снижает сложность инфраструктуры, уменьшает количество точек отказа и экономит время разработчиков.

ETL RavenDb

RavenDB использует два вида кэширования: автоматическое и агрессивное. Автоматическое кэширование позволяет клиенту сообщать серверу, что у него есть закэшированная версия запроса. Если данные не изменились, RavenDB возвращает подтверждение, и клиент использует кэш.

Агрессивное кэширование работает иначе: клиент просит сервер уведомлять его только при изменениях. До получения уведомления клиент обслуживает запросы полностью из своего кэша. Это снижает количество обращений к серверу и уменьшает задержки, особенно в облаке.

Конкурентность обеспечивается движком хранения Voron, который использует MVCC. Писатели не блокируют читателей, а RavenDB объединяет несколько операций записи в одну дисковую операцию. Это значительно снижает I/O‑нагрузку и повышает производительность при высокой параллельности.

Caching RavenDb

RavenDB имеет встроенный механизм самодиагностики, который автоматически отслеживает новые версии, критические исправления и проблемы безопасности. В отличие от большинства СУБД, где администратор сам следит за релизами и CVE‑отчётами, RavenDB делает это самостоятельно и сразу сообщает о необходимости обновления.

Каждый узел периодически обращается к RavenDB Update Service, передавая минимальные данные о своей версии и конфигурации безопасности. В ответ сервер получает информацию о доступных обновлениях и патчах. Если версия устарела или содержит исправленные уязвимости, RavenDB показывает предупреждение прямо в Studio.

Механизм работает в любом окружении - Docker, Kubernetes, облачные VM или локальная машина.

В RavenDB Cloud процесс полностью автоматизирован: обновления и патчи применяются без участия пользователя, а инфраструктура остаётся актуальной и защищённой сама по себе.

Как выглядят уведомления

Как вы уже поняли из предыдущих глав, RavenDB старается заботиться о разработчике и девопсе практически на каждом этапе работы с системой. Она не просто выполняет операции, но и пытается предупредить о потенциальных проблемах, помочь разобраться в их причинах и подсказать возможные пути решения. В полной мере это проявляется и в вопросах производительности.

Подробно разбирать все подобные уведомления в рамках этой статьи, пожалуй, нет смысла - их действительно много, и перечислить их все здесь практически невозможно.

Тем не менее, хотя бы пару примеров привести стоит. RavenDB располагает целой системой Performance Hints, которая анализирует работу приложения и сообщает о потенциально неоптимальных сценариях, предлагая разработчику обратить на них внимание.

Как выглядят уведомления

Как выглядят уведомления

Как выглядят уведомления

RavenDB используется компаниями из Fortune 100, работает на нескольких континентах и применяется в системах с огромным количеством узлов. В документах упоминается: «крупная сеть с более чем 1,5 миллионами экземпляров POS‑терминалов».

Документ

RavenDB развёртывается как локально, так и в облаке - через RavenDB Cloud DBaaS на AWS, Azure и Google Cloud. Конфигурации варьируются от односерверных установок до глобальных гео‑распределённых кластеров.

Что такое Fortune 100?

JetBrains использовала RavenDB как один из реальных крупных .NET-проектов для проверки и улучшения производительности Rider. В 2017 году проблемы Rider при работе с исходным кодом RavenDB стали поводом для отдельного расследования и серии оптимизаций IDE.

Причём сами разработчики JetBrains довольно прямо описывали ситуацию: они признавались, что были «опозорены» проблемами производительности Rider, которые возникали при разработке RavenDB.

В результате JetBrains нашла узкие места и внесла ряд исправлений, непосредственно улучшивших работу Rider с проектом RavenDB.

Это показательный момент: RavenDB выступала не просто как случайный проект, на котором однажды запустили Rider, а как реальный тяжёлый .NET-кодбейс, на котором выявлялись проблемы производительности IDE.

Текст из статьи

И это повторялось не один раз. В этой статье JetBrains снова упоминает RavenDB в контексте работы над производительностью - на этот раз уже ReSharper.

Текст из статьи

Получается довольно интересная история: RavenDB неоднократно становилась своеобразным испытательным полигоном для производительности инструментов JetBrains, поскольку её кодовая база достаточно велика и сложна, чтобы выявлять реальные проблемы IDE.

И, наконец, в 2024 году JetBrains пригласила Oren Eini, создателя RavenDB, на отдельный .NET livestream, посвящённый созданию database engine на C# и .NET. Интервью в 2024г

Текст статьи

Скажу сразу: я не включал тесты отдельных энтузиастов - мне это не особо интересно. Если RavenDB уже используют Toyota, Rakuten Kobo, JetBrains и другие крупные компании, гораздо показательнее посмотреть на их опыт.

По данным RavenDB, базой пользуются около 12 000 компаний по всему миру.

Список крупных компаний RavenDB в слайдере

Так же материал с упоминанием Toyota и Verizon

Ниже я буду опираться на книгу «Comparing MongoDB & RavenDB» Оren Eini, поэтому да - определённая предвзятость автора очевидна. Но Rakuten Kobo самостоятельно проводила сравнительные тесты, а её CTO публично рассказывал об опыте с MongoDB и CouchDB и объяснял выбор RavenDB.

Видео CTO Rakuten Kobo - Trevor Hunter’а о RavenDb

Как выглядит

Так что это не база, которая появилась вчера и существует только на словах разработчиков. Если даже после таких production-кейсов всё объявлять «предвзятостью», то, боюсь, никакие аргументы уже не убедят.

Сравнение RavenDB и MongoDB - это не просто сопоставление двух документных баз данных. Это сопоставление двух философий, двух подходов к архитектуре, двух способов думать о данных, транзакциях, индексации, репликации и эксплуатации. RavenDB и MongoDB появились в разное время, решали разные задачи и развивались под влиянием разных инженерных традиций. Поэтому их различия не поверхностны - они фундаментальны.

В этой главе мы подробно разберём ключевые отличия, опираясь на документы, включая такие фрагменты, как: «RavenDb изначально была ACID транзакционной БД, а MongoDb стала транзакционной в 2018 году…» и «индексы MongoDB оптимизируются под определённые шаблоны запросов». Мы также рассмотрим реальные кейсы, включая опыт Rakuten Kobo, который сравнивал Couchbase, MongoDB и RavenDB в условиях реальной нагрузки.

MongoDb VS RavenDB

RavenDB была спроектирована как ACID‑транзакционная система с самого первого дня. Это означает, что транзакции над несколькими документами, строгая целостность данных и предсказуемое поведение при сбоях встроены в архитектуру. Подчёркивается: «RavenDb изначально была ACID транзакционной БД…».

MongoDB же пришла к транзакциям значительно позже - только в 2018 году. До этого она поддерживала лишь атомарные операции над одним документом. Даже сегодня транзакции в MongoDB имеют цену: они снижают производительность, требуют явного включения и сопровождаются рекомендациями документации избегать их, если возможно, изменяя модель данных.

Это различие определяет всё остальное. В RavenDB транзакции - естественная часть системы. В MongoDB - компромисс между скоростью и целостностью.

ACID

RavenDB использует оптимистичное управление конкурентностью. Это означает, что операции чтения и записи не блокируют друг друга, а движок хранения Voron объединяет несколько изменений в одну дисковую операцию.

MongoDB использует многоуровневую систему блокировок - на уровне сервера, базы данных, коллекции и документа. В документах подчёркивается: «Блокировки могут составлять более 30% общей стоимости операций.»

Под нагрузкой это различие становится критическим. RavenDB масштабируется линейно по числу узлов. MongoDB начинает терять производительность из‑за роста количества блокировок и затрат на их управление.

Optimistic VS Pessimistic Locking

RavenDB использует архитектуру master‑to‑master. Запись может происходить на любом узле, узлы реплицируют изменения друг другу, и каждый узел содержит полную копию данных. Это обеспечивает нулевой простой при сбоях.

MongoDB использует модель primary–secondary. Запись идёт только на primary, а вторичные узлы получают данные через OpLog. Это создаёт узкое место и приводит к задержкам при выборе нового primary.

В документе подчёркивается: «сбой первичного узла может остановить всю систему…» и «RavenDB - 0 downtime» в тестах Chaos Monkey.

Кроме того, OpLog может переполниться при высокой нагрузке, что приводит к состоянию, которое описано как «постоянно некорректное состояние, требующее вмешательства администратора».

Переведено всё тут с этой книги

Индексирование - одна из областей, где различия между системами наиболее заметны.

MongoDB не поддерживает автоматические индексы. MongoDB Atlas предлагает Index Autopilot, но он лишь создаёт индексы по рекомендациям и не умеет удалять ненужные. Это приводит к накоплению индексов, снижению производительности и необходимости постоянного участия DBA.

MongoDb Atlas

В документе это описано так: «MongoDB Performance Advisor лучше, чем ничего, но это похоже на то, как если бы вы отвезли свой фургон на ремонт после того, как он уже сломался.»

RavenDB, напротив, создаёт индексы автоматически, оптимизирует их на основе реальных запросов, объединяет релевантные индексы и удаляет неиспользуемые. Индексы RavenDB способны обслуживать широкий спектр запросов, тогда как индексы MongoDB оптимизируются под конкретный шаблон - порядок полей, порядок сортировки, структуру запроса.

Это фундаментальное различие: RavenDB адаптируется под приложение, MongoDB требует адаптации приложения под базу.

RavenDb, как из персонажей DC Comics: Думсдэй

MongoDB предоставляет два механизма агрегирования - MapReduce и Aggregation Pipeline. Оба требуют обработки всех подходящих документов при каждом запросе. Это приводит к обходным решениям: сохранению результатов во временные коллекции, их периодическому обновлению, планированию обновлений в нерабочие часы и значительным затратам на поддержку.

RavenDB выполняет агрегирование заранее и постоянно поддерживает результаты в актуальном состоянии. В документе подчёркивается: «агрегирующие запросы выполняются за миллисекунды, а не за минуты - и без какого‑либо операционного оверхеда.»

Это превращает RavenDB в систему, где аналитические запросы не создают нагрузку на продакшен, а MongoDB - в систему, где аналитика требует отдельной инфраструктуры.

MongoDB использует BSON - формат, который требует десериализации при каждом чтении. Это увеличивает использование памяти и CPU.

RavenDB использует Blittable JSON - формат с нулевыми накладными расходами, который позволяет обращаться к документам напрямую в страничном кеше ОС.

В документе подчёркивается: «Blittable может обрабатывать данные без полного парсинга документа… что значительно снижает стоимость операций.»

Это одно из ключевых преимуществ RavenDB: система работает в тандеме с операционной системой, а не поверх неё.

Виды JSON

Шардинг MongoDB требует настройки нескольких серверов, mongos‑роутеров и config‑серверов. Выбор shard key критически важен, и его нельзя изменить без выгрузки и перезагрузки данных. Неправильный выбор приводит к неравномерному распределению данных и «горячим точкам».

RavenDB использует сегментирование по идентификатору документа и скрывает все детали реализации. Перешардирование выполняется без остановки системы. Это делает масштабирование RavenDB предсказуемым и безопасным.

Sharding

MongoDB предлагает коннекторы, но большинство ETL‑сценариев требует сторонних инструментов. MongoDB BI Connector не поддерживает выполнение запросов. Коннекторы не позволяют добавлять трансформационные скрипты.

RavenDB предоставляет встроенные ETL‑механизмы для SQL, OLAP, Kafka, RabbitMQ, Elasticsearch. Это полноценные, нативные инструменты, которые работают в реальном времени и не требуют внешних компонентов.

MongoDB предлагает полнотекстовый поиск только в MongoDB Atlas. Типичные развёртывания интегрируются с Elasticsearch, что удваивает операционный оверхед.

RavenDB предоставляет полнотекстовый поиск из коробки. В документе подчёркивается: «RavenDB предоставляет полноценный полнотекстовый поиск из коробки… отсутствие необходимости покупать, интегрировать и мониторить отдельный продукт.»

Corax

MongoDB не является безопасной по умолчанию. Конфигурация рассматривает каждого пользователя как администратора, что удобно для разработки, но опасно в продакшене. В документе приводится факт: «За последние годы было скомпрометировано более 100 000 баз данных MongoDB.»

RavenDB, напротив, блокирует небезопасные конфигурации, использует индустриальные стандарты и предоставляет простой мастер настройки безопасности.

Encryption RavenDb

Rakuten Kobo провели масштабное сравнение Couchbase, MongoDB и RavenDB. Импорт данных, нагрузочные тесты, отказоустойчивость и эксплуатация показали, что RavenDB обеспечивает стабильную производительность, нулевой простой, предсказуемую архитектуру и удобство разработки и эксплуатации.

Trevor Hunter подчёркивает: обновления RavenDB проходят легко, тесты пишутся просто, разработчики довольны, DevOps довольны, отказоустойчивость впечатляет, производительность стабильна, архитектура предсказуемая.

Rakuten Kobo

MongoDB - это система, которая предоставляет базовые механизмы, но требует значительного участия разработчиков и администраторов. Она гибкая, но эта гибкость оборачивается сложностью эксплуатации, необходимостью ручной настройки индексов, рисками неправильного выбора shard key, зависимостью от внешних инструментов и постоянной борьбой с блокировками.

RavenDB - это система, которая стремится быть безадминистративной. Она оптимизирует себя автоматически, адаптирует индексы под запросы, выполняет агрегирование заранее, скрывает сложность шардинга, обеспечивает транзакции по умолчанию, предоставляет встроенные ETL‑механизмы и работает в тандеме с операционной системой.

RavenDB позволяет разработчикам забыть о базе данных и сосредоточиться на приложении. MongoDB требует постоянного внимания.

RavenDb

История Rakuten Kobo - это не просто пример выбора между двумя документными базами данных. Это история компании с капитализацией 12-13 миллиардов долларов, которая ежедневно обслуживает десятки миллионов устройств, генерирующих нагрузку, сравнимую с постоянной DDoS‑атакой.

Rakuten Kobo - один из крупнейших мировых продавцов цифровых книг. Компания принадлежит японской корпорации Rakuten и базируется в Торонто. Миллионы пользователей покупают книги, делают выделения, оставляют заметки, синхронизируют свои устройства - и всё это требует стабильной, быстрой и предсказуемой инфраструктуры хранения данных.

Когда руководство Kobo решило модернизировать инфраструктуру, они столкнулись с вопросом: какая база данных выдержит их реальный продакшен‑трафик?
Couchbase уже использовалась в компании, но её поведение под нагрузкой вызывало вопросы. RavenDB же обещала высокую производительность, низкие задержки и устойчивость к сбоям.

Чтобы получить объективный ответ, команда под руководством CTO Тревора Хантера провела масштабное исследование, создала огромный тестовый набор данных и сравнила обе системы в условиях, максимально приближённых к реальности.

CTO Rakuten Kobo - Trevor Hunter

Для большинства компаний даже несколько тысяч одновременных запросов - серьёзная нагрузка. Для Rakuten Kobo обычный день выглядит как непрерывная атака: миллионы устройств синхронизируются автоматически, независимо от действий пользователей.

Каждый ридер периодически отправляет данные о новых книгах, выделениях, заметках. Если запросы начинают тормозить, устройства получают тайм‑ауты и повторяют попытку позже, создавая лавинообразный эффект. Инфраструктура должна выдерживать:

• постоянный поток запросов,

• редкие, но тяжёлые операции (полная синхронизация нового устройства),

• всплески нагрузки,

• сбои узлов,

• обновления кластера.

Именно поэтому выбор базы данных стал критически важным.

RavenDb VS CouchDb

Чтобы сравнение было честным, Kobo совместно с RavenDB создали воспроизводимый набор данных, максимально похожий на реальный.

В итоговую базу вошли:

• 69.38 млн пользователей,

• 63 510 книг,

• 734.22 млн связей «пользователь-книга»,

• 497.03 млн выделений,

• десятки миллионов документов о произведениях, авторах и изданиях.

Общий объём 1.35 миллиарда документов, экспорт 108 ГБ, итоговый размер базы 985 ГБ.

Структура данных отражала реальное распределение: большинство пользователей имеют мало книг, но существуют «библиотечные» аккаунты с десятками тысяч книг. Выделения распределены по длинному хвосту: от единичных до сотен тысяч.

Это не синтетический тест. Это модель реальной нагрузки крупного мирового сервиса

HighLoad Results

Загрузка 1.35 млрд документов - сама по себе серьёзный стресс‑тест.

RavenDB справилась менее чем за сутки, используя машину с 8 ядрами и 32 ГБ RAM.

Couchbase потребовала почти четыре дня, и это был только первый тревожный сигнал.

Причина - архитектура Couchbase:

• она хранит метаданные всех документов в оперативной памяти,

• каждый ключ документа занимает длину ID + 56 байт,

• при длинных идентификаторах это приводит к огромному потреблению RAM.

Для 1.35 млрд документов Couchbase потребовала 162 ГБ RAM только для хранения ключей, тогда как RavenDB работала со всем набором данных, используя 32 ГБ.

Даже узлы с 128 ГБ RAM падали из‑за нехватки памяти, уходили в page faults, становились недоступными. Приходилось снижать скорость загрузки, делать паузы, отключать механизмы Couchbase, увеличивать диски до 6 ТБ.

Минимальная конфигурация, которая смогла завершить загрузку в Couchbase, - 3 узла по 32 ядра и 128 ГБ RAM каждый.

Это в 12 раз больше, чем требовалось RavenDB.

Вот это обгон в 12 раз!

RavenDB хранила полный набор данных на каждом узле: 985 ГБ данных + 120 ГБ индексов. На дисках 2 ТБ оставалось достаточно места.

Couchbase же столкнулась с несколькими проблемами:

[1] Шардинг без репликации Каждый документ хранился только на одном узле. Это снижало надёжность и увеличивало риск потери данных.

[2] Модель append‑only Каждая запись добавляется в конец файла. При изменениях старые версии остаются, а новые записываются снова. Это приводит к:

• огромному росту файлов,

• необходимости компакции,

• временным скачкам использования диска.

[3] Компакция

Компакция Couchbase - тяжёлая операция:

• может длиться часы,

• иногда более 12 часов,

• требует огромного количества IOPS,

• может удваивать или утраивать размер файлов.

Один вторичный индекс занимал 450 ГБ, а во время компакции до 2.5 ТБ.

Чтобы завершить тест, узлы Couchbase пришлось увеличить до 6 ТБ диска каждый.

CouchDb

[1] Доступ по ключу При доступе по ключу Couchbase показывает хорошие результаты - пока данные находятся в памяти. Но есть нюанс: узел Couchbase не может обслуживать запросы, пока не загрузит все ключи в память. Это занимает 10–20 минут.

RavenDB начинает обслуживать запросы через несколько секунд после запуска, даже если данные ещё не прогреты.

[2] Запросы по пользователю и книге

Это основной сценарий Kobo: получить выделения пользователя или выделения пользователя в конкретной книге.

RavenDB обрабатывала:

• 15 000 запросов/сек до достижения порога 200 мс,

• 93% запросов - быстрее 200 мс,

• 85% - быстрее 50 мс.

Couchbase достигла порога 200 мс уже при 250 запросах/сек.

[3] Префиксные запросы

RavenDB позволяет выполнять префиксные запросы по ID, минуя индекс. Это даёт огромный выигрыш в производительности.

Couchbase пыталась повторить этот подход, но:

• CPU взлетал до 80%+,

• задержки росли,

• кластер не выдерживал даже 100 запросов/сек.

Rakuten Kobo уделяет особое внимание отказоустойчивости.

[1] Поведение Couchbase при сбое узла

Сбой узла вызывает:

• перебалансировку,

• огромную нагрузку на кластер,

• длительное время восстановления,

• необходимость загрузки всех ключей в память,

• задержку в 10–20 минут до начала обслуживания запросов,

• задержку индексов до 30 минут.

Некоторые операции Couchbase (например, смена hostname) требуют удаления узла из кластера и повторного присоединения - что вызывает перебалансировку, которая может длиться 40 часов.

[2] Поведение RavenDB при сбое узла

RavenDB:

• мгновенно переключает клиентов на другой узел,

• не вызывает перебалансировку,

• не требует загрузки ключей,

• восстанавливается за секунды,

• использует write‑ahead log,

• реплицирует только новые записи.

Обновление узла RavenDB занимает менее минуты и является «не‑событием».

Отказоустойчивость

Эталонный кластер Couchbase - минимальная конфигурация без репликации. Но в продакшене так работать нельзя.

Согласно документации Couchbase, для реальной нагрузки Kobo требуется:

• 5 узлов по 192 ГБ RAM,

• коэффициент репликации 3,

• тип узлов m5a.12xlarge,

• общий объём дисков около 30 ТБ.

Годовая стоимость - огромная.

RavenDB же:

• работает на кластере из 3 узлов m5a.xlarge,

• может работать даже на ARM‑узлах,

• выдерживает 10 000 запросов/сек на узле с 2 ядрами и 8 ГБ RAM,

• выдерживает 500 запросов/сек на Raspberry Pi 4.

Разница в стоимости - порядки величины.

Price of Infrastructure and Requests

Rakuten Kobo пришла к однозначному выводу:

• RavenDB быстрее,

• RavenDB стабильнее,

• RavenDB дешевле,

• RavenDB проще в эксплуатации,

• RavenDB выдерживает реальные нагрузки,

• RavenDB не требует внешних систем для запросов,

• RavenDB не падает при сбоях,

• RavenDB не требует терабайтов диска,

• RavenDB не требует сотен гигабайт RAM.

Couchbase же:

• не выдерживает запросы под нагрузкой,

• требует огромных ресурсов,

• долго восстанавливается,

• вызывает перебалансировки,

• нуждается в Elasticsearch для запросов,

• не подходит для инфраструктуры Kobo.

Конкуренция на рынке баз данных привела к появлению действительно интересных решений, и одним из наиболее ярких примеров стала RavenDB. Она выгодно выделяется среди альтернатив благодаря сочетанию продуманной архитектуры, мощных технологических возможностей и качественного пользовательского опыта.

Любопытно, что когда‑то RavenDB вдохновлялась идеями CouchDB, но сегодня сама опережает его по уровню зрелости и функциональности. MongoDB, несмотря на популярность, также заметно уступает RavenDB по качеству предоставляемых возможностей и стабильности работы.

Даже если эти факты не производят сильного впечатления, они демонстрируют важный принцип: там, где есть конкуренция, рождаются лучшие продукты. Конкуренция остаётся ключевым двигателем прогресса.

Конкуренция ключ прогресса