Скорость эволюции схемы
Этот вопрос является вариантов классического вопроса «насколько длинна часть строки?». Это зависит от контекста, деталей эволюции схемы, скорости дисковой системы, размера базы данных, объема физической основной памяти и числа процессоров в машине, производящей эволюцию схемы.
Средство эволюции схем ObjectStore разработано и оптимизировано для наиболее эффективной работы в среде высокопроизводительных серверов, на которых обычно развертываются базы данных ObjectStore.
Имеются три основных фазы эволюции схемы:
Однако при этом отсутствует троекратное чтение всех страниц базы данных. Первые две фазы могут выполняться без чтения и отображения страниц, содержащих реальные объекты. С каждой страницей в базе данных ObjectStore ассоциируются метаданные, которые задают местоположение и тип каждого объекта внутри этой страницы, а также указатель на начало страницы. Эта информация сильно сжата, и обычно ее размер гораздо меньше размера страницы. На первых двух фазах требуется прочитать только эту метаинформацию, и поэтому они выполняются на порядки величин быстрее, чем если бы требовалось считывать и отображать страницы целиком. Так что в терминах считывания страниц выполняются не три прохода по базе данных, а скорее 1.2 проходов.
Ответ состоит в том, что серверная архитектура, основанная на страницах, позволяет писать C++-клиентов таким образом, как если бы они работали со структурами данных в основной памяти, вместо того, чтобы заставлять программистов использовать API для навигации по базе данных. Для программиста, использующего ObjectStore, наилучшей метафорой является не «база данных», а «замороженная транзакционная куча» («frozen transactional heap»). Это снижает сложность приложений и повышает скорость приложений, выполняющих большую работу над подсетью объектов, которая может быть кэширована.
При эволюции схемы имеется в точности противоположный сценарий использования. В этом сценарии считываются все страницы базы данных, но над каждой страницей выполняется очень небольшой объем работ.
«Ключевое отличие в реализации систем с физической идентификационной информацией приводит к существенному отличию по части масштабируемости при управлении «сырыми» данными на дисках. Применение в архитектуре, основанной на страницах, подхода трансляции адресов делает невозможным истинно интегрированное распределение данных на диске. Можно сегментировать данные внутри одной базы данных, чтобы приложения работали с подобластями этой базы данных в адресных пространствах своих процессов, но невозможно обеспечить в дисковой подсистеме распределенную (федеративную) базу данных, доступную клиентам в виде логического источника данных. Это означает, что в реализации архитектуры, основанной на контейнерах, возможности масштабируемости распространяются до терабайтных и даже петабайтных диапазонов, но в реализации архитектуры, основанной на страницах, они ограничены диапазонами мегабайт или гигабайт.»
Это просто неверно. Кажется, Грин полагает, что вся база данных должна помещаться в адресное пространство клиента. Конечно, это не так. Виртуальное адресное пространство расходуется только для действительно затрагиваемых страниц (на самом деле, групп страниц общим размеров в 64 Кб) и для страниц, на которые ссылаются «жесткие» указатели, находящиеся в затрагиваемых страницах.Кроме того, виртуальное адресное пространство динамически переназначается ObjectStore для обеспечения приложению возможности доступа к более крупной части персистентного хранилища. Даже на 32-разрядных клиентских машинах нет ограничения на размер базы данных, кроме ограничений на размер файла, и нет ограничений на одновременное интегрированное использование нескольких баз данных. С появлением 64-разрядного виртуального адресного пространства действительно отсутствуют ограничения на трансляцию адресов.
