СУБД для бизнес-систем.

добавлено: 21 мар 16
понравилось:0
просмотров: 2017
комментов: 0

теги:

Автор: U-gene

Не прошло и трех лет, как в этом блоге появилась новая запись. Однако это не значит, что мы ничего не делали. Из конкретных результатов - лицензионные соглашения с российскими СУБД вендорами: Релекс и ОИТ(он же НИСТ, производит СУБД HyTech). Кроме того стучались в MS, Сколково, и прочие интересные места (разве что до Oracle не дошли). В MS два раза прошли технологические экспертизы: первый раз в украинском, по результатам нас позвали в Киевский бизнес инкубатор EastLabs (дело было в начале 2014-го и мы не решились), второй в российском, мы были приглашены в качестве партнеров на запуске 2014 сервера, дальше дело пока не двинулось. Есть успехи по Сколково, с третьей попытки в прошлом году мы одолели концептуально-идейную часть, их эксперты признали наши преимущество перед мировыми аналогами, новизну, реализуемость, коммерческий потенциал, и т.п., но срезали по требованиях к команде. Конечно, мы контачили со многими инвесторами, фондами и т.п. и нам показалось, что они ориентированы на получение прибыли в максимально короткий срок и ориентируются в первую очередь на модные тренды, на В2С сегмент. В общем, это нормальный тернистый путь к успеху, для которого нам не хватает выхода на рынок рабочей RxO СУБД. ОиТ и РЕЛЭКС маловаты, и пока просто не могут выделить достаточного кол-ва ресурсов для быстрого внедрения, да и не до жиру им сейчас.

Поэтому, как в кино, в конце концов прозвучала фраза "если хочешь что то сделать хорошо, сделай всё сам". Мысль эта возникла не только что, мы уже достаточно серьезно проанализировали разные СУБД с открытым кодом на предмет использования их как основы для RxO СУБД , и в конце концов склонились в FIREBIRD. Она, конечно, не настолько мейнстрим как тот же PostgreSQL, с другой стороны у нее куча сестер (включая глобальные коммерческие и российские сертифицированные), более-менее внятный С++ код без особых археологических напластований, несколько плюшек внутри, которыми мы хотим воспользоваться, и, что для нас важно, это просто реляционная СУБД без особых концептуальных наворотов поверху этой простоты. Мы очень надеемся, что возможности, которые мы хотим в ней реализовать, значительно увеличат аудиторию её пользователей. Я реанимировал этот блог, что бы рассказывать о нашей работе. Точнее не рассказывать, а говорить, благо формат позволяет вести общение.

Однако сначала надо все-таки уточнить, о каких таких возможностях идет речь, для чего вообще нужна RxО СУБД . И здесь я хочу сказать, что все эти многочисленные контакты, с которых я начал этот пост, и даже вопросы-ответы в этом блоге, заставили меня понять, что мои предыдущие разговоры про "объекты и отношения" понятны исключительно узкому кругу специалистов. Более того, в этом узком круге они могут вызвать совершенно неожиданные и, порой, даже неприятные реакции. Например, когда я озвучил эту тему известному PG-гуру, он сразу же отреагировал словами, что в PostgreSQL всяки-разны ОО-фишки давно уже есть, никто ими практически не пользуется, ничего нового в этом направлении не сделать.... ну а дальше разговор как-то не задался. Сейчас я считаю, что гуру был прав, когда сказал, что нам надо по-другому о себе рассказывать. Дело не в абстрактных объектах и отношениях, а в совершенно конкретных привычках и нуждах пользователей, которые теперь и являются стартовой точкой нашего рассказа о себе.

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

Что бы расставить точки над i и обозначить цель нашей работы, я в несколько приемов выложу здесь текст, который является компиляцией статей, заявок и презентаций, связанных в единую историю, рассказывающая о месте, предназначении, принципах работы и новых возможностях нашей системы. Речь ни в коем разе не идет о какой-то глобальной серебряной пуле. Однако, исходя из собственного опыта, из проблем и вопросов специалистов (многие из которых многократно озвучены на SQL.RU) и из полученных отзывов, я практически уверен, что она может облегчить жизнь достаточно большому числу и разработчиков, и пользователей, особенно когда речь идет о небольших или средних решениях. Очень интересно мнение SQL.RU-шников обо всем этом. Букв много и я очень прошу, дочитайте до конца, возможно, там найдутся ответы на вопросы, которые у вас могут возникнуть сначала. Текст может показаться суховатым - причина в том, что многие фрагменты выдернуты из статей, которые готовились для журналов и конференций, а том очень строго с объемом. Итак...


СУБД для бизнес-систем.


Информационные бизнес-системы (далее ИБС) используются в таких традиционных сферах как финансы, продажа и маркетинг, закупки и цепочки поставок, транспорта и склада, проекты, бизнес-анализ, персонал и т.п. Это
• известные готовые "коробочные" ERP-системы, например, SAP R3, MS Dynamics ERP (Navison и Axapta), 1C, которые предлагают готовые конфигурации, допускающие адаптацию под нужды пользователей,
• "заказные" корпоративные системы, создаваемые под конкретные нужды заказчиков.

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

Традиционная архитектура ИБС подразумевает использование реляционной СУБД, роль которой сводиться к хранению данных. Функции описания модели бизнеса (модель предметной области или domain model[]) и обработка данных выполняется вне СУБД - в клиентской программе, либо на сервере приложений. Исторически, такое положение дел возникло в связи тем, что реляционные СУБД являются результатом эволюции систем управления медленными, внешними устройствами хранения данных (управление дисками и лентами –> файлы - > базы данных -> СУБД). Долгое время аппаратных возможности серверов едва хватало для реализации базовых функций СУБД (хранение данных, многопользовательский доступ, поддержка транзакций, защита данных). В таких условиях создание внешнего слоя для обработки данных является, по сути, единственным способом построения полноценной ИБС.

Многоуровневая архитектура привело к появлению такой же многоуровневой иерархии программистов и пользователей. Системные программисты создают СУБД, которые используются разработчиками ИБС, которые, в свою очередь, реализуют требования программистов-внедренцев и, в конечном итоге, пользователей ИБС. В этой цепочке специалисты крайне ограничены в возможностях внести изменения уровнем ниже. С другой стороны, создатели СУБД ориентируются на требования разработчиков ИБС и, как нам кажется, не очень четко представляют себе реалии, с которыми имеют дело их конечные пользователи (об этом далее). Такое "расслоение" специалистов является не только следствием, но теперь уже и одной из причин, поддерживающих существование многоуровневой архитектуры.

Очевидно, что эта архитектура является источником значительных проблем, а именно
• Как любые многоуровневые системы, они сложны для создания, изменения и поддержки.
• Необходимость обрабатывать данные вне СУБД приводит к катастрофическому снижению производительности, связанному с неоптимальным (и трудно оптимизируемым) обменом данными между слоями. Простейшие действия в МБ могут сопровождаться сотнями и тысячами мелких запросов к используемой БД. Масштаб бедствия можно оценить по тому факту, что перенос обработок данных на сторону СУБД может ускорить их в десятки и сотни раз. К сожалению, сегодня такая оптимизация может выполняться только вручную. Она требует высокой квалификации и еще более усложняет(tundle) систему.
• Затрудняется интеграции с другими программами (например, MS Excel), использующими стандартные средства доступа к данным в СУБД (например ODBC). Схема данных, сформированная внешним слоем в СУБД, обычно недоступна или непонятна для бизнес-пользователя, а стандартные способы доступа к внешнему уровню, где реализована бизнес-модель, как правило, отсутствуют.

Мы не утверждаем, что традиционная архитектура является неправильной или плохой. Однако со времени ее формирования условия принципиально изменились.
• Благодаря прогрессу в области аппаратуры, возможности современных серверов стали превосходить потребности СУБД, используемых в ИБС. Никого уже не удивляют машины с десятками процессорных ядер и с ОЗУ, размер которой значительно превышает размер пользовательских БД. Эти изменения уже привели к возникновению in-memory СУБД, где данные полностью размещается в оперативной памяти. Такие СУБД показывают значительное увеличение производительности, однако очевидно, что это никак не избавляет от проблем, связанных с обменом данными между слоями системы.
• Основной тенденцией в области ПО является появление принципиально новых задач, для решения которых были созданы принципиально новые СУБД (NoSQL, XML, научные СУБД). Специализированные СУБД в силу своей эффективности становятся следующим шагом эволюции систем хранения данных.

Изменившиеся условия позволяют расширить выбор потребителей, предложив им альтернативу традиционной архитектуре. Её центральным звеном является СУБД, которая является специализированным расширением традиционных реляционных СУБД и обладает рядом возможностями, важными для пользователей ИБС. Главная особенность этой СУБД заключается в том, что она реализуют известный по множеству существующим ИБС и понятный для бизнеса принцип создания сложных моделей бизнеса непосредственно в СУБД.

Модель бизнеса.

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

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

Попытаемся перечислить основные свойства, которыми должна обладать "хорошая" система моделирования бизнеса:
Выразительность означает, что любой из сущностей, образующей бизнес, в системе соответствует понятный информационный объект, который может быть связан с другими объектами понятными связями, а любому из бизнес-процессов - понятный элемент функционала (функция, процедура или метод), выполняющие согласованное изменения частей системы. Слово "понятный" здесь означает, что метаданные, описывающие все эти объекты, связи и элементы функционала, несут в себе соответствующую семантику моделируемого бизнеса в виде используемых бизнес-пользователем понятий и терминов. Это свойство крайне важно, поскольку позволяет создать в информационной системе полную, точную и ясную для пользователя модель бизнеса.
Гибкость позволяет пользователю в любой момент времени модифицировать МБ, добавлять описание новых сущностей и процессов, изменять существующие (ones) и удалять ненужные(ones), не прерывая при этом существования этой МБ, не лишая других пользователей доступа к ней.
Персистентность является базовым свойством всех частей МБ. Это свойство позволяет создать долгоживущие МБ, которые накапливают и хранят данные о сущностях, фактах и произведенным операциях.
Открытость означает, что должны существовать возможности для доступа к МБ разными пользователями. Использованием стандартных протоколов, интерфейсов доступа и/или инструментов (например MS Excel) без привлечения системных программистов, делает МБ более открытой.
Защищенность означает, что доступ к МБ должен регулироваться в соответствии в установленными приоритетами, также необходимо обеспечивать устойчивость к разного рода сбоям.

В большинстве современных ИБС, МБ существует в выделенном архитектурном слое, на уровне сервера приложения. Современные ИБС реализует многопользовательский доступ, при этом система позволяет устанавливать и контролировать права доступа к частям МБ. Так же ИБС реализуют механизм транзакций, необходимых для согласования частей МБ при её изменении. Очевидно, что эти возможности по созданию и использованию MB во многом дублируют механизмы традиционных РСУБД, которые очень схожим образом позволяют описать схему данных, создать хранимые процедуры и функции, реализуют многопользовательский доступ и транзакции. Часто эти возможности реализуются в ИБС с вовлечением соответствующих механизмов используемых СУБД (этот факт, как правило, скрыт от пользователей), однако сложность МБ в любом случае ведет к необходимости, по крайней мере, координировать действия на уровне, где эта модель реализована, т.е. на уровне сервера приложений. Можно сказать, что возможностей реляционных СУБД почти достаточно для создания "хорошей" модели бизнеса. Единственным серьезным исключением является выразительность.

Сложность МБ и присущий реляционным СУБД недостаток выразительности является еще одной причиной, почему МБ существуют вне СУБД[]. Эксперты в области СУБД на протяжении многих лет пытаются преодолеть этот недостаток. В свое время они проявили редкостное единодушие, когда рассматривали объектно-ориентированный подход как своего рода панацею для увеличения выразительности позволяющую удовлетворить требования бизнеса. За последние 25 лет сделано большое число различных попыток реализовать ОО подход в реляционных СУБД. . В этой статьи мы будем рассматривать только те предложения, которые подразумевают эволюционное развитие реляционных СУБД. Все предложенные решения, так или иначе, сводятся к двум вариантам соединения объектов и отношений:
• объекту соответствует строка таблицы БД ("объект = строка"). Например, экземпляры объектных типов хранятся у Oracle в специальной типизированной таблице, где каждому экземпляру соответствует одна единственная строка.
• объекту соответствует поле в строке таблицы БД ("объект = поле"). Наиболее ярким примером логического использования этого принципа является экспериментальный язык "D"[]. Существует и чисто технологические реализации этого принципа, когда для хранения объектов могут использоваться BLOB, JSON и т.п. поля, при этом для манипуляций данным внутри таких полей требуются внешние языки и инструменты.
В любом случае объекты хранятся "внутри таблиц" (как строки, либо как поля строк). В целом, схема БД остается чисто табличной (и, в этом смысле, гомогенной).

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

Базовый принцип построения объектов в ИБС можно обозначить формальным уравнением "объект = реляционная БД". В этом уравнении мы исходим из того, что любое подмножество кортежей отношения можно рассматривать как отношение. Объекту соответствует "множество строк разных таблиц", т.е. множество таких отношений. В свою очередь, фраза "множество отношений" является ключевым элементом формального определения реляционной БД.

Этот базовый принцип используется во всех ИБС на протяжении десятилетий. Можно предположить, что именно он наиболее полно соответствует потребностям бизнеса и именно он должен быть в первую очередь реализован в СУБД, которая подходит для ИБС. Однако попытки создать такую СУБД до сих пор отсутствовали. Более того, складывается впечатление, что эта возможность не рассматривается даже теоретически[].

Как нам кажется, объектные расширения "внутри таблиц", предложенные создателями ОРСУБД, не востребованы в первую очередь потому, что они не учитывают реальные требования бизнес-пользователей. Эти расширения не создают привычную для пользователей МБ в самой БД. С другой стороны, использовать их в традиционных ИБС, которые, с точки зрения пользователя, и так обладают достаточной выразительностью, вообще не имеет смысла. Таким образом, объекты, которые не являются частью сложной, активной и удобной МБ, не нужны бизнесу - даже если они являются персистентными. К тому же, как нам кажется, объекты в традиционных ООЯП и в объектных расширениях РСУБД, созданных с оглядкой на эти ООЯП, лишены важных возможностей, которые позволили бы эффективно использовать их в долгоживущих МБ (об этом - далее).

Мы предполагаем, что СУБД, реализующая описанные выше принципы построения МБ, позволит принципиально упростить общую архитектуру ИБС, в том числе избавиться от избыточного обмена данных между слоями системы и от проблем, связанных с этим обменом. Мы называем ее RxO СУБД. Некоторые из излагаемых идей были реализованы в прототипе "RxO system"; его входные команды мы будем использоваться для демонстрации.

Продолжение следует...

Комментарии




Необходимо войти на сайт, чтобы оставлять комментарии