Ждать ли появления NoECM?
Идея использования нереляционных баз данных в системах Enterprise Content Management обсуждается уже пару лет. Чего можно ожидать от такого альянса.
Темы ECM и СЭД в отечественных реалиях неразрывно связаны (см. Чем еще отличается ECM от СЭД) А потому, вслед
за появлением термина Анти-СЭД было бы логичным ожидать появление термина
NoECM. Идея использования нереляционных баз данных в системах Enterprise
Content Management обсуждается уже пару лет (см. например Alfresco, NOSQL, and
the Future of ECM). Чего можно ожидать от такого альянса.
В первую очередь, конечно, экстремальной масштабируемости хранилища контента. По сути, системы ECM, построенные на нереляционных БД смогут стать тем самым единым хранилищем контента для организации (см. BigData 2012. Время выполнять обещания?).
Во-вторых, мы действительно получим требуемую гибкость при создании необходимых структур данных. Идея открытого формата данных (freeform) реализуется и в реляционных базах данных. Для чего используется шаблон Entity-Atribute-Value (Иногда еще говорят о разворачивании широкой таблицы в столбец). Но делает это каждый разработчик в своей манере. А затем он вынужден решать проблему индексирования некоторого подмножества записей в большой общей таблице. И здесь общего рецепта уже нет. Кто-то делает отдельные таблицы в СУБД, кто-то обращается к записям через внешнюю систему поиска и т.д. В итоге, добавление атрибутов становится сложной задачей, которую не следует поручать заказчику.
Следующее преимущество это интероперабельность. Большое количество разноплановых приложений не может работать с одной реляционной БД. Не стоит, например, в одной и той же базе одновременно сохранять транзакции и строить отчеты. Строгая нормализация данных ведет к тому, что информацию об одном и том же предмете или явлении в разных системах мы храним по-разному. Из-за этого появляется необходимость дорогостоящей и не очень надежной интеграции приложений. Интероперабельность, т.е. способность приложения «встраиваться» в многоуровневую архитектуру избавляет нас от необходимости дополнительной интеграции.
Казалось бы, перспективы безоблачны и разработчики ECM систем очень быстро перейдут на нереляционные базы данных, например документоориентированную MongoDB, позволяющую хранить внтури себя большие файлы (GridFS). Но мне почему-то кажется, что события будут развиваться немного иначе. Разработчики СЭД/ECM слишком консервативны и присматриваться к той или иной NoSQL базе данных они будут достаточно долго. Тем временем программисты, создающие информационные системы на заказ, по требованиям пользователей, освоят нереляционные базы намного быстрее. И к моменту появления NoECM решений корпоративный ИТ-ландшафт будет загроможден большим количеством приложений в архитектуре: нереялционнка плюс тот или иной framework для быстрой разработки окошек поверх неё.
Разумеется это серьезный вызов корпоративной ИТ-архитектуре.
Оригинал: Архитектура информационных систем.
Комментарии 8
Немного непонятно, что такое NoECM? ECM использующая NoSQL базу данных?
По описанию так и выходит.
Но чем NoECM полезнее ECM (если не брать всякие технические детали, типа масштабирования) это не объясняет. Пока что традиционные РСУБД (для метаданных) + файловое хранение (неструктурированных тел) вполне себе спасает от роста объемов.
я копнул немного эту тему (в рамках первой страницы результатов в поисковике). Alfresco может или уже использует NoSQL для своих интернет компонентов, мотивируя это тем, что NoSQL работает по простой выборке данных куда быстрее, чем РСУБД, ну и масштабирование.
А вот какая выгода самой ECM пока неясно.
У Alfresco (по крайней мере в версии 3.x) использовалась очень своеобразная модель данных. Она больше напоминает иерархическую (или сетевую) нежели традиционную реляционную - дерево с произвольными объектами в узлах + дополнительные связи.
Так что у них переход от РСУБД мог быть даже на руку.
У меня был опыт миграции исторических данных из постреляционной D3 в привычную MS SQL Server. Практически отсутствующая документация, слабая поддержка разработчика, ограниченное число сообществ, особенно региональных, сделало работу по миграции по истине - творческой :).
Когда кто-то говорит о NOECM и NOSQL, забывают оценить сколько будут стоить те специалисты, которые будут заниматься поддержкой и развитием системы на таких СУБД, сколько будет стоить их обучение и как в конечном счете, это скажется на стоимости продукта и его владении. Пока еще NOSQL - это экзотика. А делать ставки на непроверенную временем экзотику, ради желания попасть в тренд времени - неоправданное расточительство.
Консервативность - не всегда плохо, особенно там, где требуется прогнозируемый результат работы и ее высокое качество.
NoSQL появились до реляционных баз так-то... А в целом, вот в известной вам системе, есть "файловые хранилища" - это же noECM, не так ли? И есть причины почему пусть даже в таком виде они нужны. И специалистов по этим "хранилищам", я почти уверен, меньше чем по MongoDB или Azure Tables, например. Да и чисто технически, для большой системы, хранить тело документа в MS SQL не лучшее решение. Так что надо копать в эту сторону дальше...
Ирина, Вы совершенно точно заметили, что есть проблема с наличием специалистов и готовностью инфраструктурных подразделений поддержать NoSQL и IMDG решения. Вернее, среди разработчиков такие специалисты уже есть и потому в огромном количестве новых решений данные технологии используются. На моей прошлой работе в 2013 году внутри приложений в компании совершенно случайно "выросли" CouchBase, MongoDB и Redis. Но т.к. ни системные администраторы ни аналитики не готовы работать с этими технологиями, то и появление их происходит полуподпольно. Поставщик приносит софт, а что там внутри особо и не рассказывает. Я думаю, что в web-приложениях 3-d party software еще больше, просто никто туда не лезет и не спрашивает - а какой кэш ты используешь для синхронизации сессий между серверами, а какие у тебя очереди сообщений и т.д.. Сверху все это выглядит как простенькое решение на php или aspx, а начинаешь разбираться и обнаруживаешь внутри добрую половину apache-вских проектов.
Максим, спасибо, именно это я и имела в виду.
аналитики ограничены рамками и сроками проектов для конкретных заказчиков, а исследование новых областей требует времени, поэтому, лично мое мнение NOSQL-решения развиваются по механизмам, сходным с развитием Linux - решений, т.е. большей частью на энтузиазме разработчиков и админов, этим объясняется и динамика продвижения таких баз данных и их сравнительно небольшая популярность.
Иногда, и туда приходиться лезть и опять таки приходится упираться в качество поддержки функционала со стороны поставщика.