Мы используем cookies и предполагаем, что вы согласны на обработку ваших данных, если продолжите пользоваться сайтом
OK
Связаться с нами
Нажимая кнопку, вы подтверждаете своё согласие с политикой конфиденциальности.
компаний-разработчиков ПО, специализирующихся на распределённых системах
Наш продукт создан специально для
компаний-интеграторов, поставляющих ПО для комплексных проектов
и предоставляющих услуги IT-консалтинга
и предоставляющих услуги IT-консалтинга
IT-департаментов крупного бизнеса, отвечающих за автоматизацию разработки
делает сложные проекты малыми силами или работает в условиях дефицита ресурсов
ищет кроссплатформенную СУБД, работающую на различных устройствах и платформах
А также для тех, кто
Варианты использования СУБД «Енисей»
Поисковый индекс для документного хранилища. Многократно ускоряет процессы поиска документов и формирование ETL выгрузок из хранилища.
Отказоустойчивое документное хранилище позволяет строить решения, способные хранить десятки миллиардов документов без деградации производительности.
Мощный и отказоустойчивый файловый сервер.
Распределенная коммуникационная инфраструктура для вашего решения.
Хранение ГЕО-данных в соответствии с требованиями формата RFC 7946 GeoJSON.
Часть проекта TrioData — технологического стека, на базе которого можно строить высоконагруженные решения для хранения и обработки больших массивов данных.
«Енисей» оптимизирует
затраты на разработку
затраты на разработку
Сокращает время time-to-market на 30%
Широкие перспективы развития продукта
Экономит до 40% временных затрат разработчиков
Сокращает время time-to-market на 30%
Экономит до 40% временных затрат разработчиков
Отечественное решение от российского разработчика
Ускоряет прототипирование сложных решений в 2 раза
Ускоряет прототипирование сложных решений в 2 раза
Отсутствие рисков, присущих западным решениям и Open Source
Отечественное решение от российского разработчика
Широкие перспективы развития продукта
Отсутствие рисков, присущих западным решениям и Open Source
Поддержка российских разработчиков
Мы предлагаем «Енисей» для разработчиков российских решений и стартапов бесплатно на период разработки продуктов. Оплату лицензий осуществляет конечный потребитель, либо покупатель стартапа или разработанного решения.
На период разработки мы оказываем консультационную поддержку и помогаем адаптировать архитектуру разрабатываемого решения, чтобы наши продукты максимально раскрыли свой потенциал.
Мы предлагаем партнёрство, вы создаёте новые продукты. Наши лицензии оплачивают ваши клиенты.
Какие проблемы решает «Енисей»
Вам необходимо разработать распределённую систему
СУБД должна работать на разных ОС и платформах
Предстоит миграция на NoSQL СУБД российского производства
Требуется оптимизировать существующий технологический стек и при этом сэкономить
Доставка данных осуществляется в неустойчивых каналах
Нет необходимости разработки REST API для ваших сервисов
Вам необходимо разработать распределённую систему
СУБД должна работать на разных ОС и платформах
Предстоит миграция на NoSQL СУБД российского производства
Требуется оптимизировать существующий технологический стек и при этом сэкономить
Доставка данных осуществляется в неустойчивых каналах
Нет необходимости разработки REST API для ваших сервисов
Для разработчиков
«Енисей» идеально подходит для основы инфраструктуры вашего проекта. На его базе можно построить сложную распределённую систему буквально за несколько часов, потому что «Енисей» сам является такой системой.
Высокая скорость обмена данными между репликами в multi-master и использование уже готовой транспортной инфраструктуры с REST API в качестве интерфейса для работы с СУБД «Енисей» позволяют сэкономить ресурсы для разработки и развития системы.
Высокая скорость обмена данными между репликами в multi-master и использование уже готовой транспортной инфраструктуры с REST API в качестве интерфейса для работы с СУБД «Енисей» позволяют сэкономить ресурсы для разработки и развития системы.
Высокая производительность
Фреймворк для разработки
Высокоскоростная репликация
В комплекте с СУБД есть Java-фреймворк «Ангара». В нём решены стандартные задачи и предусмотрены уникальные возможности, благодаря которым можно существенно сократить срок разработки собственных решений на базе «Енисея».
«Ангара» также реализует поддержку ODM (Object-Document Mapping), тем самым превращая Енисей в своего рода документо-ориентированное хранилище.
«Ангара» также реализует поддержку ODM (Object-Document Mapping), тем самым превращая Енисей в своего рода документо-ориентированное хранилище.
Основные сценарии использования
Построение сложных распределённых систем
Обработка данных в высоконагруженной среде
Основа транспортной инфраструктуры
Примеры внедрения
С помощью платформы Завершена разработка расширения «Триодата» для 1С, позволяющего подключать «Енисей» в качестве распределенного файлового хранилища. Вместе с возможностями, предоставленными нашим партнером ООО «Газинформсервис» в своем решение Jatoba, наши клиенты получат высокопроизводительное, отказоустойчивое и распределенное решение для 1С, позволяющее хранить и обрабатывать большие объемы данных.
Интеграция СУБД «Енисей» в систему «Честный знак» — один из самых серьезных примеров использования в подобных проектах. Разработчики других представленных на рынке решений пока не могут похвастаться кейсами внедрения такого масштаба. Благодаря уникальным возможностям СУБД «Енисей» построена распределенная инфраструктура обмена данными, которая объединит центральную систему «Честный знак» с миллионами кассовых аппаратов по всей стране.
С помощью платформы Завершена разработка расширения «Триодата» для 1С, позволяющего подключать «Енисей» в качестве распределенного файлового хранилища.
Интеграция СУБД «Енисей» в систему «Честный знак» — один из самых серьезных примеров использования в подобных проектах.
Комплекс «Триодата» будет полезен для заказчиков с большими объемами данных и высокой нагрузкой на 1С. Решение готово для демонстрации и тестирования.
Конечно же, в комплекте идут миграционные механизмы для переноса данных в хранилище нового типа.
Енисей также используется в 1С как распределенное хранилище логов. Такой подход снимает ограничения на объем хранимых данных, предоставляет удобный инструментарий для работы с логами. Может быть встроен непосредственно в 1С, в штатные интерфейсы для работы с логами.
Вместе с возможностями, предоставленными нашим партнером ООО «Газинформсервис» в своем решение Jatoba, наши клиенты получат высокопроизводительное, отказоустойчивое и распределенное решение для 1С, позволяющее хранить и обрабатывать большие объемы данных.
Комплекс «Триодата» будет полезен для заказчиков с большими объемами данных и высокой нагрузкой на 1С. Решение готово для демонстрации и тестирования.
Конечно же, в комплекте идут миграционные механизмы для переноса данных в хранилище нового типа.
Енисей также используется в 1С как распределенное хранилище логов. Такой подход снимает ограничения на объем хранимых данных, предоставляет удобный инструментарий для работы с логами. Может быть встроен непосредственно в 1С, в штатные интерфейсы для работы с логами.
Задача СУБД «Енисей» — хранение информации о маркированной продукции, для обеспечения работы торговой точки, когда нет доступа в интернет. Инфраструктура работает с высокой нагрузкой, и требования к ее надежности крайне высоки. В данном проекте «Енисей» используется «as is», без каких-либо доработок под задачи проекта. «Енисей» выбран с учетом ключевых требований заказчика — простоты интеграции и кроссплатформенности. Других СУБД с таким набором поддерживаемых платформ на рынке не существует. внедрения: легкая интеграция — ключевое требование заказчика. Представленный кейс, несомненно, будет интересен многим компаниям — участникам оборота маркированной продукции, производителям оборудования. В ближайшее время им придется искать СУБД с указанными свойствами. Выход уже найден!
Разработчики других представленных на рынке решений пока не могут похвастаться кейсами внедрения такого масштаба. Благодаря уникальным возможностям СУБД «Енисей» построена распределенная инфраструктура обмена данными, которая объединит центральную систему «Честный знак» с миллионами кассовых аппаратов по всей стране. Задача СУБД «Енисей» — хранение информации о маркированной продукции, для обеспечения работы торговой точки, когда нет доступа в интернет. Инфраструктура работает с высокой нагрузкой, и требования к ее надежности крайне высоки. В данном проекте «Енисей» используется «as is», без каких-либо доработок под задачи проекта. «Енисей» выбран с учетом ключевых требований заказчика — простоты интеграции и кроссплатформенности. Других СУБД с таким набором поддерживаемых платформ на рынке не существует. внедрения: легкая интеграция — ключевое требование заказчика. Представленный кейс, несомненно, будет интересен многим компаниям — участникам оборота маркированной продукции, производителям оборудования. В ближайшее время им придется искать СУБД с указанными свойствами. Выход уже найден!
Статьи
Почему «Енисей»
NoSQL СУБД «Енисей» спроектирована для применения в высоконагруженных системах реального времени и без проблем может хранить миллиарды документов, предоставляя широкий выбор инструментов для работы с такими объемами данных.
Listeners (обработчики событий БД)
Listeners (обработчики событий БД)
JSON как формат хранения данных
MapReduce
Высокопроизводительные view
Append-Only
JSON как формат хранения данных
RESTful API
JSON как формат хранения данных
RESTful API
JSON как формат хранения данных
JSON как формат хранения данных
RESTful API
Listeners (обработчики событий БД)
JSON как формат хранения данных
Listeners (обработчики событий БД)
JSON как формат хранения данных
JSON как формат хранения данных
Listeners (обработчики событий БД)
Listeners (обработчики событий БД)
JSON как формат хранения данных
MapReduce
Append-Only
Высокопроизводительные view
Append-Only
MapReduce
Высокопроизводительные view
Минимальное время на освоение и внедрение СУБД в процесс разработки
Разработчику не нужно осваивать специальные языки для работы с данными или искать драйвера для фреймворков выбранного языка программирования...
Кроссплатформенность
«Енисей» работает на любой платформе, на которой можно развернуть Docker. Кроме того, платформа поддерживает ARM8, ARM7, Raspberry Pi и работу в браузере...
Ядро «Енисей»
В ядре используется CouchDB, документо-ориентированная СУБД. Она уже отлично зарекомендовала себя во множестве продуктов и проектов — например...
В «Енисее» применяются знакомые всем HTTP-запросы GET и POST. Клиентом нашей СУБД может быть просто браузер.
Наш продукт очень прост в конфигурации и эксплуатации, не требует глубокого понимания нюансов работы и настройки.
В комплекте с «Енисеем» идет Java-фреймворк, в котором уже решено большинство стандартных задач и есть много уникальных возможностей, которые помогут сократить срок разработки собственных решений на базе нашей СУБД.
Наш продукт очень прост в конфигурации и эксплуатации, не требует глубокого понимания нюансов работы и настройки.
В комплекте с «Енисеем» идет Java-фреймворк, в котором уже решено большинство стандартных задач и есть много уникальных возможностей, которые помогут сократить срок разработки собственных решений на базе нашей СУБД.
Подробнее
Да, именно работу в браузере, так как у нас есть версия на JavaScript. Кроме того, на финальной стадии разработки находится версия для Android.
«Енисей» – это система хранения данных и коммуникационная среда, готовая работать «из коробки».
«Енисей» – это система хранения данных и коммуникационная среда, готовая работать «из коробки».
Подробнее
в облачном решении от IBM «Cloudant», в информационных системах CERN, Красного Креста, United Airlines, BBC, Canal +, Amadeus ITGoup и во многих других.
«Енисей» написан на Erlang — языке программирования, разработанном для создания высоконагруженных, распределенных систем.
От CouchDB мы взяли всё самое лучшее и устранили недостатки. Мы увеличили производительность, улучшили безопасность, доработали управление пользователями, улучшили пользовательский интерфейс и разработали собственный фреймворк, в который включены все наши наработки более чем за 7 лет активной работы с CouchDB.
«Енисей» зарегистрирован как самостоятельное решение в 2022 году, но сам проект — это плод работы за все эти годы.
«Енисей» написан на Erlang — языке программирования, разработанном для создания высоконагруженных, распределенных систем.
От CouchDB мы взяли всё самое лучшее и устранили недостатки. Мы увеличили производительность, улучшили безопасность, доработали управление пользователями, улучшили пользовательский интерфейс и разработали собственный фреймворк, в который включены все наши наработки более чем за 7 лет активной работы с CouchDB.
«Енисей» зарегистрирован как самостоятельное решение в 2022 году, но сам проект — это плод работы за все эти годы.
Подробнее
Дистрибутивы и лицензии
Перед началом работы с программным обеспечением, рекомендуем внимательно ознакомиться с условиями Лицензионного соглашения и инструкцией по установке
Ubuntu 22.04
версия 1.0.0
Make great presentations, longreads, and landing pages, as well as photo stories, blogs, lookbooks, and all other kinds of content oriented projects.
инструкция по установке
Инструкция по установке Ubuntu 22.04
- Обратитесь в отдел продаж или технической поддержки производителя программного продукта для получения информации о доступных опциях лицензирования и приобретения необходимого ключа активации.
- Получите необходимые данные от поставщика, включая серийный номер лицензии, тип лицензии и условия её использования.
- Следуя инструкциям, предоставленным поставщиком, установите ключ активации в соответствии с требованиями производителя.
- Проверьте правильность установки лицензии, чтобы убедиться в корректной работе программного продукта.
- Сохраняйте все документы и ключи активации для дальнейшего обновления или поддержки продукта.
Debian 11
версия 1.0.0
Make great presentations, longreads, and landing pages, as well as photo stories, blogs, lookbooks, and all other kinds of content oriented projects.
инструкция по установке
Инструкция по установке Debian 11
- Обратитесь в отдел продаж или технической поддержки производителя программного продукта для получения информации о доступных опциях лицензирования и приобретения необходимого ключа активации.
- Получите необходимые данные от поставщика, включая серийный номер лицензии, тип лицензии и условия её использования.
- Следуя инструкциям, предоставленным поставщиком, установите ключ активации в соответствии с требованиями производителя.
- Проверьте правильность установки лицензии, чтобы убедиться в корректной работе программного продукта.
- Сохраняйте все документы и ключи активации для дальнейшего обновления или поддержки продукта.
Docker
версия 1.0.0
Make great presentations, longreads, and landing pages, as well as photo stories, blogs, lookbooks, and all other kinds of content oriented projects.
инструкция по установке
Инструкция по установке Docker
- Обратитесь в отдел продаж или технической поддержки производителя программного продукта для получения информации о доступных опциях лицензирования и приобретения необходимого ключа активации.
- Получите необходимые данные от поставщика, включая серийный номер лицензии, тип лицензии и условия её использования.
- Следуя инструкциям, предоставленным поставщиком, установите ключ активации в соответствии с требованиями производителя.
- Проверьте правильность установки лицензии, чтобы убедиться в корректной работе программного продукта.
- Сохраняйте все документы и ключи активации для дальнейшего обновления или поддержки продукта.
версия 2.1.2
версия 2.1.2
версия 2.1.2
версия 2.1.2
Для использования потребуется файл комьюнити-лицензии.
Ознакомиться с возможностями, функционалом и примерами использования СУБД «Енисей» вы можете в разделе онлайн-документации.
Ознакомиться с возможностями, функционалом и примерами использования СУБД «Енисей» вы можете в разделе онлайн-документации.
«Енисей» имеет существенные доработки в плане функционала по сравнению с CouchDB. К ним относятся новая модель безопасности, функции аудита, способы хранения на диске бинарных данных, новые встроенные функции построения выборок и манипуляций с данными, поддержка языка Elixir в проектных документах, поддержка LDAP, режим «грязной» записи, поддержка дополнительного протокола доступа и др.
Вместе с тем мы постоянно анализируем развитие CouchDB и его выпускаемые релизы и адресно импортируем все важные изменения в «Енисей». В настоящий момент в «Енисее» содержится весь функционал версии 3.3.3 CouchDB.
Вместе с тем мы постоянно анализируем развитие CouchDB и его выпускаемые релизы и адресно импортируем все важные изменения в «Енисей». В настоящий момент в «Енисее» содержится весь функционал версии 3.3.3 CouchDB.
«Енисей» поддерживает два2 типа программных интерфейсов:
- HTTP REST API с доступом к полностью всему функционалу СУБД. Интерфейс содержит несколько десятков методов, относящихся как к работе с данными, так и к администрированию сервера.
- Erlang Distribution Protocol. Данный интерфейс позволяет выполнять производительную низкоуровневую интеграцию с прикладными системами, реализованными на языках Erlang/Elixir и на Java.
Производительность «Енисея» такая же, как у CouchDB 3.3.3
Поддержка мультимастер-репликаций является одним из наиболее интересных свойств «Енисея», отличающих его от других СУБД. Режим «Мультимастер» обеспечивается как при работе с одним сервером «Енисея», так и в кластере, а также при объединении нескольких кластеров. НТо есть, независимо от того, с каким из связанных кластеров работает клиент и с каким конкретно сервером внутри кластера, он может выполнять любые операции по выборке и изменению данных, а обеспечение консистентности данных при этом берет на себя СУБД.
«Мультимастер» реализован на базе технологии MVCC. При любом изменении какого-либо документа указывается предыдущая ревизия документа, которая известная клиенту и, на базе которой он выполняет данное изменение. При обработке запросов и репликаций данных «Енисей» выстраивает цепочки изменений и может решить, какая из ревизий документа является актуальной.
«Мультимастер» реализован на базе технологии MVCC. При любом изменении какого-либо документа указывается предыдущая ревизия документа, которая известная клиенту и, на базе которой он выполняет данное изменение. При обработке запросов и репликаций данных «Енисей» выстраивает цепочки изменений и может решить, какая из ревизий документа является актуальной.
SQL не поддерживается. «Енисей» — - это NoSQL- система, в которой все функции манипуляции с данными описываются на одном из поддерживаемых языков программирования. ИТо есть используются не специализированные языки работы с данными, а именно языки программирования широкого назначения.
Все функции работы с данными собираются в так называемых проектных документах. Это тоже документы, лежащие в БД, но в них содержится не информационный контент, а код функций. Для проектных документов так же действуют механизмы репликации, как и для обычных документов.
Предусмотрены функции нескольких типов: — валидаторы изменений, MapReduce- агрегации данных, обработчики произвольных пользовательских запросов, преобразователи выходных документов. Суммарно, все эти функции обеспечивают практически весь спектр потребностей по работе с данными, который может быть реализован на SQL.
Все функции работы с данными собираются в так называемых проектных документах. Это тоже документы, лежащие в БД, но в них содержится не информационный контент, а код функций. Для проектных документов так же действуют механизмы репликации, как и для обычных документов.
Предусмотрены функции нескольких типов: — валидаторы изменений, MapReduce- агрегации данных, обработчики произвольных пользовательских запросов, преобразователи выходных документов. Суммарно, все эти функции обеспечивают практически весь спектр потребностей по работе с данными, который может быть реализован на SQL.
Таких планов нет. «Енисей» — - это наш форк именно CouchDB, его невозможно перевести на что-то другое. В свое время CouchDB отлично зарекомендовал себя в наших проектах как оперативная база данных и как транспортная подсистема, поэтому именно он был выбран в качестве основы для разработки «Енисея».
Это проекты, где используется именно «„Енисей“», но есть множество проектов, где стоит наш форк CouchDB, который не имел до 2022 года своей собственной торговой марки
«Енисей» собирается под Debian, Ubuntu, Windows, AltLinux, AstraLinux, РЕДОС. Также имеется дистрибутив в виде docker-образа. Поддерживаются аппаратные платформы x86 и ARM.
В «Енисее», как и в CouchDB, нет такого понятия, как внешние ключи, и не имеется функционала для какой-либо специфической поддержки этих внешних ключей. Однако это, конечно, не мешает использованию в качестве значения атрибутов документов любых идентификаторов (строковых, числовых, или составных) из других баз, или даже из внешних СУБД. ЛА любой атрибут документа может быть использован в качестве ключа или значения представлений, плюс по любому атрибуту или их группе может быть построен индекс в «Енисее» для оптимизации доступа. Если требуется более сильная зависимость от внешних сущностей, то это должно реализовываться на прикладном уровне.
Это напрямую зависит от проекта, сайзинг вне контекста вряд ли возможен. Утилизация ресурсов со стороны СУБД —- это прежде всего результат выполнения запросов при операциях над данными. Не имея представления о требованиях со стороны решения, нельзя дать адекватный ответ на такой вопрос. На ряде инсталляций достаточно и сервера с двумя2 ядрами и 2 ГБ памяти. Оптимальным вариантом для достижения «Енисеем» высоких скоростей записи и выборок данных в высоконагруженных решениях мы считаем сервер с 32 ядрами и 32 ГБ RAM.
Принципы масштабирования полностью соответствуют тому, как работает CouchDB. Кластер может состоять из произвольного количества узлов, поддерживается шардирование, репликации и партиционирование БД. Состав кластера может произвольно меняться в процессе работы. Каждая Б Д в кластере может иметь свои персональные настройки по числу шардов и реплик.
«Енисей» не имеет коллекций, схемы данных и схемы связей между коллекциями, как это реализовано в MongoDB, т. То есть нет и намека на реляционную структуру данных, как в MongoDB. БД в «Енисее» — - это просто линейный список документов. Документ в «Енисее» — - это самодостаточная сущность, не требующая внешних связей. Поэтому можно сказать, что в «Енисее» нет языковой модели как таковой. Построение выборок в" Енисее" подразумевает использование принципиально другого подхода, чем в MongoDB, — - представленийя, которые реализуют технику Map-Reduce.
В «Енисее» имеется поддержка типа запроса — Mango Query (видимо, под собственной языковой моделью подразумевается именно эта возможность). Его синтаксис напоминает MongoDB, но прямой совместимости нет
В «Енисее» имеется поддержка типа запроса — Mango Query (видимо, под собственной языковой моделью подразумевается именно эта возможность). Его синтаксис напоминает MongoDB, но прямой совместимости нет
Дисковые операции с данными в «Енисее» реализованы по принципу «Append-only», поэтому нет деградации скорости добавления данных или получения результатов выборок с увеличением размера БД. Мы эксплуатировали «Енисей» на базах с десятками миллиардов документов, объем данных при этом достигал десятков терабайт. Такой режим, по сути, ничем не отличался от работы с базами малого объема и не требовал увеличения процессорных ресурсов, или памяти. Только диски должны быть большими. Нет технических ограничений по размерам документов, числу документов в БД, байтовому размеру БД, числу БД на одном сервере или кластере.
Прежде всего, в том, что это разные решения для разных задач. «„Енисей“ —» — это документо-ориентированная СУБД, в которой реализованы специфические механики для обработки и хранения документов. S3 —- key-value объектное хранилище, в котором, при желании можно хранить и документы. В ««Енисеt"й» можно хранить и бинарные данные, как объекты с метадатой, что удобно в дополнение к основному функционалу. Построить на базе S3 распределенную инфраструктуру хранения и обработки документов в теории можно, но не будет эффективно.
«Енисей» не поддерживает транзакции. Гарантируется только то, что успешно отправленный документ будет сохранен в БД полностью. При сохранении и после него могут возникнуть конфликты, которые тоже являются неотъемлемым свойством MVCC, позволяющим исключить блокировки документов или операций с БД.
Да, с помощью API-эндпоинта _find возможно построение произвольных запросов данных, для оптимизации которых используются индексы. «Енисей» позволяет создавать индексы по любым полям и группам полей. Кроме того, выполняется автоматическая индексация ключей, получаемых на выходе этапа Map- представлений и индексация всех документов по Id, т.к. выборка документа по Id —- наиболее частая операция с БД в реальных проектах.
Запросы документов по Id и получение результатов представлений не требуют предварительного ручного создания индексов. Использование функции _find (Mango-запросы), как правило, заставляет добавлять индексы для ее оптимизации. Есть возможность создавать индексы по произвольным полям и группам полей. Кроме того, «Енисей» позволяет получать время выполнения запросов и пояснения к обработке запросов для их отладки и целенаправленной оптимизации.
«Енисей» поддерживает 4 языка «„из коробки“». Это JavaScript, CoffeScript, Erlang, Elixir. Использование этих языков описано в документации. Кроме того, в интернете можно найти готовые драйверы (для CouchDB) для поддержки и некоторых других языков, их тоже возможно подключить к «Енисею».
В «Енисее» ведется полная статистика по внутреннему состоянию, количество метрик исчисляется сотнями. Доступ к ней выполняется с поддержкой протокола Prometheus.
Блокировки являются инструментом для реализации транзакций. Транзакции в «Енисее» не поддерживаются, и блокировок в традиционном их понимании тоже нет.
Однако, в качестве одной из дополнительных функций «Енисея», по сравнению с CouchDB, является реализация «системы параллельного обслуживания заявок», которая позволяет подключить к БД несколько клиентов, выполняющих роль обработчиков заявок (документов в терминологии СУБД). Данный функционал реализован как раз с помощью так называемых блокировок, которые обеспечивают то, что документы будут равномерно распределены между обработчиками.
Однако, в качестве одной из дополнительных функций «Енисея», по сравнению с CouchDB, является реализация «системы параллельного обслуживания заявок», которая позволяет подключить к БД несколько клиентов, выполняющих роль обработчиков заявок (документов в терминологии СУБД). Данный функционал реализован как раз с помощью так называемых блокировок, которые обеспечивают то, что документы будут равномерно распределены между обработчиками.
При построении представлений используется любой из поддерживаемых «Енисеем» языков программирования. Это означает, что выражения и конструкции могут быть произвольной сложности и размера.
В API-эндпоинте _find, в котором используется декларативный синтаксис выборки данных, могут применяться десятки поддерживаемых операторов, т. е. получаемые конструкции по факту тоже могут быть достаточно сложными, н. Но относятся они к одному документу. Невозможно задать параметры выборки так, чтобы принимались в расчет несколько документов, или отношения между документами.
В API-эндпоинте _find, в котором используется декларативный синтаксис выборки данных, могут применяться десятки поддерживаемых операторов, т. е. получаемые конструкции по факту тоже могут быть достаточно сложными, н. Но относятся они к одному документу. Невозможно задать параметры выборки так, чтобы принимались в расчет несколько документов, или отношения между документами.
Между отдельными серверами или кластерами «Енисея» настраиваются задания на репликацию данных. Все задания являются односторонними. Поэтому для двунаправленной репликации следует создать два2 отдельных задания.
Репликации бывают:
Гибкость в организации репликаций позволяет строить распределенные базы без полного дублирования данных, а с гибким роутингом потоков изменений.
Репликации бывают:
- однократными и непрерывными;
- безусловными и селективными.
Гибкость в организации репликаций позволяет строить распределенные базы без полного дублирования данных, а с гибким роутингом потоков изменений.
При выполнении записи документа в кластере в параметрах запроса указывается replica-factor, который определяет, на скольких серверах должны быть сохранены данные перед отправкой ответа клиенту. Аналогично replica-factor присутствует и в запросах на чтение. С помощью данных параметров достигается гарантированная видимая консистентность данных в кластере с точки зрения клиента, причем происходит это в режиме «Мультимастера».
Отдельно в «Енисее» существует механизм репликации данных между кластерами. Это не то же самое, что репликация внутри кластера. Эта операция выполняется без привязки к клиентским запросам, в фоновом режиме. Поэтому, если система состоит из двух отдельных кластеров с репликацией между ними, то добиться синхронной репликации данных из клиентского запроса в оба кластера действительно не получится. Если требуется, чтобы данные синхронно реплицировались в несколько дата-центров (то есть необходимо обеспечить устойчивость к отказам дата-центра полностью), то система должна строиться, например, так: в кластер включаются сервера сразу из нескольких дата-центров. Тогда с помощью параметра replica-factor можно обеспечить сохранение данных во всех дата-центрах перед ответом клиенту. И, соответственно, если такая запись не удалась, из-за недоступности одного из дата-центров, то клиент получит на свой запрос ошибку.
Отдельно в «Енисее» существует механизм репликации данных между кластерами. Это не то же самое, что репликация внутри кластера. Эта операция выполняется без привязки к клиентским запросам, в фоновом режиме. Поэтому, если система состоит из двух отдельных кластеров с репликацией между ними, то добиться синхронной репликации данных из клиентского запроса в оба кластера действительно не получится. Если требуется, чтобы данные синхронно реплицировались в несколько дата-центров (то есть необходимо обеспечить устойчивость к отказам дата-центра полностью), то система должна строиться, например, так: в кластер включаются сервера сразу из нескольких дата-центров. Тогда с помощью параметра replica-factor можно обеспечить сохранение данных во всех дата-центрах перед ответом клиенту. И, соответственно, если такая запись не удалась, из-за недоступности одного из дата-центров, то клиент получит на свой запрос ошибку.
В «Енисее» split-brain невозможен, так как при работе с данными не используются алгоритмы консенсуса. Все сервера в кластере «Енисея» полностью равноправны в плане функциональности и управления данными. Запрос на получение или обновление данных обрабатывается одним из серверов кластера, который выступает «„организатором“» именно для этого запроса.
Вместо работы с консенсусом, в «Енисее» действует подход MVCC, — то есть обновление данных на любом узле с последующей синхронизацией изменений на основе номеров ревизий.
Для разрешения конфликтов в «Енисее» предусмотрено два2 подхода:
Вместо работы с консенсусом, в «Енисее» действует подход MVCC, — то есть обновление данных на любом узле с последующей синхронизацией изменений на основе номеров ревизий.
Для разрешения конфликтов в «Енисее» предусмотрено два2 подхода:
- автоматическое разрешение, когда алгоритмически одна из конфликтующих ревизий считается «„победителем“» одинаково на всех серверах;
- выдача конфликтующих ревизий в прикладную систему для принятия решения вне «Енисея».
«Енисей» поддерживает несколько схем аутентификации, в том числе LDAP и JWT-токены.
Защита данных на уровне протокола обеспечивается поддержкой HTTPS.
Защита данных на уровне протокола обеспечивается поддержкой HTTPS.
В «Енисее» все операции требуют авторизации.
Поддерживаются одновременно дискреционная и мандатная модели контроля доступа, п. Причем управление доведено до уровня отдельных документов.
Поддерживается несколько категорий пользователей: администраторы сервера, администраторы БД, читатели БД, писатели БД, читатели и писатели конкретного документа. Каждая из этих категорий обладает своими полномочиями по выполнению операций с документами, базами данных, настройками серверов и кластера в целом.
При обработке поступающих в БД документов могут задействоваться специальные функции проектных документов —- валидаторы, которые позволяют выполнить произвольные проверки контента документа, свойств базы и пользователя для принятия решения о возможности записи такого документа в БД. Это максимально гибкий механизм контроля записи.
Поддерживаются одновременно дискреционная и мандатная модели контроля доступа, п. Причем управление доведено до уровня отдельных документов.
Поддерживается несколько категорий пользователей: администраторы сервера, администраторы БД, читатели БД, писатели БД, читатели и писатели конкретного документа. Каждая из этих категорий обладает своими полномочиями по выполнению операций с документами, базами данных, настройками серверов и кластера в целом.
При обработке поступающих в БД документов могут задействоваться специальные функции проектных документов —- валидаторы, которые позволяют выполнить произвольные проверки контента документа, свойств базы и пользователя для принятия решения о возможности записи такого документа в БД. Это максимально гибкий механизм контроля записи.
Да, «Енисей» поддерживает авторизацию с помощью JWT-токенов, которые как раз используются в Keycloak.
Все события, происходящие на сервере, такие как клиентские запросы, или запуск автоматических заданий, протоколируются в журнале.
Кроме того, имеется функционал аудита данных. При этом в каждой ревизии документа в служебном атрибуте сохраняется, кто именно из пользователей и когда создал данную ревизию. Эта информация реплицируется между серверами вместе с самим документом и таким образом становится доступной не только локально, но и во всех остальных узлах системы.
Отдельно еще ведется (активизируется конфигурацией) специальная глобальная БД изменений данных, в которой фиксируются факты создания и удаления баз данных, а также идентификаторы всех ревизий, создаваемых во всех БД.
Кроме того, имеется функционал аудита данных. При этом в каждой ревизии документа в служебном атрибуте сохраняется, кто именно из пользователей и когда создал данную ревизию. Эта информация реплицируется между серверами вместе с самим документом и таким образом становится доступной не только локально, но и во всех остальных узлах системы.
Отдельно еще ведется (активизируется конфигурацией) специальная глобальная БД изменений данных, в которой фиксируются факты создания и удаления баз данных, а также идентификаторы всех ревизий, создаваемых во всех БД.
Максимальная скорость приема данных зависит от свойств кластера: — числа серверов, числа шардов и реплик БД, мощности отдельных серверов. Кроме того, скорость варьируется в зависимости от параметров запросов: — размера документов и числа документов в батчах (при групповых вставках). Некоторые из комбинаций указанных параметров более рациональны в смысле достижения высокой скорости получения данных, другие — менее. У нас имеются данные экспериментов по обеспечиваемым максимальным скоростям получения и сохранения данных. Предельные значения скорости дисковой записи соизмеримы с возможностями современных SSD (- до 400 МБ/с и выше). Сетевая скорость при этом, естественно, связана с возможностями дисковой подсистемы.
В «Енисее» есть такое понятие, как кворум, измеряется в числе серверов с одинаковой последней ревизией документа. Он применяется при формировании ответов на запросы данных из БД. Кворум может быть не равен числу реплик документа в кластере. Размер кворума по умолчанию указывается в свойствах БД и может быть установлен в другое значение в параметрах запроса. Успешный ответ на клиентский запрос придет только при достижении кворума при обработке этого запроса.
«Енисей» обеспечивает работу с файлами БД в режиме Append-oOnly. Поэтому в один момент времени в базе может присутствовать несколько ревизий одного и того же документа. Ко всем ревизиям имеется доступ через API.
Периодически запускается процесс уплотнения БД, который создает новый файл БД и переносит в него не все, а только последние ревизии документов, т. То есть при уплотнении старые ревизии документов удаляются. Сколько именно ревизий следует оставлять, а также параметры планировщика уплотнений указывают в конфигурации сервера «Енисея».
На каждом из серверов «Енисея», между которыми настроена репликация одной и той же БД, могут быть свои параметры уплотнения. Поэтому, например, один из серверов, с целью сохранить более полную историю изменений, может вообще не выполнять уплотнение автоматически, а только по запросу от внешней системы, или администратора.
Периодически запускается процесс уплотнения БД, который создает новый файл БД и переносит в него не все, а только последние ревизии документов, т. То есть при уплотнении старые ревизии документов удаляются. Сколько именно ревизий следует оставлять, а также параметры планировщика уплотнений указывают в конфигурации сервера «Енисея».
На каждом из серверов «Енисея», между которыми настроена репликация одной и той же БД, могут быть свои параметры уплотнения. Поэтому, например, один из серверов, с целью сохранить более полную историю изменений, может вообще не выполнять уплотнение автоматически, а только по запросу от внешней системы, или администратора.
При сохранении JSON-данных в файлы действительно работает сжатие. Уровень сжатия указывается в конфигурации серверов.
В реальных проектах хорошей тактикой будет исключение на прикладном уровне возможности одновременного изменения одного и того же документа в разных узлах системы. Существует множество более правильных альтернативных подходов к структурированию информации в NoSQL-системах, которые можно использовать вместо постоянного обновления одного и того же документа.
Несмотря на это, «Енисей» полностью обеспечивает режим работы с данными, указанный в данном вопросе. Документ можно произвольно менять одновременно в разных частях системы. При изменении документа обязательно указывается номер ревизии, на основе которой выполняется изменение. Затем, когда выполняется синхронизация данных между серверами, возможно возникновение конфликтов, т. е. ситуаций, когда присутствует несколько изменений, выполненных на основе одной и той же базовой ревизии. В этом суть классического MVCC-подхода, который используется в «Енисее», так же как и во многих других СУБД. Способы разрешения конфликтов описаны в ответе на предыдущий вопрос.
Основной концепцией «Енисея» является сохранение постоянной доступности сервиса и отсутствие блокировок. В соответствии с CAP-теоремой, обеспечивается это за счет возможной неконсистентности данных. «Енисей» обеспечивает «„согласованность в конечном счете“» (Eventual Consistency).
Несмотря на это, «Енисей» полностью обеспечивает режим работы с данными, указанный в данном вопросе. Документ можно произвольно менять одновременно в разных частях системы. При изменении документа обязательно указывается номер ревизии, на основе которой выполняется изменение. Затем, когда выполняется синхронизация данных между серверами, возможно возникновение конфликтов, т. е. ситуаций, когда присутствует несколько изменений, выполненных на основе одной и той же базовой ревизии. В этом суть классического MVCC-подхода, который используется в «Енисее», так же как и во многих других СУБД. Способы разрешения конфликтов описаны в ответе на предыдущий вопрос.
Основной концепцией «Енисея» является сохранение постоянной доступности сервиса и отсутствие блокировок. В соответствии с CAP-теоремой, обеспечивается это за счет возможной неконсистентности данных. «Енисей» обеспечивает «„согласованность в конечном счете“» (Eventual Consistency).
Параметры серверов зависят от особенностей проекта, в котором используется «Енисей». На ряде инсталляций достаточно и сервера с двумя2 ядрами и 2 ГБ памяти. Оптимальным вариантом для достижения «Енисеем» высоких скоростей записи и выборок данных мы считаем сервер с 32 ядрами и 32 ГБ RAM.
В «Енисее» есть понятие «зона размещения данных». В случае необходимости размещения одной БД в нескольких дата-центрах в свойствах базы можно указать, сколько реплик каждой шарды будет находиться в каждом из дата-центров. Обращаться при получении или обновлении данных можно на любой из серверов кластера. Таким образом, доступ к данным гарантируется при любых инфраструктурных отказах. В период отсутствия связности между дата-центрами все данные остаются полностью доступными для любых изменений в каждом из дата-центров отдельно. После восстановления связности «Енисей» автоматически выполнит синхронизацию данных, в ходе которой возможно возникновение конфликтов данных (это неотъемлемое свойство MVCC-технологии).
Либо может быть использован другой способ: в каждом ДЦ создается своя БД, между которыми организуется двунаправленная master-master- репликация.
Либо может быть использован другой способ: в каждом ДЦ создается своя БД, между которыми организуется двунаправленная master-master- репликация.
Шардирование —- это обычное свойство всех БД под управлением «Енисея», так как он изначально создавался для работы с большими данными, которые по определению не помещаются на одном сервере. Даже по умолчанию база создается в режиме: три шарды, две реплики. Шардирование работает по хешу от идентификатора документа, таким образом, данные автоматически равномерно распределяются между шардами. Однако с помощью элементарной конфигурации можно обеспечить и ручное распределение данных, указать для базы, какие ее части должны быть размещены на каком именно сервере кластера. Кроме того, поддерживается функционал «партиционирования,» — это почти то же самое, что и шардирование, только на основе пользовательского признака, а не по ID документа. С помощью партиционирования можно гибко управлять размещением данных с целью более рационально использовать оборудование, или повышение производительности доступа.
REST API «Енисея» имеет методы для администрирования кластера и перераспределения БД между его узлами. Их вызовы достаточно легко автоматизируются. Методыа не представляют никакой сложности и подробным образом описаны в документации.
«Енисей» имеет единственный интерфейс — HTTP REST, п. Поэтому подходят, в принципе, любые балансировщики HTTP протокола, н. Например, Traefik или HAProxy. В нашем варианте поставки «Енисея» под контейнерную платформу Imagenarium используется Traefik.
Бэкап может быть реализован двумя способами: — либо репликацией базы на отдельный сервер, либо простым копированием файлов БД на диске. Копирование файлов выполняется без остановки сервера, данные при этом гарантированно останутся консистентными. «Енисей» имеет такую архитектуру, при которой будет обеспечена консистентность данных даже при крешах OC, или физическом выключении сервера в любой момент времени.
Имеется поддержка вызова пользовательских сценариев после выполнения операции уплотнения БД. Эта функция может быть использована для автоматизации сохранения бэкапов БД.
Имеется поддержка вызова пользовательских сценариев после выполнения операции уплотнения БД. Эта функция может быть использована для автоматизации сохранения бэкапов БД.
Для работы с «Енисеем» достаточно обучения в том же объеме, что и для CouchDB. По нашему опыту, в силу особенностей имплементации «, Енисей» имеет очень низкий порог вхождения. Большинству инженеров достаточно краткосрочного знакомства с API «Енисея», для того, чтобы уже можно было начать прототипирование будущего решения.
В «Енисее» имеется механизм аудита БД, который позволяет автоматически фиксировать время и авторство всех изменений каждого их документов. Эта фукнция работает в том числе и при межкластерных репликациях данных.
Опросника нет. На сайзинг влияет множество разных факторов, обсуждаем их отдельно в применении к каждому проекту.
Но у нас есть калькулятор, который позволяет самостоятельно определить параметры серверов и размер кластера, удовлетворяющего определенным показателям входного потока данных.
Но у нас есть калькулятор, который позволяет самостоятельно определить параметры серверов и размер кластера, удовлетворяющего определенным показателям входного потока данных.
С нашей платформой можно легко и быстро перейти от традиционных методов разработки ПО к полностью контейнеризированным решениям. В Imagenarium есть большой выбор инструментов для решения больших задач по упаковке, конфигурированию, тестированию и развёртыванию разрабатываемых программных решений.
Это Java-фреймворк для разработки приложений под Imagenarium. Он позволяет сократить время разработки за счёт использования готовых компонентов, которые упрощают и ускоряют разработку приложений, работающих на нашей платформе.
Оставьте заявку на демонстрацию продукта. Мы свяжемся с вами в течение рабочего дня.
Нажимая кнопку, вы подтверждаете своё согласие с политикой конфиденциальности.
Нажимая кнопку, вы подтверждаете своё согласие с политикой конфиденциальности.
Заинтересовала
СУБД «Енисей»?
СУБД «Енисей»?