В этой статье я собираюсь обсудить проблемы, поднятые в статье Адриана Мариотта «Еще раз об архитектурах ООСУБД». В качестве вступления замечу, что в своей исходной статье «Архитектуры ООСУБД» я стремился предоставить сторонникам технологии ООБД некоторые практические советы, облегчающие ее успешное внедрение. Ставилась задача привести именно практические, а не теоретические рекомендации, поскольку, в конечном счете, каждому из нас приходится создавать масштабируемые системы при наличии практических ограничений индивидуальных компонентов этих систем. И поэтому я думаю, что необходимо высказаться по поводу возражений Мариотта, в которых, по моему мнению, много теоретических рассуждений, менее полезных для практических реализаций. Кроме того, мне хочется прояснить комментарии Мариотта, которые являются некорректными или приведенными в отрыве от контекста, выделяя при этом области, относящиеся к которым комментарии Мариотта являются законными.

Я буду стараться высказываться кратко и по существу, поскольку уже описал свои представления о данном предмете в исходной статье. Я не буду стремиться вдаваться здесь в описание конкретных возможностей ООСУБД Versant, поскольку эта информация должным образом приведена в соответствующих руководствах пользователя.

Ответ на комментарии «Введения»

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

Ответ на комментарии раздела «Архитектура, основанная на страницах»

Похоже, что проблему Мариотту создала часть предложения «*Требуется* реализация», касающаяся стратегий размещения объектов в ObjectStore. Снова замечу, что я старался привести практические, а не теоретические рекомендации. С моей точки зрения, только в наиболее тривиальных демонстрационных версиях систем с архитектурой, основанной на страницах, можно было бы игнорировать проблему размещения объектов. В этой статье я укажу на места, в которых Мариотт снова и снова ссылается на эту стратегию размещения объектов как основное средство устранения различных трудностей разработки. Так что, говоря практически, в реальном мире должно существовать приложение, для которого будет иметься значительное число одновременно работающих пользователей и большие базы данных, и своей статьей Мариотт подтверждает эту точку зрения. Если приверженец технологии ООБД решит игнорировать этот аспект, он пойдет на риск.

Ответ на комментарии раздела «Архитектура, основанная на объектах»

Относительно того, что место выполнения запросов относится к требованиям приложения, замечу следующее. Я полагаю очевидным для своих читателей, что значимость места выполнения запросов существенно зависит от характеристик приложения. Как считает Мариотт, этот вопрос, несомненно, является сложным. Размещение данных и/или индексов на клиенте для целей выполнения запросов может быть совершенно приемлемым для определенной категории приложений. На самом деле, в исходной статье указывалось, что необходимо проанализировать характеристики приложения и подобрать ООСУБД, в архитектуре которой лучше всего поддерживаются эти характеристики. Если приложение имеет дело с очень большими наборами данных, то я бы не советовал использовать локализацию данных на стороне клиента несмотря на возможное желание разделять и распределять данные. Это связано с моим замечанием о превосходстве одной архитектуры ООСУБД на другой архитектурой при управлении крупными наборами данных. Теоретически можно перетащить в свои клиентские процессы пять гигабайт индексов и управлять их обновлением в распределенном режиме, но практически разработчик мог бы потерять работу, пытаясь реализовать это решение.

Ответ на комментарии раздела «Модель параллельности»

По-видимому, в Objectivity и Versant имеется возможность ослаблять свойства ACID, а в ObjectStore такой возможности нет. Так что я признаю ошибку. Но в любом случае это замечание Мариотта непонятно с учетом того, что в следующем предложении я говорю, что мое обсуждение фокусируется на правильном ACID-поведении. Процитированное предложение «обновления всегда приводят к выполнению операций координации блокировок и согласования кэшей.» приведено Мариоттом вне контекста.

Очевидно, что в моем контексте это означало, что для ТРАНЗАКЦИИ, демонстрирующей свойства ACID и выполняющей ОБНОВЛЕНИЯ, потребуются операции координации блокировок и согласования кэшей. Если мы говорим об индивидуальных операциях внутри транзакции, то имеется множество возможностей. В связи с этим я не понимаю замечания Мариотта о потребности блокировки миллионов объектов и влиянии этого на поведение систем с архитектурой, основанной на объектах. В практической реализации в этих случаях использовался бы паттерн блокировок GateKeeper. Например, если доступ к тысячам атомов, образующим сложную структуру, производится только через эту структуру, то потребуется блокировать структуру, а не атомы. Я вспоминаю ранние дни реляционных баз данных, когда разные поставщики приводили аналогичные аргументы по поводу гранулярности блокировок, а теперь, десять лет спустя все основные поставщики реализуют блокировки на уровне записей. Я не считаю, что эта тема завершена моим примером или примером Мариотта. Однако, вопреки утверждению Мариотта, я не «опускаю» информацию, касающуюся семантики блокировок приложения. Транзакционные блокировки требуются даже для транзакций с оптимистическими блокировками, чтобы они могли получить логически согласованный мгновенный снимок базы данных. Для рассмотрения всех возможностей потребовалась бы целая книга.

Далее автор говорит: «Грин также не упоминает о том, что в системах с архитектурой, основанной на страницах, при наличии реальной потребности в блокировке на уровне объекта можно просто поместить объект на отдельную страницу.». В таком случае я полагаю, что забыл сказать и о бесполезных затратах памяти при хранении 20-байтного объекта в странице размером в 4096 байт, а также о потерях виртуальной памяти при трансляции адресов и потерях пропускной способности сети при передаче почти пустых страниц... А вообще-то, конечно, можно иметь гранулированные блокировки и в архитектуре, основанной на страницах. Я предлагаю читателям самим решить, чем различаются практика и теория.

Ответ на комментарии раздела «Параллельность в архитектуре, основанной на страницах»

По поводу семантики блокировок и следствий для приложений с высоким уровнем параллельного доступа можно сказать следующее. В своей статье Мариотт пишет: «Грин утверждает, что это представляет собой потенциальную проблему. Насколько серьезно это в действительности?». Я полагаю, что это зависит от того, используется или не используется эта «не обязательная» стратегия размещения объектов, и, конечно, на это указывает даже сам автор! Оставшаяся часть этого раздела статьи Мариотта является подробным объяснением того, как на блокировки в ObjectStore влияют CRUD-операции, и как можно использовать «необязательные» кластеризацию и стратегии размещения объектов, чтобы избежать отрицательного воздействия этих операций, но когда Мариотт утверждает, что «в системах реального мира большая часть паттернов доступа соответствует сценарию "в основном чтение"», ему следовало бы подтвердить это примерами из своего практического опыта.

Ответ на комментарии раздела «Следствия модели параллельности»

Мне кажется, что здесь Мариотт предполагает использование замечательной стратегии размещения объектов. Когда автор утверждает, что «Грин забыл упомянуть о том, что тот же самый трешинг может возникнуть на уровне объектов в системах, в которых используются блокировки на уровне объектов», он не является корректным. Я не говорил об этом, поскольку, если бы в объектной архитектуре имелся этот конфликт, он бы разрешался за счет поддержки очереди запросов блокировок, и для этого бы не требовались возвратные вызовы всех клиентов, у которых соответствующий объект находится в кэше, как это требуется в сервере с архитектурой, основанной на страницах. Я снова предлагал практическую рекомендацию, иллюстрирующую важность стратегий размещения в архитектуре, основанной на страницах. Именно поэтому далее я писал: «Приложения, у которых имеются относительно фиксированные модели с редко конфликтующими обновлениями, хорошо сегментирующиеся в независимый кластер, обычно ведут себя наилучшим образом в архитектурах, основанных на контейнерах и страницах.» Но эту фразу Мариотт не процитировал.

Далее Мариотт утверждает, что «здесь Грин не упоминает о том, что в сервер-ориентированных системах, таких как Versant, по мере возрастания числа пользователей могут быстро проявиться проблемы масштабируемости, поскольку большая часть обработки должна производиться на сервере», и это полностью неверно. Так ведут себя реляционные системы, в которых для доступа ко всем данным используются только запросы, и в этом основной смысл использования термина «баланс» в моей исходной статье. Реляционные системы делают все (выполняют запросы) в серверном процессе, а в некоторых объектных архитектурах, таких как ObjectStore, используется противоположный подход, и все делается в клиентском процессе. В ООСУБД Versant и ее архитектуре, основанной на объектах, устанавливается некоторый «баланс», и на стороне сервера выполняются запросы, а на стороне клиента поддерживаются навигация и кэширование.

В среде Versant разработчики используют запросы только для инициирования сценария использования, импортируя на сторону клиента ключевые объекты, связанные с другими объектами, которые требуются в транзакции. Затем производится навигация по связанной информации в режимах отложенной загрузки или упреждающего чтения без использования обработки запросов. Замечу также, что инициирующий запрос не является «обязательным», и что для непосредственной навигации могут использоваться именованные корневые объекты, но опыт показывает, что приложения реального мира не могут быть чрезмерно упрощенными, и для них требуются оба эти метода.

Казалось бы, Мариотт, будучи экспертом в области ООБД, должен был бы знать об этих навигационных возможностях Versant, и поэтому мне непонятно, что побудило его к обсуждению этой темы. Я согласен с тем утверждением Мариотта, что «преимущества каждой из архитектур будут сильно зависеть от контекста». Снова замечу, что в этом состоял весь смысл исходной статьи: требуется понять характеристики своего приложения и подобрать правильную архитектуру ООСУБД, соответствующую требованиям приложения. Я просто хочу, чтобы приверженцы технологии ООБД преуспели в ее применении, я вовсе не стремлюсь ввести их в то заблуждение, что некоторая ООСУБД ВСЕГДА является наилучшей. Я не буду вдаваться в детали возможностей реализации ООСУБД Versant, таких как распределенные и параллельные запросы, поскольку эти вопросы хорошо освящены в руководствах по этой системе.

Ответ на комментарии раздела «Следствия сетевой модели»

Здесь в своем первом комментарии автор говорит об использовании этих «не обязательных» стратегий размещения для решения упоминаемой им проблемы. И во втором комментарии оказывается, что спасают именно «не обязательные» стратегии размещения.

Что же касается того утверждения Мариотта, что реализации с архитектурой, основанной на объектах, оказываются не слишком пригодными для приложений с большим числом одновременно работающих пользователей из-за наличия узких мест на стороне сервера и блокировок мелких объектов, я уже пояснял, что в Versant в качестве основного средства доступа к объектам используется навигация, а не запросы. Я также говорил, что в многочисленных публикациях, затрагивающих проблему блокировок мелких объектов, приводится много паттернов блокировок, и даже упомянул про транзакции с оптимистическими блокировками, в которых для достижения согласованности используются временные метки, а не блокировки. Все это говорилось только для обеспечения полной ясности. Я не говорил, что для обеспечения наилучших результатов запросов не обязательно требуется тщательно продумывать их формулировки, заботиться об индексации, оптимизации и т.д. Однако при написании исходной статьи я считал, что читателям известны эти основы методов доступа к базам данных.

Ответ на комментарии раздела «Реализация запросов в архитектуре, основанной на страницах»

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

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

Ответ на комментарии раздела «Реализация запросов в архитектуре, основанной на объектах»

Я не уверен в уместности приведенного Мариоттом урока по объектно-ориентированному программированию в качестве контрдоводов к моей исходной статье. Возможно, в подразделе «Реализация запросов в архитектуре, основанной на страницах» мне стоило упомянуть слово «оптимизатор». Конечно, я не имел в виду, что у какого-либо поставщика имеется средство поддержки запросов, которое невозможно оптимизировать. Во всем остальном материал этого раздела статьи Мариотта является отличным обзором подсистемы обработки запросов ObjectStore, хотя я бы не стал говорить об использовании STL-коллекций для оправдания подхода к обработке запросов на стороне клиента. Естественные языковые структуры и многочисленные паттерны моделирования действительно обеспечивают отличные навигационные средства, позволяющие избежать потребности в запросах, а возможность использования индексов и семантика запросов - это уже совсем другая тема.

Вопреки утверждению Мариотта, а вовсе не заявлял, что в архитектуре, основанной на страницах, нельзя использовать несколько потоков управления. Что касается параллельных и распределенных запросов, я имел в виду вовсе не то, что данные берутся из одной физической базы данных и распределяются по нескольким клиентам для выполнения запроса; я говорил о возможности одного клиента адресовать запрос к нескольким физическим базам данных. Проблема состоит в потребности в передачи клиентам бесполезной информации только для того, чтобы выполнить запрос и получить несколько объектов, удовлетворяющих условию. Так что интерес представляет случай, когда имеется множество данных (миллионы объектов), распределенных между многими физическими базами данных (или даже хранимых в одной базе данных), и обеспечивается возможность задавать простой уточненный запрос с получением в ответ пары объектов, от которых можно начать навигацию, следуя логике сценария использования. И я говорил, что очень неприятной является потребность в перемещении этих миллионов объектов (или их индексов) в группу клиентских машин, каждая из которых обрабатывает некоторый сегмент этих данных и возвращает куда-то результаты (я не уверен, что в ObjectStore обеспечивается удаленная обработка запросов между клиентскими процессами), а также последующая потребность (для реального использования результатов) в загрузке по сети страниц (если они уже не загружены), содержащих некоторые объекты, которые не удовлетворяют условию запроса. Конечно, эта последняя фаза - пересылка бесполезных объектов могла бы, на самом деле, принести пользу, если использовать эту «не обязательную» стратегию размещения, при которой в сценарии использования потребуются эти «бесполезные» объекты.

Ответ на комментарии к разделу «Следствия модели запросов»

Хочу пояснить свое отношение к навигационному доступу, которому, по утверждению Мариотта «уделяется недостаточное внимание». Цель исходной статьи состояла в том, чтобы подчеркнуть основные различия между ООСУБД, и, если не учитывать различия в семантике реализации, навигацию все они поддерживают очень хорошо. Под этим я имею в виду то, что во всех реализациях эффективная навигация достигается в основном за счет статически определенных связей, а не динамически определяемых связей (вычисляемых соединений), как в реляционной технологии. Я не вижу смысла в дальнейшем обсуждении этой темы, поскольку она полностью раскрывается в руководствах всех поставщиков.

На мой взгляд, оспаривание важности модели запросов в части высказывания Мариотта «:приводит к вопросу о следствиях модели запросов в целом» показывает серьезное отсутствие понимания значимости этого механизма для эффективного запуска сценария использования. Модель запросов, ее реализация, ее эффективность становится очень существенной при возрастании объемов наборов данных, с которыми имеет дело приложение. Отсутствие понимания этого факта служит в поддержку моего утверждения, что архитектура, основанная на страницах, наименее подходит для использования в приложениях, работающих с большими объемами данных. Не считая этого, большая часть материала этого раздела является хорошим обсуждением значимости навигации ВО ВСЕХ ООСУБД.

Кажется, я действительно был не прав, утверждая, что НЕТ НИКАКОЙ ВОЗМОЖНОСТИ доступа к объектам, не содержащимся в коллекциях, над которыми можно выполнять запросы. Правильнее было бы сказать, что, как кажется, в ObjectStore можно загрузить в клиента все объекты некоторого класса и последовательно сканировать их, пока не найдутся искомые объекты. Однако в практической, а не теоретической реальности, несмотря на наличие «возможностей», описанных Мариоттом в этом разделе, если попытаться инсталлировать сегодняшнюю реализацию архитектуры, основанную на страницах, и сразу воспользоваться ею, вы не сможете выполнять запросы на стороне сервера, поскольку для этого придется загрузить в клиентов много сторонней информации. Кроме того, если учитывать характеристики производительности и затрат памяти, то лучше направлять запросы к индексированным коллекциям, над которыми можно выполнять запросы, поскольку в противном случае в клиента будут загружены тонны информации для последовательного сканирования при поиске требуемых объектов. Советую подумать, как это может воздействовать на возможность удовлетворения требований к приложениям, генерирующим оперативные отчеты.

Дискуссия о возможности обращений ко внемодельным объектам, для которых требуется автоматическая сборка мусора в стиле поддержки времени выполнения виртуальной машины, носит религиозный характер, и подобным обсуждениям лучше посвящать отдельные статьи. Я полагаю достаточным сказать, что многие светила нашей области доходят то того, что данные «никогда» не следует удалять. С подобным заявлением выступил известный специалист из Microsoft на панельной экспертной дискуссии по объектам и базам данных на конференции OOPSLA 2006.

Что касается параллельного выполнения запросов в нескольких физических узлах, из текста Мариотта мне трудно понять, почему он считает неверным мое утверждение. Если я неправ, то, видимо, мне следовало сказать, что разработчики приложений должны сами реализовывать это поведение, а не полагаться на то, что иногда им могут помочь встроенные возможности ObjectStore. В Versant запрос поступает от одного потока исполнения в контексте соответствующих транзакции и кэша и адресуется к некоторой абстракции, которой является логическая база данных. Внутри ООСУБД Versant для каждой физической базы данных, входящей в это логическое представление, используется отдельный поток управления, эти потоки выполняются в параллель, и их частичные результаты сливаются, обеспечивая результирующий набор данных для вызывающего потока управления. Мне кажется, что для того чтобы делать что-то подобное в ObjectStore, потребовалось бы, чтобы от раздельных потоков управления внутри раздельных кэшей (сессий) поступали их собственные запросы, и чтобы затем приложение управляло этими потоками управления и окончательный результат собирался из разных кэшей с использованием мягких указателей ObjectStore. Я приведу выдержку из проспекта ObjectStore, чтобы дать понять, что я имею в виду: «В одной сессии ObjectStore может иметься несколько потоков управления, выполняемых в рамках одной транзакции базы данных, или один процесс с несколькими сессиями, в которых выполняется несколько независимых транзакций. Это обеспечивает идеальную поддержку СУБД для многих потоков управления крупномасштабных серверов приложений, которые должны обслуживать много одновременно поступающих запросов». Сессии ObjectStore соответствует контекст кэша.

Ответ на комментарии к разделу «Управление идентификационной информацией»

Хочу сделать замечание относительно возможности масштабирования за счет лишь поддержки 64-разрядных машин. Проблема масштабируемости проистекает не только из использования физической идентификационной информации, а и из особенностей реализации. Я соглашусь с тем, что в 64-разрядной реализации архитектуры, основанной на страницах, можно достичь большего уровня масштабируемости. Но я не думаю, что путем перекомпиляции всех приложений в расчете на 64-разрядную машину можно повысить их масштабируемость. Возможно, это связано с тем, что эта проблема является проблемой не архитектуры, основанной на страницах, а конкретной реализации. Если взглянуть на сегодняшние приложения, работающие с терабайтными объектными базами данных, то поддерживающими их ООСУБД преимущественно окажутся Objectivity and Versant. У этого факта имеется причина, и хотя теоретически 64-разрядная адресация позволяет работать с более крупными наборами данных, я продолжаю настаивать на своем практически обоснованном утверждении, что реализации архитектуры, основанной на страницах, не очень подходят для работы с очень большими наборами данных. ООСУБД Versant и Objectivity обеспечивали возможность работать с данными подобного объема намного раньше появления 64-разрядных машин.

Ответ на комментарии к разделу «Физическая идентификационная информация»

По поводу утверждения Мариотта, что я пренебрегаю «очень быстрым» разыменованием физических идентификаторов хочу сказать следующее. Я задаю вопрос и призываю задать этот вопрос читателей: «как можно назвать реализацию «очень быстрой», если сначала нужно все загрузить в клиента?». В Versant можно зафиксировать объекты в памяти и пользоваться обычными указателями по памяти, никак не заботясь об идентификаторах базы данных. Как я уже говорил, я считаю, что навигация хорошо поддерживается во всех ООСУБД, но я не согласен с позицией Мариотта по данному вопросу, и, возможно, мне следует обсудить аспект навигации более подробно.

Пусть читатели статьи Мариотта сами решают, насколько гибкой является эволюция схемы в среде ObjectStore. Я не являюсь экспертом по реализации ObjectStore, и Мариотт много написал, чтобы показать читателям, что эволюция схемы в ObjectStore возможна. Я уже высказал свое мнение об этом в исходной статье.

Заключение

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