Фирма ООО «ЦППБ АТОЛЛ», разработчик отечественного программного обеспечения, специализирующая на работе с базами данных, предлагает взглянуть на проблему работы с данными (с большими данными) несколько под другим углом, не принятому в массовых кругах разработчиков.
Если взглянуть на все чаще возникающие проблемы с большим количеством данных, их хранением и доступностью, то напрашиваются выводы о том, что реляционные модели данных, употребляемые сейчас почти в любом отечественном государственном информационном ресурсе, не справляются с поставленными задачами резкого увеличения объемов информации и доступности её большому потоку пользователей.
В момент создания и активного развития реляционной модели данных сложно было представить, на сколько в будущем вырастут объемы информации, подлежащей хранению. Поэтому не удивительно, что сейчас реляционные базы уже не годятся для постоянно меняющихся и быстрорастущих проектов.
Такие базы данных хорошо приспособлены для «вертикального» масштабирования, то есть последовательного наращивания таблиц за счет добавления новых строк. Вертикальное масштабирование на физическом уровне — это просто еще более мощный сервер, еще более крупный диск. Но когда счет данных идет на петабайты, ни один, пусть и «очень большой», сервер с такими объемами не справится. И тогда придется задуматься о «горизонтальном» масштабировании, то есть дроблении базы на фрагменты.
Для горизонтального распределения реляционная модель, в общем, приспособлена уже не так хорошо. Конечно, вы можете один раз физически разделить большую базу данных на 10 баз поменьше. Но в какой-то момент нагрузка на них опять разбалансируется, и данные снова придется «перетасовывать». Потребуется писать «надстройки», сочетающие в себе привычный SQL-синтаксис с более продвинутой и динамичной моделью горизонтального масштабирования.
Как только сервис упирается в проблему масштаба, меняется все. В частности, возникают проблемы с «железом» и «софтом». Серверы больше не помещаются в серверную и едут на отдельную хостинговую площадку, а простой и надежной модели бэкенда по принципу «сервер крутит базу данных» становится недостаточно.
Накопившийся объем данных становится слишком велик, чтобы работать на одном сервере, необходимо разнести его на несколько нод (node). К тому же, чем дальше, тем труднее проводить в базе операции, которые не сводятся к простому «поиск/запись/удаление». Пример — полнотекстовый поиск. Хоть он и реализован в базах данных на основе SQL, их функциональности может быть недостаточно, когда число разносортных запросов начинает сильно расти.
Из-за числа запросов и сам по себе доступ к базе данных превращается в «бутылочное горлышко», и для решения этой задачи приходится создавать отдельный сервис.
Еще одна проблема у реляционной модели данных—это жесткая конфигурация. Она предполагает, что каждая запись (строка) в базе имеет определенное число полей (по числу столбцов).
А как еще можно организовывать данные в базе? Если всерьез задаться этим вопросом, то обнаружится, что реляционная модель подходит отнюдь не для всех задач. В ней действует единая модель доступа к любому значению: системе надо знать название самой таблицы, значение первичного ключа (его аналог — номер строки) и название столбца. Значит, все записи должны быть стандартизированы.
На практике это означает, что пока все параметры стандартны, проблем не возникнет. Но если в базе внезапно появится элемент с несколькими характеристиками, которых в ней до этого не было, всю базу данных придется полностью переделать. Получается, что гибко работать с такими задачами реляционная модель не способна.
В общем реляционная модель - это одна из возможности работы с данными, и нельзя наращивать бесконечно только одну парадигму. Рано или поздно выявятся проблемы, которые она решить не может, потому что не обладает достаточной гибкостью работы с данными. Что мы сейчас и наблюдаем, в постоянных сбоях и недоступности ГИС-ов (государственных информационных систем).
Как известно, многомерная структура данных является идеальной математической моделью для работы с данными. С помощью такой модели можно выйти на любую конструкцию данных: реляционная, иерархическая, сетевая и прочее. Таким образом, можно достигнуть максимальной гибкости при построении различных структур данных. В настоящее время имеются готовые СУБД приложения, поддерживающие многомерные структуры данных, например: Cashe(производитель Intersystems), GT.M (производитель FIS-GTM), YottaDB (открытое сообщество) и другие системы, в основном работающие на стандарте MUMPS. Такие системы обладают огромной производительностью, надёжностью, масштабируемостью и гибкостью. Они прекрасно работают в США на таких ответственных направлениях, как: банковский сектор, медицина и оборонная промышленность и прекрасно зарекомендовали себя за долгие годы работы как надёжные, высокопроизводительные системы, способные работать с любыми объёмами данных. Кстати, с введением санкций против РФ, сайт производителя FIS-GTM стал недоступен для жителей России, что говорит о стратегическом уровне данной технологии.
Наша компания уже давно работает с подобными системами и имеет свои наработки в этой области. Нами создана многомерная система управления базами данных СУБД М10, обладающая высокой производительностью и надёжностью. На базе данного продукта разработаны и внедрены ряд крупных проектов для государственного сектора. Ведётся дальнейшая работа на повышение качественных характеристик нашего продукта с целью увеличения рынка сбыта.
База данных СУБД М10 входит в реестр отечественного ПО. Основана она на открытой и доработанной нами системе GT.M (производитель FIS-GTM).
При выборе подхода к проектированию нашего продукта (СУБД М10) мы решили использовать множество парадигм структур баз данных, т.к. это подходит для выполнения всех видов задач не зависимо от требований к производительности, объёму, надёжности и масштабируемости СУБД. Для этого был выбран способ хранения данных в виде B*деревьев, а доступ к данным обеспечен с помощью стандартизированного языка программирования MUMPS. Исходя и этого, мы получили очень быструю, многомерную структуру данных, способную на высокую масштабируемость, и удобный инструмент для их манипулирования. С помощью СУБД М10, используя встроенные библиотеки и обладая возможностью быстро написать свои, можно, исходя из поставленной задачи, применить наиболее подходящую структуру хранения данных и метод доступа к ним. Благодаря такому подходу вы можете выбрать нужную вам производительность СУБД и её надёжность.
Наши наработки в этом направлении:
Доработанное ядро СУБД.
Существует визуальная среда работы с данными.
Разработан универсальный шлюз для взаимодействия с другими системами.
Разработаны библиотеки для работы непосредственно с B*деревом базы для языков Си и PHP. Что позволяет полноценно создавать любые системы любых масштабов.
Разрабатывается свой язык программирования для работы с данными для замены устаревшему MUMPS.
Есть наработки полностью изменения ядра СУБД (уход от открытого GT.M).
На нашей базе уже успешно работают ряд систем в государственных структурах.
Создана специализированная система Сбора статистики с подведомственных организаций, которая позволяет быстро организовать сбор данных, не прибегая к программированию.
В России данная технология достаточно распространена и успешно используется в медицинских системах, а также биллинговых системах операторов связи.
Преимущества нашей СУБД М10:
Отечественная разработка. Входит в реестр отечественного программного обеспечения.
Быстродействие. Не уступает зарубежным аналогам, таким, как ORACLE и MSSQL и т.п., а в специализированных задачах в разы превосходит по скорости записи (из-за особенности внутренней архитектуры данных).
Надёжность. Встроенный механизм многоуровневого журналирования при работе с данными обеспечивает высокую надежность и отказоустойчивость хранения данных, а также целостность транзакций БД.
Простота установки и обслуживания. Для выполнения всех необходимых операций достаточно базовых знаний администратора *nix систем.
Гибкость в использовании аппаратного обеспечения. Возможно использования как на стандартных персональных компьютерах, так и на многопроцессорных аппаратных платформах.
Данные занимают меньше места на диске по сравнению с реляционными системами.
Предназначена для применения в высоконагруженных и информационно ёмких проектах.
Работа с данными в виде многомерных массивов информации. Позволяет строить очень сложные системы аналитики.
Работает на ОС семейства Linux (открытое и бесплатное программное обеспечение).
