«Енисей» имеет существенные доработки в плане функционала по сравнению с CouchDB. К ним относятся новая модель безопасности, функции аудита, способы хранения на диске бинарных данных, новые встроенные функции построения выборок и манипуляций с данными, поддержка языка Elixir в проектных документах, поддержка LDAP, режим «грязной» записи, поддержка дополнительного протокола доступа и др.

Вместе с тем мы постоянно анализируем развитие CouchDB и его выпускаемые релизы и адресно импортируем все важные изменения в «Енисей». В настоящий момент в «Енисее» содержится весь функционал версии 3.3.3 CouchDB.

«Енисей» поддерживает два типа программных интерфейсов:

• HTTP REST API с доступом к полностью всему функционалу СУБД. Интерфейс содержит несколько десятков методов, относящихся как к работе с данными, так и к администрированию сервера.
• Erlang Distribution Protocol. Данный интерфейс позволяет выполнять производительную низкоуровневую интеграцию с прикладными системами, реализованными на языках Erlang/Elixir и на Java.

Производительность «Енисея» такая же, как у CouchDB 3.3.3

Поддержка мультимастер-репликаций является одним из наиболее интересных свойств «Енисея», отличающих его от других СУБД. Режим «Мультимастер» обеспечивается как при работе с одним сервером «Енисея», так и в кластере, а также при объединении нескольких кластеров. Независимо от того, с каким из связанных кластеров работает клиент и с каким конкретно сервером внутри кластера, он может выполнять любые операции по выборке и изменению данных, а обеспечение консистентности данных при этом берет на себя СУБД.

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

SQL не поддерживается. «Енисей» — это NoSQL-система, в которой все функции манипуляции с данными описываются на одном из поддерживаемых языков программирования. Используются не специализированные языки работы с данными, а именно языки программирования широкого назначения.

Все функции работы с данными собираются в проектных документах. Это тоже документы, лежащие в БД, но в них содержится не информационный контент, а код функций. Для проектных документов так же действуют механизмы репликации, как и для обычных документов.

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

Таких планов нет. «Енисей» — это наш форк именно CouchDB, его невозможно перевести на что-то другое. В свое время CouchDB отлично зарекомендовал себя в наших проектах как оперативная база данных и как транспортная подсистема, поэтому именно он был выбран в качестве основы для разработки «Енисея».

Это проекты, где используется именно «Енисей», но есть множество проектов, где стоит наш форк CouchDB, который не имел до 2022 года своей собственной торговой марки.

«Енисей» собирается под Debian, Ubuntu, Windows, AltLinux, Astra Linux, РЕД ОС. Также имеется дистрибутив в виде docker-образа. Поддерживаются аппаратные платформы x86 и ARM.

В «Енисее», как и в CouchDB, нет такого понятия, как внешние ключи, и не имеется функционала для какой-либо специфической поддержки этих внешних ключей. Однако это, конечно, не мешает использованию в качестве значения атрибутов документов любых идентификаторов (строковых, числовых или составных) из других баз или даже из внешних СУБД. Любой атрибут документа может быть использован в качестве ключа или значения представлений, плюс по любому атрибуту или их группе может быть построен индекс в «Енисее» для оптимизации доступа. Если требуется более сильная зависимость от внешних сущностей, то это должно реализовываться на прикладном уровне.

Это напрямую зависит от проекта, сайзинг вне контекста вряд ли возможен. Утилизация ресурсов со стороны СУБД — это прежде всего результат выполнения запросов при операциях над данными. Не имея представления о требованиях со стороны решения, нельзя дать адекватный ответ на такой вопрос. На ряде инсталляций достаточно и сервера с двумя ядрами и 2 ГБ памяти. Оптимальным вариантом для достижения «Енисеем» высоких скоростей записи и выборок данных в высоконагруженных решениях мы считаем сервер с 32 ядрами и 32 ГБ RAM.

Принципы масштабирования полностью соответствуют тому, как работает CouchDB. Кластер может состоять из произвольного количества узлов, поддерживается шардирование, репликации и партиционирование БД. Состав кластера может произвольно меняться в процессе работы. Каждая БД в кластере может иметь свои персональные настройки по числу шардов и реплик.

«Енисей» не имеет коллекций, схемы данных и схемы связей между коллекциями, как это реализовано в MongoDB, то есть нет и намека на реляционную структуру данных, как в MongoDB. БД в «Енисее» — это просто линейный список документов. Документ в «Енисее» — это самодостаточная сущность, не требующая внешних связей. Поэтому можно сказать, что в «Енисее» нет языковой модели как таковой. Построение выборок в«Енисее» подразумевает использование принципиально другого подхода, чем в MongoDB, — представлений, которые реализуют технику Map-Reduce.

В «Енисее» имеется поддержка типа запроса Mango Query (видимо, под собственной языковой моделью подразумевается именно эта возможность). Его синтаксис напоминает MongoDB, но прямой совместимости нет.

Дисковые операции с данными в «Енисее» реализованы по принципу Append-only, поэтому нет деградации скорости добавления данных или получения результатов выборок с увеличением размера БД. Мы эксплуатировали «Енисей» на базах с десятками миллиардов документов, объем данных при этом достигал десятков терабайт. Такой режим, по сути, ничем не отличался от работы с базами малого объема и не требовал увеличения процессорных ресурсов или памяти. Только диски должны быть большими. Нет технических ограничений по размерам документов, числу документов в БД, байтовому размеру БД, числу БД на одном сервере или кластере.

Прежде всего, в том, что это разные решения для разных задач. «Енисей» — это документо-ориентированная СУБД, в которой реализованы специфические механики для обработки и хранения документов. S3 — key-value объектное хранилище, в котором при желании можно хранить и документы. В «Енисей» можно хранить и бинарные данные как объекты с метадатой, что удобно в дополнение к основному функционалу. Построить на базе S3 распределенную инфраструктуру хранения и обработки документов в теории можно, но не будет эффективно.

«Енисей» не поддерживает транзакции. Гарантируется только то, что успешно отправленный документ будет сохранен в БД полностью. При сохранении и после него могут возникнуть конфликты, которые тоже являются неотъемлемым свойством MVCC, позволяющим исключить блокировки документов или операций с БД.

Да, с помощью API-эндпоинта _find возможно построение произвольных запросов данных, для оптимизации которых используются индексы. «Енисей» позволяет создавать индексы по любым полям и группам полей. Кроме того, выполняется автоматическая индексация ключей, получаемых на выходе этапа Map-представлений и индексация всех документов по ID, т.к. выборка документа по ID — наиболее частая операция с БД в реальных проектах.

Запросы документов по ID и получение результатов представлений не требуют предварительного ручного создания индексов. Использование функции _find (Mango-запросы), как правило, заставляет добавлять индексы для ее оптимизации. Есть возможность создавать индексы по произвольным полям и группам полей. Кроме того, «Енисей» позволяет получать время выполнения запросов и пояснения к обработке запросов для их отладки и целенаправленной оптимизации.

«Енисей» поддерживает 4 языка «из коробки». Это JavaScript, CoffeScript, Erlang, Elixir. Использование этих языков описано в документации. Кроме того, в интернете можно найти готовые драйверы (для CouchDB) для поддержки и некоторых других языков, их тоже возможно подключить к «Енисею».

В «Енисее» ведется полная статистика по внутреннему состоянию, количество метрик исчисляется сотнями. Доступ к ней выполняется с поддержкой протокола Prometheus.

Блокировки являются инструментом для реализации транзакций. Транзакции в «Енисее» не поддерживаются, и блокировок в традиционном их понимании тоже нет.

Однако в качестве одной из дополнительных функций «Енисея» по сравнению с CouchDB является реализация системы параллельного обслуживания заявок, которая позволяет подключить к БД несколько клиентов, выполняющих роль обработчиков заявок (документов в терминологии СУБД). Данный функционал реализован как раз с помощью так называемых блокировок, которые обеспечивают то, что документы будут равномерно распределены между обработчиками.

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

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

Между отдельными серверами или кластерами «Енисея» настраиваются задания на репликацию данных. Все задания являются односторонними. Поэтому для двунаправленной репликации следует создать два отдельных задания.

Репликации бывают:

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

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

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

При выполнении записи документа в кластере в параметрах запроса указывается replica-factor, который определяет, на скольких серверах должны быть сохранены данные перед отправкой ответа клиенту. Аналогично replica-factor присутствует и в запросах на чтение. С помощью данных параметров достигается гарантированная видимая консистентность данных в кластере с точки зрения клиента, причем происходит это в режиме «Мультимастера».

Отдельно в «Енисее» существует механизм репликации данных между кластерами. Это не то же самое, что репликация внутри кластера. Эта операция выполняется без привязки к клиентским запросам, в фоновом режиме. Поэтому если система состоит из двух отдельных кластеров с репликацией между ними, то добиться синхронной репликации данных из клиентского запроса в оба кластера действительно не получится. Если требуется, чтобы данные синхронно реплицировались в несколько дата-центров (то есть необходимо обеспечить устойчивость к отказам дата-центра полностью), то система должна строиться, например, так: в кластер включаются сервера сразу из нескольких дата-центров. Тогда с помощью параметра replica-factor можно обеспечить сохранение данных во всех дата-центрах перед ответом клиенту. И, соответственно, если такая запись не удалась из-за недоступности одного из дата-центров, то клиент получит на свой запрос ошибку.

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

Вместо работы с консенсусом в «Енисее» действует подход MVCC, то есть обновление данных на любом узле с последующей синхронизацией изменений на основе номеров ревизий.

Для разрешения конфликтов в «Енисее» предусмотрено два подхода:

• автоматическое разрешение, когда алгоритмически одна из конфликтующих ревизий считается «победителем» одинаково на всех серверах;
• выдача конфликтующих ревизий в прикладную систему для принятия решения вне «Енисея».

Наличие конфликтов никак не мешает последующему обновлению данных и не приводит к каким-либо блокировкам.

«Енисей» поддерживает несколько схем аутентификации, в том числе LDAP и JWT-токены.Защита данных на уровне протокола обеспечивается поддержкой HTTPS.

В «Енисее» все операции требуют авторизации. Поддерживаются одновременно дискреционная и мандатная модели контроля доступа, причем управление доведено до уровня отдельных документов.

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

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

Да, «Енисей» поддерживает авторизацию с помощью JWT-токенов, которые как раз используются в Keycloak.

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

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

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

Максимальная скорость приема данных зависит от свойств кластера: числа серверов, числа шардов и реплик БД, мощности отдельных серверов. Кроме того, скорость варьирует в зависимости от параметров запросов: размера документов и числа документов в батчах (при групповых вставках). Некоторые из комбинаций указанных параметров более рациональны в смысле достижения высокой скорости получения данных, другие — менее. У нас имеются данные экспериментов по обеспечиваемым максимальным скоростям получения и сохранения данных. Предельные значения скорости дисковой записи соизмеримы с возможностями современных SSD (до 400 МБ/с и выше). Сетевая скорость при этом, естественно, связана с возможностями дисковой подсистемы.

В «Енисее» есть такое понятие, как кворум, измеряется в числе серверов с одинаковой последней ревизией документа. Он применяется при формировании ответов на запросы данных из БД. Кворум может быть не равен числу реплик документа в кластере. Размер кворума по умолчанию указывается в свойствах БД и может быть установлен в другое значение в параметрах запроса. Успешный ответ на клиентский запрос придет только при достижении кворума при обработке этого запроса.

«Енисей» обеспечивает работу с файлами БД в режиме Append-only. Поэтому в один момент времени в базе может присутствовать несколько ревизий одного и того же документа. Ко всем ревизиям имеется доступ через API.

Периодически запускается процесс уплотнения БД, который создает новый файл БД и переносит в него не все, а только последние ревизии документов, то есть при уплотнении старые ревизии документов удаляются. Сколько именно ревизий следует оставлять, а также параметры планировщика уплотнений указывают в конфигурации сервера «Енисея».

На каждом из серверов «Енисея», между которыми настроена репликация одной и той же БД, могут быть свои параметры уплотнения. Поэтому, например, один из серверов, с целью сохранить более полную историю изменений, может вообще не выполнять уплотнение автоматически, а только по запросу от внешней системы или администратора.

При сохранении JSON-данных в файлы действительно работает сжатие. Уровень сжатия указывается в конфигурации серверов.

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

Несмотря на это, «Енисей» полностью обеспечивает режим работы с данными, указанный в данном вопросе. Документ можно произвольно менять одновременно в разных частях системы. При изменении документа обязательно указывается номер ревизии, на основе которой выполняется изменение. Затем, когда выполняется синхронизация данных между серверами, возможно возникновение конфликтов, т.е. ситуаций, когда присутствует несколько изменений, выполненных на основе одной и той же базовой ревизии. В этом суть классического MVCC-подхода, который используется в «Енисее», так же как и во многих других СУБД. Способы разрешения конфликтов описаны в ответе на предыдущий вопрос.

Основной концепцией «Енисея» является сохранение постоянной доступности сервиса и отсутствие блокировок. В соответствии с CAP-теоремой обеспечивается это за счет возможной неконсистентности данных. «Енисей» обеспечивает «согласованность в конечном счете» (Eventual Consistency).

Параметры серверов зависят от особенностей проекта, в котором используется «Енисей». На ряде инсталляций достаточно и сервера с двумя ядрами и 2 ГБ памяти. Оптимальным вариантом для достижения «Енисеем» высоких скоростей записи и выборок данных мы считаем сервер с 32 ядрами и 32 ГБ RAM.

В «Енисее» есть понятие «зона размещения данных». В случае необходимости размещения одной БД в нескольких дата-центрах в свойствах базы можно указать, сколько реплик каждой шарды будет находиться в каждом из дата-центров. Обращаться при получении или обновлении данных можно на любой из серверов кластера. Таким образом, доступ к данным гарантируется при любых инфраструктурных отказах. В период отсутствия связности между дата-центрами все данные остаются полностью доступными для любых изменений в каждом из дата-центров отдельно. После восстановления связности «Енисей» автоматически выполнит синхронизацию данных, в ходе которой возможно возникновение конфликтов данных (это неотъемлемое свойство MVCC-технологии).

Либо может быть использован другой способ: в каждом ДЦ создается своя БД, между которыми организуется двунаправленная master-master-репликация.

Шардирование — это обычное свойство всех БД под управлением «Енисея», так как он изначально создавался для работы с большими данными, которые по определению не помещаются на одном сервере. Даже по умолчанию база создается в режиме: три шарды, две реплики. Шардирование работает по хешу от идентификатора документа, таким образом, данные автоматически равномерно распределяются между шардами. Однако с помощью элементарной конфигурации можно обеспечить и ручное распределение данных, указать для базы, какие ее части должны быть размещены на каком именно сервере кластера. Кроме того, поддерживается функционал партиционирования, это почти то же самое, что и шардирование, только на основе пользовательского признака, а не по ID документа. С помощью партиционирования можно гибко управлять размещением данных с целью более рационально использовать оборудование или повышение производительности доступа.

REST API «Енисея» имеет методы для администрирования кластера и перераспределения БД между его узлами. Их вызовы достаточно легко автоматизируются. Методы не представляют никакой сложности и подробным образом описаны в документации.

«Енисей» имеет единственный интерфейс HTTP REST, поэтому подходят, в принципе, любые балансировщики HTTP протокола, например Traefik или HAProxy. В нашем варианте поставки «Енисея» под контейнерную платформу Imagenarium используется Traefik.

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

Имеется поддержка вызова пользовательских сценариев после выполнения операции уплотнения БД. Эта функция может быть использована для автоматизации сохранения бэкапов БД.

Для работы с «Енисеем» достаточно обучения в том же объеме, что и для CouchDB. По нашему опыту, в силу особенностей имплементации «Енисей» имеет очень низкий порог вхождения. Большинству инженеров достаточно краткосрочного знакомства с API «Енисея», для того чтобы уже можно было начать прототипирование будущего решения.

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

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

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