serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Об инерции мышления
serge_gorshkov
Сегодня участвовал в одной конференции, на которой познакомился с третьим по счету MDM-решением, которое использует отчасти семантическое, по принципу организации данных, хранилище, но держит его в реляционной базе.
Инерция мышления - потрясающая вещь. С тем же успехом можно выпустить автомобиль, но впереди все-таки запрячь лошадь вместо двигателя.
Впрочем, в увиденном есть плюсы:
 - То, что MDM не может быть в чистом виде реляционной базой, стало мейнстримом :) И теперь я могу всем говорить, что утверждал это еще раньше :)
 - Лучше делать такие MDM, чем не делать вообще никаких.
 - Мы первые, и пока единственные, по крайней мере в России, обладатели семантического MDM на семантическом же хранилище.

Почему я не сижу с этим фактом втихомолку, а, наоборот, всегда готов просветить коллег? Потому, что мы ушли весьма далеко вперед от простой идеи использовать для MDM семантическое хранилище. Например, мы реализовали на нем контроль прав доступа к модели в виде промежуточного логического слоя - это вещь настолько нетривиальная, что вряд ли у кого получится ее сходу воспроизвести. Есть и другие идеи, которые можно будет предъявить рынку в качестве преимущества, когда он способен будет их осознать. Так что бояться за технологическое первенство - нечего.
А вот популяризация на рынке идеи семантического MDM, наоборот, нам выгодна.

  • 1
Если сделать в РБД одну таблицу, то она перестает быть реляционной, но по прежнему хорошо работает (на хабре описывали noSQL сценарий, в котором постгрес отработал лучше, чем noSQL база, не помню какая). В конце концов на железном уровне сводится к линейной записи данных на диск. Если в семантической модели на каком-то этапе таблица удобнее линейной записи, то туда сразу напрашивается РБД. Они давно и успешно отработаны и вообще лапочки. Так что любой другой платформе надо сильно постараться, чтобы работать эффективнее ее эмуляции на РБД с одной - двумя таблицами на 3-4 колонки (не разобрался пока до конца, сколько нужно в семант модели).

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


Вопрос в том, а не будут ли костыли в конкретном MDM быстрее и удобнее, чем универсальный SPARQL, на который еще и лицензия хз сколько стоит и программистов не найдешь. А MSSQL уже есть, отдел ИТ с ним давно работает и уже миллион поделок напилил. Запилит и еще одну.
"Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp[1]" Но это все равно не повод использовать Лисп :)

Edited at 2015-02-27 10:36 am (UTC)

Да, часто бывает что удобнее "костылить" на освоенных технологиях. Но, это скорее как первый подход к снаряду, потому что через некоторое время упираешься в ограничения "бега на костылях", и появляется острая необходимость в инструментах типа SPARQL или WIPE (Graph Exploration & Manipulation language).

Хех. Интересно. Не ожидал, что у нас в России что-то подобное для внутреннего рынка делается. А как это дело продается? Ведь чтобы внедрить, надо не просто мозги переформатировать, а еще и с унаследованными системами что-то делать...

Тема очень актуальна, особенно в свете импортозамещения. И определенный слой заказчиков/ген. подрядчиков уже понял, что сложные системы без MDM+ESB не строятся (не будем вспоминать, через сколько лет после появления этих технологий).
Так что внутренний рынок как раз в определенной степени готов. Что до унаследованных систем, то прелесть предлагаемого нами стека как раз в том, что все старое барахло можно сначала подключить к новому архитектурному ядру, написав адаптеры обмена. А потом, когда общая архитектура системы выстроится - заменить унаследованные системы, передав функции по обработке частей общей информационной модели, которые они выполняли, новому софту.


К примеру, сколько будет стоить интеграция с 1с бухгалтерией и какие тормоза она несет? Что если в разные программы вводятся одни и те же данные по частям, да еще редактируются активно? У вас уже есть те, кто реально купил и перевел все данные на новые рельсы? Обычно я слышу про проекты, где триплсторы с боку привязываются к существующим системам. А чтобы в центре были, я пока не знаю про таких смелых...

Что касается интеграции с 1С - в одном из наших проектов компания 1С:Рарус написала отличный интерфейс мэппинга данных MDM на 1С'ную модель, с возможностью визуальной настройки соответствия сущностей и атрибутов. Работает в обе стороны: если что-то меняется в 1С - она отправляет по шине сообщения в MDM, если меняется в MDM - он уведомляет все системы, включая 1С. Работает.
Список завершенных проектов мы не прячем. На вопросы о цене готов отвечать в личку :) А также делиться подробностями реализации.
Что в середине архитектуры, в качестве хранилища мастер-данных - триплстор или реляционная база - вопрос как раз инерции мышления.

Если говорить об архитектуре, то семантический MDM в центре - это уже ново. Даже если и на реляционке.

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

кто, если не секрет?

Ответил в личку, чтобы никого не рекламировать и не обижать :)

  • 1
?

Log in

No account? Create an account