Базы данных — иной взгляд

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

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

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

Вертикальное vs горизонтальное масштабирование

Такие базы данных хорошо приспособлены для «вертикального» масштабирования, то есть последовательного наращивания таблиц за счет добавления новых строк. Вертикальное масштабирование на физическом уровне — это просто еще более мощный сервер, еще более крупный диск. Но когда счет данных идет на петабайты, ни один, пусть и «очень большой», сервер с такими объемами не справится. И тогда придется задуматься о «горизонтальном» масштабировании, то есть дроблении базы на фрагменты.

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

Накопившийся объем данных становится слишком велик, чтобы работать на одном сервере, необходимо разнести его на несколько нод (node). К тому же, чем дальше, тем труднее проводить в базе операции, которые не сводятся к простому «поиск/запись/удаление». Пример — полнотекстовый поиск. Хоть он и реализован в базах данных на основе SQL, их функциональности может быть недостаточно, когда число разносортных запросов начинает сильно расти.

Жёсткая конфигурация — ещё один барьер

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

А как ещё можно организовывать данные в базе? Если всерьёз задаться этим вопросом, то обнаружится, что реляционная модель подходит отнюдь не для всех задач. В ней действует единая модель доступа к любому значению: системе надо знать название самой таблицы, значение первичного ключа (его аналог — номер строки) и название столбца. Значит, все записи должны быть стандартизированы.

В общем, реляционная модель — это одна из возможностей работы с данными, и нельзя наращивать бесконечно только одну парадигму. Рано или поздно выявятся проблемы, которые она решить не может, потому что не обладает достаточной гибкостью работы с данными. Что мы сейчас и наблюдаем в постоянных сбоях и недоступности ГИС (государственных информационных систем).

Многомерная структура данных — математически идеальная модель

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

В настоящее время имеются готовые СУБД приложения, поддерживающие многомерные структуры данных, например: Cache (производитель Intersystems), GT.M (производитель FIS-GTM), YottaDB (открытое сообщество) и другие системы, в основном работающие на стандарте MUMPS. Такие системы обладают огромной производительностью, надёжностью, масштабируемостью и гибкостью. Они прекрасно работают в США на таких ответственных направлениях, как: банковский сектор, медицина и оборонная промышленность и прекрасно зарекомендовали себя за долгие годы работы как надёжные, высокопроизводительные системы, способные работать с любыми объёмами данных.

Наш подход к проектированию

При выборе подхода к проектированию нашего продукта мы решили использовать множество парадигм структур баз данных, т.к. это подходит для выполнения всех видов задач независимо от требований к производительности, объёму, надёжности и масштабируемости СУБД. Для этого был выбран способ хранения данных в виде B*деревьев, а доступ к данным обеспечен с помощью стандартизированного языка программирования MUMPS.

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

Наши наработки в этом направлении

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

Преимущества нашей СУБД ГЛОБАЛ

• Отечественная разработка. Входит в реестр отечественного программного обеспечения.
• Быстродействие. Не уступает зарубежным аналогам, таким как ORACLE и MSSQL, а в специализированных задачах в разы превосходит по скорости записи.
• Надёжность. Встроенный механизм многоуровневого журналирования обеспечивает высокую надежность, отказоустойчивость и целостность транзакций БД.
• Простота установки и обслуживания. Для выполнения всех необходимых операций достаточно базовых знаний администратора *nix систем.
• Гибкость в использовании оборудования. Возможно использование как на стандартных ПК, так и на многопроцессорных аппаратных платформах.
• Экономия дискового пространства. Данные занимают меньше места на диске по сравнению с реляционными системами.
• Высокая нагрузка. Предназначена для применения в высоконагруженных и информационно ёмких проектах.
• Многомерность. Работа с данными в виде многомерных массивов информации позволяет строить очень сложные системы аналитики.
• Открытость. Работает на ОС семейства Linux (открытое и бесплатное программное обеспечение).