СУБД «Енисей» в контексте современных потребностей

«А зачем нужна NoSQL СУБД в стеке современных информационных систем?» — вопрос, который нам задают чаще всего. Отвечаем.

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

В первую очередь мы рассматриваем самую крупную группу заказчиков — государственный и квазигосударственный сектора и крупный бизнес. В их среде востребован Oracle и подход «одна СУБД», если проще, то Oracle все вынесет, а если не вынесет, купим Exadata, и она точно вынесет. Все данные, т.е. вообще все, которыми оперирует и которые хранит информационная система, сваливаются в одну СУБД, в ней же, как правило, определяют логику их обработки на Pl/SQL.

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

И вот у нас есть два подхода. Первый — «одна СУБД на все задачи», в котором используются СУБД широкого назначения, к которым относится тот же Oracle или PostgreSQL, набирающий популярность в РФ как решение для миграции с Oracle. Второй — распределенный слой хранения данных, в котором применяется, как правило, СУБД двух типов: реляционная и NoSQL.

В данной статье мы не будем рассматривать вопрос миграции «один-к-одному» с Oracle на PostgreSQL. Иначе пришлось бы обсуждать, зачем, раз такое возможно, тратили деньги на Oracle в свое время и не построили систему сразу на PostgreSQL.

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

Фактор, напрямую влияющий на скорость работы любой серьезной системы, — скорость работы ее слоя хранения данных. Она напрямую связана с объемами данных, которые данный слой должен хранить и обрабатывать. В основе подхода, который мы назвали «ТриоДата», лежит распределение объема данных информационной системы между СУБД двух типов в соответствии с их целевым назначением, и применение полнотекстового поискового индекса для работы с ними. Три столпа: SQL, NoSQL и поисковый индекс, позволяют создать слой хранения данных любого объема, с отличными возможностями масштабирования и серьезным снижением эксплуатационных издержек.

Итак, зачем нам NoSQL? Прежде всего, для хранения данных NoSQL, к которым относятся:

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

JSON — это формат обмена данными, максимально широко распространенный в настоящее время. Подавляющее большинство информационных систем используют данный формат в RESTFul API и, соответственно, в оперативной обработке данных, поступающих в информационную систему, и зачастую для их долговременного хранения. Поддержка JSON реализована во многих СУБД широкого назначения, где он представлен данными особого типа, даже с возможностью индексация полей JSON и пр. Тем не менее это не их нативный формат и функционал. СУБД, изначально разработанные для работы с JSON, например «Енисей», будут справляться с данной работой, очевидно, эффективнее. Работа с JSON в реляционных СУБД появилась точно так же, как и функция хранения бинарных данных, для удовлетворения потребностей разработчиков и заказчиков. Первые не хотят рассматривать специализированные решения, особенно в контексте развития существующих систем, вторые поддерживают их, экономя на лицензиях для специализированных СУБД.

Кроме того, JSON —формат сериализации объектов, и, например, «Енисей» предоставляет возможность хранения состояния объектов в БД, с применением подхода объектного-документного мэппинга (ODM), который намного эффективнее в части производительности по сравнению с более распространенным объектно-реляционным (ORM).

Получается, что при миграции с Oracle или построении системы с нуля оптимальное решение — перенести бинарные данные и JSON-документы и сообщения в NoSQL СУБД, и «Енисей» отлично справится с этой задачей. Тем самым вы существенно облегчите PostgreSQL, который как реляционную систему вы выберете свой технологический стек с вероятностью 99%.

Рассмотрим хранение объектов в виде JSON. Сторонники ORM скажут, что JSON займет больше пространства на диске. Да, это так. Стоит отметить, что при этом производительность вашей системы вырастет минимум на 20%, а в зависимости от сложности объекта и количества операций чтения записи — и до 50%. При сериализации в JSON объект сохраняется как один документ одной операцией записи, при этом асинхронно, так как «Енисей» — это append-only СУБД.В случае сохранения объекта с ORM в реляционную структуру из группы таблиц, он сохраняется в рамках транзакции, при обработке которой «кусочки» объекта раскидываются по нескольким таблицам. В случае объектного хранения в JSON при выборке объекта из БД и десериализации читается один документ, и мы получаем объект; в случае ORM осуществляется операция чтения с JOIN группы таблиц, где хранится состояние объекта.

Если нужно выбрать: увеличить объем хранимых данных не только без деградации производительности, но и с ее существенным приростом или наблюдать за постепенной деградацией системы, — все очевидно. Есть множество достаточно известных примеров, построенных на базе ORM, показывающих драматичную деградацию производительности при росте данных. Часть их них, работая на Oracle более-менее справляется, потому что он многое прощает, даже кривую архитектуру и неоптимальный код работы с данными. При попытке убрать из этих систем Oracle пользователи понимают, что тогда у них нет возможности работать с большими данными. С ODM у вас не будет таких проблем, здесь нет блокировок, с которыми вы столкнетесь, запуская интенсивные операции чтения-записи в ORM-решениях.

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

Последний штрих к портрету — поисковый индекс. Документы, поступающие в СУБД «Енисей», индексируются поисковым движком Lucene, попросту говоря, это такой Google по данным в БД.

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

Предлагаемая архитектура «ТриоДата» позволяет гарантированно провести миграцию с Oracle или MS SQL. Это решение, которое мы используем в своей практике более 10 лет, работая с проектами национального масштаба. Оно отлично себя зарекомендовало с точки зрения как разработки, так и эксплуатации. СУБД «Енисей» создана именно в условиях разработки подобных систем, как часть стека «ТриоДата».

На первый взгляд, предлагаемое решение выглядит сложнее в плане инфраструктуры: вместо одной СУБД целых две. Но есть ли другие варианты? Если вы использовали Oracle по-настоящему и у вас много данных и высокая нагрузка, ответим сразу: других вариантов у вас нет. Их нет и при разработке высоконагруженных систем с нуля. Точнее, есть вариант попробовать по-другому, но потом сделать все правильно, когда по-другому не получится.

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