FuzzyУважаемые коллеги!

Я недавно открыл для себя объектно-ориентированную базу данных (db4o). И вот какая мысль у меня в связи с этим возникла.

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

Однако, так ли уж прекрасно и РСУБД справляется с задачами анализа?
Ведь обычно аналитики не используют OLTP-систему для формирования своих отчётов, а используют OLAP-кубы!
Причины этого: а) в случае, если данные находятся в сильно нормализованном виде, запросы по ним выполняются довольно-таки медленно. Особенно, если не построены нужные индексы, а они ведь и не построены в OLTP-системе, т.к. индексы там заточены под задачи бизнес-транзакций, а не анализа; б) какой-нибудь тяжёлый аналитический запрос, этак на пару-тройку часов, может помешать выполнению бизнес-транзакций, что неприемлемо.

Получается, что OLTP на РСУБД является типичной универсальной системой, которая справляется и с задачами текущей работы с информационной системой, и с задачами анализа. Но обе эти задачи она решает не идеально!

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

Получится, что каждую из задач мы решим наиболее оптимальным способом. Как вам кажется?

Итого, вы предлагаете построить транзакционную систему на ООБД, а классическую аналитическую "архив+агрегаты+отчетность" - на РСУБД+OLAP. Пожалуйста. Никто не мешает, если ваша ООБД лучше справится с суточным потоком данных, а ночная репликация не будет глючить и создавать проблем. Только учтите все риски добавления новой технологии, посчитайте денежки и поймите, кто это будет создавать-поддерживать-оптимизировать.

FuzzyДа, Александр, совершенно точно, именно это я и предлагаю. Собственно, хотел здесь обсудить такое решение как одно из возможных практических применений ООБД. Мне кажется, что ООБД чисто для задач OLTP реально должно рвать РСУБД просто на части, и по скорости разработки, и по производительности, и по удобству рефакторинга. А недостатки ООБД мы решим через репликацию на, условно говоря, сервер отчётов с OLAP на РСУБД.

Удобство разработки - да. Рефакторинг - может быть... хотя все уже так привыкли к реляционкам, что ООБД может только добавить проблем.
И очень сильно сомневаюсь насчет производительности, а в транзакционных системах только она и нужна :) ООБД интересна, когда надо быстро состряпать нечто, имеющее сложный пользовательский интерфейс, сложную бизнес-логику. Короче, когда БД вторична и на нее надо потратить минимум усилий. А вот в транзакционных системах БД первична.

TORTЧто есть такое "запрос на пару тройку часов"???

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

FuzzyА почему сомнения насчёт производительности? Как насчёт object-relational impedance mismatch? Насколько я понимаю, OLTP-система только и делает, что создаёт и сохраняет объекты в базе данных. Значит, в случае РСУБД нужен маппинг объектной структуры на реляционную. Значит, тормоза по сравнению с ООБД.
Или Вы предлагаете без ООП обойтись?

ООБД дает производительность в случае, когда вы работаете с большим набором разнородных объектов и не можете прогнозировать, что приедет через секунду. Задача OLTP - быстро провести транзакцию по определенному, сто раз оптимизированному набору данных. Это совсем разные задачи.

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

Озвучьте размеры вашей организации и кол-во филиалов, пожалуйста. Похоже, мы мыслим совсем разными масштабами :)

FuzzyА причём тут моя организация? Вопрос чисто теоретический и принципиальный. В принципе -- объект сохранить быстрее в ООБД, чем в РБД? Объект прочитать быстрее из ООБД, чем из РБД?
То, о чем вы говорите - это не OLTP, а CMS. Задача OLTP-это insert и только он.

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

FuzzyА почему так вот сразу "небольшой" да "небольшой"? А вот если абстрагироваться от имеющейся практической реализации (dbo4o на java)? Аргументы можно увидеть какие-нибудь? С Вашим экспертным мнением я уже ознакомился :)
А чем кстати плохо, что на яве? Если сервер приложений на яве, ну и база пусть на яве, почему нет.

Мы тут практикой занимаемся или теориями? Давайте абстрагируемся. В теории можно. Реализуйте.
Аргументы были приведены.
Спасибо за внимание, но вы плохо ознакомились.
Ява не позволяет создавать быстрые приложения. Она позволяет быстро создавать приложения.
Если на обед суп грибной, пусть и на второе грибы будут.

FuzzyЕщё раз перечитал топик, но так и не нашёл аргументов, почему сохранение/изменение объекта в ООБД было бы медленнее, чем в РБД. Пожалуйста, приведите их ещё раз, мне очень любопытно. Кстати, на сайте db4o приводятся бенчмарки, в которых эта база разрывает на таких операциях MySQL. Что и неудивительно, собственно.

MySQL не является промышленной базой данных. Она используется для того же круга задач, что и ООБД (CMS - Content management system). Про сравнение БД вас уже направили на соотв. форум. Я пытался рассмотреть вопрос с позиций темы данного форума и сказал, что при определенных ограничениях этот подход может быть оправдан. Применение современных реализаций ООБД в транзакционной системе, занимающейся регистрацией большого объема данных в реальном времени ( OLTP - Online Transaction Processing), считаю неперспективным.

P.S. Применение ООБД и, естественно, MySQL (как вполне достойной непромышленной реляционки), конечно не ограничавается только CMS. Прошу прощения за неточную формулировку.

FuzzyТак я не в том форуме, значит? Ясно. А тут форум про крутейшие системы реального времени только, да? А с обычными учётными системами для средних по размерам оптово-розничных организаций мне куда?
Спасибо за приведённые аргументы, кстати. А то всё "я так считаю!" да "я же сказал!"...

Так я спрашивал про вашу организацию. Помните?
Решение по архитектуре системы принимается не "теоретически". И не надо вопрос "можно ли применять ООБД в качестве хранилища данных самописной учетной системы средней по размерам оптово-розничной организации с учетом последующего построения над ней системы аналитической отчетности?" формулировать как теоретический вопрос о применении такой системы на все случаи жизни. Случаи разные бывают.

_мод iscrafmбедные, бедные update и delete... их выгнали из OLTP приюта. вместе с select впрочем.
Забыли наверное что OLTP на 99% это select

Ребята, вы OLTP с OLAP не путаете?

FuzzyНикаких надстроек! ОО надстройки -- это ещё тормознее и сложнее, чем просто вручную мапить объекты в РСУБД.
Гораздо быстрее во всех смыслах использовать сразу ООБД. В этом и суть топика.

А вы не задумавались, что "мапить" надо не всегда и не все. Ну на кой нагруженную транзакционным потоком базу забивать ненормализованной информацией уровня бизнес-логики или, не дай Бог, пользовательского интерфейса? Как раз реляционка заставляет задуматься - что надо хранить, а что - нет. Потом это все разгребать и реплицировать (сама по себе очень некислая задача - перелить то, что нужно, из изменчивой ООБД в нормализованное хранилище реляционки). Да на одну поддержку логики репликации у вас уйдет все, что вы наэкономили. Короче, нужно крепко думать, взвешивать за и против. Выгода даже без споров о производительности далеко не очевидна.

авторЯ извиняюсь, а кто же заставляет сохранять в ООБД все объекты подряд???

Про подряд я не говорил. Прелесть ООБД в том, что вы храните объекты "как есть", со всеми связими и потрохами. Этим она вас и привлекла, по всей видимости. Для разработчика - супер : не надо на каждый чих лезть в базу и т.д. и т.п. Но, с другой стороны, это означает, что набор данных в ООБД для репликации очень изменчив. Кошмарный сон интегратора.

авторЧто реляционка заставляет задуматься -- это просто не то слово :)

И во многих случаях это очень неплохо, честное слово :)

авторСудя по описанию репликации между db4o и РСУБД, всё делается элементарно и почти автоматически. Реклама?

попробуйте, потом расскажите :) поверьте мне, наткнетесь на кучу всяческих "но".

автор
про обслугу на ООБД где-то соглашусь, конечно. Ну так что ж, на всё новое всегда сначала не хватает персонала. Главное, что технология ООБД + OLAP на РБД -- перспективна.

Давайте разложим все по полочкам. Благо сегодня время есть...
ООБД позволяет быстро создавать приложения, требующие хранения разнообразных по своей природе объектов. Поэтому в первую очередь они нашли применение у веб-программистов. Очень удобно хранить сессии пользователей (персонализация интерфейса), порталы, и т.д. и т.п. Что из этого следует? Это означает, что фактически каждое изменение в логике приложения отражается на структуре данных. Добавление новых сущностей - это ерунда, это происходит и в системах на РСУБД. Главное - это изменение котракта (интерфейса), по которому ваша система взаимодействует с другими системами. Фактически есть 4 основных способа интеграции приложений :
1. на уровне GUI. Надежность - без комментариев, используется если ничего другого нет.
2. на уровне SDK. Требует разработки вменяемого SDK, поддержки контракта (совместимость снизу вверх и прочие прелести), подробная документация, интегратор должен знать "потроха" приложения.
3. на уровне БД. Наиболее часто используемый. Понятен большинству. Есть стандарт - SQL. Но и здесь обычно строят еще один слой в виде набора view, процедур или стабильной структуры таблиц.
4. на уровне сервисов. SOA, разговоры про слабое связывание и все остальные модные темы.

Для информации : Промышленные ESB поставляются с адапторами, напрямую поддерживающими только 2 последних уровня.

Вы предлагаете перевести уровень интеграции системы из 3-го во 2-й. И это именно так - ООБД меняется теми же темпами, что и логика приложения (иначе зачем она нужна?). И не надо питать иллюзий насчет волшебной репликации, которая все сделает за вас. Не сделает.
Не питаем иллюзий также насчет того, что у вас - единая система учет+аналитическая отчетность. Это не так. Это две РАЗНЫЕ системы, требующие интеграции. И это ПРАВИЛЬНО, что они разные. Поскольку это надежнее. Почему продолжает жить идея Hibernate и сейчас получает развитие в новом детище Майкрософта - LINQ? Потому что это позволяет использовать РСУБД для интеграции и быструю разработку для быстрой реакции на изменение требований пользователя.
Итого : использовать ООБД для создания отдельного приложения можно. Использовать его напрямую для интеграции, без некоторого более стабильного слоя, нельзя. Таким образом, на мой взгляд, область применения ООБД ограничивается приложениями, занимающимися отображением данных и введение этой технологии в приложение, экспортирующее данные, неоправдано.

_мод FuzzyСелекты всё ещё не нужны.
Упорно не хотите вводить накладную. Для ввода надо прочитать:
поставщика
договор
товар
ед. измерения
Добавить контроль остатков, оперативный анализ, справки и получите 99% селектов против 1%инсерт-апдейт-делете. Такой вот он олтп понимаешь

Уважаемый _мод, ну прочитайте, наконец, определение OLTP, и не используйте этот термин применительно к системам другого класса. Fuzzy, кстати, изначально тоже неверно его применил. Правильное название систем, о которых вы говорите - это "модуль ERP" (предположительно - CRM).

iscrafm Титов АлександрУважаемый _мод, ну прочитайте, наконец, определение OLTP, и не используйте этот термин применительно к системам другого класса. Fuzzy, кстати, изначально тоже неверно его применил. Правильное название систем, о которых вы говорите - это "модуль ERP" (предположительно - CRM).
Уважаемый Александр, разберитесь наконец.., что такое OLTP,OLAP,ERP,CRM,CMS и т.п. смешали в кучу коней, людей и сусликов.

Я в курсе. Опять неверно понят по собственной вине :) Читать "модуль ERP" ИЛИ, возможно, CMS. У меня получилась, что CRM - это модуль ERP, а не другой класс систем. А разбираться в этих системах приходится уже давно и не теоретически.

Тьфу, уже самому смешно :)
Читать "модуль ERP" ИЛИ, возможно, CRM . У меня получилась, что CRM - это модуль ERP, а не другой класс систем. А разбираться в этих системах приходится уже давно и не теоретически.

FuzzyЯ понимаю OLTP так же, как написано в википедии тынц
первый абзац
авторOLTP (Online Transaction Processing) — онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.
А Вы как, Александр?

Именно так, что, на мой взгляд, совершенно невозможно при 99% селектов, а также большой доле апдейтов (которые требуют тех же селектов) и уж тем более делитов, которых в нормальной системе всячески избегают. OLTP, как я понимаю, работают по принципу "сохрани, а вечером разбирайся". Я не прав?

По теме топика еще что-нить будет, или очередная ветка ушла в безуспешные попытки оценить компетентность оппонентов?

FuzzyХорошо, раз мы разобрались, что такое OLTP-система, то продолжим.
Насколько я Вас понял, вы утверждаете, что главные грабли в предлагаемой мной структуре инф.системы будут при организации репликации из ООБД в РБД?
У меня вопрос, чем, по Вашем мнению, репликация ООБД->РБД намного сложнее репликации РБД->РБД? Ведь мы же всё равно должны переносить данные из OLTP-системы в хранилище данные для организации OLAP-системы, верно?
С моей т.з. -- наоборот, перенос данных из ООБД должен быть намного проще, т.к. репликация -- это ни что иное, как перенос изменений из одного хранилища в другое, а изменяются у нас в OLTP-системах объекты , следовательно, и отследить эти изменения гораздо проще в ООБД, нежели в РБД.

Еще раз прочтите, пожалуйста, вот это
Кажется, я там довольно подробно все сформулировал и обосновал свою точку зрения.

З.Ы. по поводу OLTP - это действительно более широкий класс систем, чем я думал. Признаю свою ошибку.