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

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