Глава 5. Базы данных: реальные образцы

База данных в памяти Oracle TimesTen это оптимизированная для памяти реляционная база данных, которая предоставляет приложения с чрезвычайно быстрым времени отклика и очень высокой пропускной способностью. База данных в памяти Oracle TimesTen (далее просто TimesTen) вырабатывает производительно реального времени меняя само предположение о том где располагаются данные в реальном времени. Поддерживая данные в памяти и соответствующим образом оптимизируя структуры данных и алгоритмы доступа, операции базы данных выполняются с максимальной эффективностью. Оснащение TimesTen обычно обладает приложения со множеством пользователей и большим числом потоков, применяющих изолированность блокировок строк и фиксации считывания. Получающие доступ к базе данных TimesTen приложения применяют стандартный SQL через программные интерфейсы JDBC, ODBC, ODP.NET, OCI (Oracle Call Interface), Pro*C/C++ и Oracle PL/SQL. Связанная со своими приложениями исполняемая TimesTen достигает наилучшей производительности (также именуемой "непосредственным режимом" - direct mode). Однако обычный доступ клиент/ сервер, как правило, применяется при исполнении различных приложений в различных серверах, совместно применяющих базу данных. Базы данных TimesTen относятся к числу непрерывно присутствующих и восстанавливаемых. Их долговечность обеспечивает сочетание ведения журналов транзакций и контрольных точек баз дынных на диске. Высокая доступность предоставляется применением для транзакций Репликаций TimesTen между базами данных TimesTen в масштабе реального времени. Большинство корпоративных внедрений TimesTen добавляет Репликации TimesTen для доступности и восстановления после сбоев. Например, глобальные системы телекоммуникации с веб- доступом, такие как оплата в реальном времени, управление сеансами подписки, электронная коммерция, хранилища реального времени, вебсайты путешествий и резервирования не могут допускать времени простоя приложения/ службы; финансовые услуги и безопасные торговые системы обязаны быть непрерывно доступными пока открыты финансовые рынки. Репликации TimesTen пользуются технологией репликаций, основанной на оптимизированное для памяти ведение журналов транзакций поверх эффективного и основанного на потоках сетевого протокола для высокой производительности надёжности и устойчивости.

Ключевые функциональные возможности TimesTen включают в свой состав:

TimesTen обладает большим числом знакомых функциональных возможностей помимо некоторых уникальных. Вот некоторый не исчерпывающий их все перечень:

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

 

Блоки памяти

Применение связанных списков блоков это первейшая организация для постоянных и временных сегментов в базе данных TimesTen. Блоки памяти могут быть различными в размере, причём с некого низшего минимального предела; тем не менее, эти блоки должны быть кратными лежащему в основе размеру дсикового блока. Всем объектам базы данных ставится соответствие блокам.

 

Куча TimesTen

Для реализации таблиц и индексов TimesTen пользуется не сортированными файлами кучи, организуемыми словарём, как это пояснялось в 4.4.2. Не сортированная куча содержит буферы кучи, которые способны обладать переменной длиной и организованы при помощи каталога. Этот метод применяется для соответствующего каталога, как это описано в 4.7.6.1. Кучи TimesTen и буферы кучи TimesTen выделяются из блоков памяти для сохранения организации памяти и чтобы иметь возможность их простого хранения на диске.

 

Форматы записей

Записи TimesTen организуются в страницы записей. Каждая стрница записей обладает следующими характеристиками:

Все записи TimesTen различаются по длине с применением описанной в 4.7.10.1 методики.

MySQL, наиболее популярная система управления базами данных SQL с открытым исходным кодом, разрабатывается, распространяется и поддерживается корпорацией Oracle.

База данных MySQL доставляет быстрый, со множеством потоков, большим числом пользователей и устойчивый сервер баз данных SQL (Structured Query Language). Сервер MySQL предназначен для жизненно необходимых промышленных систем с интенсивной нагрузкой, а также для встроенного в любое массово развёртываемое программное обеспечение. Программное обеспечение MySQL обладает двойным лицензированием. Пользователи могут выбирать применение программного обеспечения MySQl либо в качестве продукта с открытым исходным кодом в терминах GNU (General Public License, общедоступной лицензии) или же может приобретаться как стандартная коммерческая лицензия Oracle.

База данных MySQL была создана в 1979 году компанией с названием TcX в качестве механизма хранения нижнего уровня с возможностями отчётов. Изначально она имело название Unireg.

На протяжении десятилетия 90х некоторые потребители TcX запрашивали от Unireg возможностей SQL, вследствие чего в 1996 году была выпущена MySQL. Она предлагала некоторое подмножество языка SQL, оптимизатор и поддержку для различных API, однако отсутствовали возможности транзакций, внешние ключи и и прочее из современных функциональных возможностей. В 2000 году сформировалась независимая компания с названием MySQL AB и она установила партнёрские отношения с SleepyCat для предоставления интерфейса SQL под файлы данных BerkleyDB. Поскольку BerkleyDB поддерживали транзакции, это партнёрство снабдило MySQL поддержкой транзакций.

Эта интеграция кода под партнёрство никогда в реальности не работала, поскольку таблицы BerkleyDB никогда не были стабильными на временном промежутке. Тем не менее, оно снабдило кодовую основу MySQL полностью оборудованными особыми точками входа для простого подключения новых механизмов хранения. Первоначальный механизм хранения MySQL носил название MyISAM.

На протяжении 2001 года в MySQL был интегрирован механизм хранения InnoDB. Он поддерживал транзакции и блокирование на нижнем уровне. Данная интеграция увидела свет как версия выпуска 4.0 MySQL. На протяжении последующих лет в эту базу данных MySQL наряду с улучшением её стабильности в своих выпусках добавлялись дополнительные функциональные возможности. Фактически именно это стало той причиной, по которой на протяжении 2003 года была выпущена версия 5.0 MySQL. В течение 2008 года MySQL AB была приобретена Sun Microsystems, которая затем была поглощена корпорацией Oracle на протяжении 2010 года, которая, уже начиная с 2005 года была владельцем Innobase Oy, той компании, которая разработала механизм хранения InnoDB для MySQL [20].

Ниже приводится не исчерпывающий перечень модулей базы данных MySQL с её серверной стороны:

Рисунок 5.1 представляет схему взаимосвязей между этими модулями стороны сервера базы данных MySQL.

Различные механизмы хранения обладают различными возможностями. Таблица на Рисунке 5.2 содержит сопоставление различных механизмов хранения.

В остающейся части мы сосредоточимся на MySQL с применением механизма InnoDB, так как он устанавливается по умолчанию и наиболее богат функиональными возможностями механизма хранения в современных установках MySQL.

 

Механизм хранения innoDB

InnoDB это один из наиболее сложных механизмов хранения из присутствующих в настоящее время в MySQL. Он поддерживает транзакции, множество уровней, блокировки уровня строк, а также внешние ключи. Он обладает современной системой управления вводам/ выводом и памятью. Для выявления взаимноых блокировок он имеет внутренние механизмы и выполняет быстрое и надёжное восстановление после крушений. InnoDB пользуется табличными пространствами. Некое табличное пространство может храниться в файле или в необработанном разделе. Все таблицы могут пребывать в одном общем табличном пространстве, либо каждая из таблиц способна обладать своим собственным табличным пространством. Этот механизм хранит свои данные в определённой структуре с названием кластерного индекса, которая является деревом B+ со своим первичным ключом, действующим как соответствующее значение ключа поиска и с реальной записью. Его диск хранит такое дерево B+. Тем не менее, при буферизации некой страницы индекса, InnoDB будет строить некий адаптивный индекс в памяти для ускорения просмотра такого индекса на предмет кэшированных страниц. InnoDB буферируют и ключи B- дерева, и данные. Для действенного определения положения ключей InnoDB поддерживает дополнительную структуру с названием каталога всех страниц. Это разрежённый сортированный массив указателей на ключи внутри соответствующей страницы. Для определения места конкретной записи система пользуется двоичным поиском. После этого в силу разряжённости индекса всё ещё может потребоваться изучение ещё ряда ключей в связном списке записей.

H-Store [34] или его коммерческая версия VoltDB [24] это распределённая реляционная база данных в памяти на основе строк, имеющая своей целью высокопроизводительную обработку OLTP. Она мотивирована двумя обстоятельствами: во- первых, определённые операции в традиционных основанных на диске базах данных, такие как ведение журнала, автоматическая фиксация, блокировка, операции B-дерева и управления буфером, навлекают на себя значительное количество времени обработки (более 90 процентов) при портировании в базы данных в памяти; во- вторых, имеется возможность повторного проектирования обработки баз данных в памяти с тем, чтобы эти компоненты стали не нужными. В H-Store большинство таких "тяжёлых" компонентов удалены или оптимизированы для достижения высокопроизводительной обработки транзакций.

Исполнение транзакций в H-Store основывается на предположении что все (по крайней мере, большинство) имеющиеся шаблоны транзакций известны наперёд, что представлено в качестве множества скомпилированных хранимых процедур внутри самой базы данных. Это снижает необходимые накладные расходы синтаксического анализа транзакций времени исполнения и к тому же позволяет предварительную оптимизацию самой архитектуры базы данных, а также малый вес стратегии ведения журнала. В частности, его база данных может более просто разбиваться на разделы во избежание транзакций со множеством разделов, причём каждый раздел сопровождается площадкой, которая представляет собой демон с единственным потоком, который в большинстве случаев последовательно и независимо обрабатывает транзакции без необходимости тяжеловесного контроля одновременности (то есть блокировок). Далее мы тщательно рассмотрим его обработку транзакции, переполнение данных и стратегии устойчивости к отказам.

Обработка транзакций в H- Store проходит на основе раздела/ площадки [34]. Площадка (site) это некий независимый элемент обработки транзакции, который исполняет транзакции последовательно, что превращает его в реально выполнимый только когда большинство транзакций расположены на одной площадке. Это обусловлено тем, что когда транзакция вовлекает в себя множество разделов, все эти площадки выстраиваются в последовательность для обработки такой распределённой транзакции сообща (как правило, 2PC) и, тем самым, не способны обрабатывать транзакции независимо одновременно. H-Store проектирует модель разбиения на разделы с осведомлённостью об уклоне - Horticulture, Хортикультуры - для автоматического разбиения на разделы своей базы данных на основании установленной схемы базы данных, хранимых процедур и образца рабочей нагрузки транзакции для минимизации общего числа транзакций со множеством разделов и смягчения тем самым эффекта временных всплесков в своей рабочей нагрузке. Хортикультура для изучения потенциальных разделов пользуется подходом поиска большой окрестности (LNS, large-neighborhood search) руководящим образом, при котором также учитываются репликации доступных только на чтение таблиц для снижения стоимости передачи частого удалённого доступа, репликация вторичного индекса во избежание широковещательного обмена и перенаправление атрибутов хранимых процедур для включения действенного механизма маршрутизации под запросы.

Такая модель разбиения на разделы Хортикультутры способна существенно снижать значение числа транзакций между разделами, но не полностью. Таким образом, должна быть доступной соответствующая схема одновременности для различия транзакций в одном разделе от транзакций во множестве разделов, причём такая, которая не навлекает высокие накладные расходы так, где они не требуются (то есть когда имеются лишь транзакции одного раздела). H-Store проектирует две схемы одновременности с низкими накладными расходами, а именно, блокировку с малым весом и умозрительный контроль одновременности. Схема блокировок с низким весом снижает необходимые накладные расходы получения блокирования и удаления взаимных исключений позволяя выполнять транзакции одного раздела без блокировок когда нет никаких активных транзакций со множеством разделов. А схема умозрительного контроля одновременности способна продолжать выполнение выстроенных в очередь транзакций умозрительно при ожидании завершения 2PC ( в точности после исполнения самого последнего фрагмента транзакции со множеством разделов), что превосходит соответствующую схему с блокировкой, поскольку нет нескольких прекращений или транзакций со множеством разделов, которые вовлечены в большое число рабочих циклов взаимодействия.

Кроме того, на основе стратегий разбиения на разделы и контроля одновременности, H-Store при обработке транзакции пользуется множеством оптимизаций, в особенности для рабочих нагрузок с перекрытием одиночных и множественных транзакций. В частности, для обработки входящих транзакций (некой хранимой процедуры с конкретными значениями), H-Store пользуется подходом на основе модели процессов Марков для определения необходимых оптимизаций через предсказание наиболее вероятного пути и того множества разделов, к которому может осуществляьбся доступ. На основе таких предсказаний соответственно применяются четыре основных оптимизации, а именно (1) исполнение транзакции в том узле, в котором необходимый раздел будет испытывать наиболее частый доступ; (2) блокировка только тех разделов, к которым данная транзакция выполняет доступ; (3) отключение регистрации для отката в транзакциях без прекращения; (4) умозрительная фиксация соответствующей транзакции в разделах, к которым боле не требуется доступ.

Хотя H-Store это база данных в памяти, она также пользуется методом под названием антикэширования для того чтобы допускать хранение сведений в своей базе данных больше размера памяти, причём не принося в жертву производительность, через перемещение холодных данных на диск сообразно транзакции на уровне данного кортежа, в противоположность страничному уровню управления виртуальной памятью ОС. В частности, для отселения холодных данных на диск она выталкивает наиболее давно применявшиеся кортежи из своей базы данных в множество блочных буферов, которые записываются на диск, обновляет те отселяемые таблицы, которые отслеживают такие отселяемые кортежи и все необходимые индексы, причём чрез особую транзакцию отселения. Более того, выборка без блокирования достигается простым прекращением той транзакции, которая выполняет доступ к отселённым данным с последующим её перезапуском в более поздний момент времени после выборки необходимых данных с дисков, что дополнительно оптимизируется исполнением некого этапе перед проходом перед прекращением для определения всех отселённых данных, требуемых для этой транзакции с тем, чтобы она была способна выбрать их за один проход без дополнительных прекращений.

H-Store применяет гибридные стратегии устойчивости к отказам, а именно, она пользуется набором реплик для достижения высокой доступности [34], а также и контрольными точками, и ведением журналов для восстановления на случай когда утрачены все реплики. В частности, все разделы реплицируются на k площадок для обеспечения k- сохранности, то есть она всё ещё будет доступна в случае одновременного отказа k площадок. Кроме того, H-Store периодически выполняет контрольные точки всех фиксированных состояний базы данных на диски через распределённые транзакции, которые помещают все имеющиеся площадки в режиме копирования записью (copy-onwrite), при котором обновления/ удаления вызывают копирование строк в теневую таблицу. Между имеющимися интервалами двух контрольных точек для обеспечения сохранности схемы записанных в журнал команд через регистрацию таких команд (а именно, идентификатора и значений параметров транзакции/ хранимой процедуры), в противоположность регистрации всех операций (вставки/ удаления/ обновления), осуществляемой транзакцией через то что выполняет традиционное ведение журналов транзакции физиологией ARIES. Помимо этого, для поддержки откатов некоторых прекращаемых транзакций может применяться располагаемый в памяти журнал возвратов (undo). Очевидно, что ведение журнала команд обладает намного меньшими накладными расходами времени исполнения чем физиологическое ведение журнала, поскольку оно выполняет меньше работы времени исполнения и записывает на диск меньше данных при растущей стоимости времени восстановления. Таким образом, схема с журналом регистрации команд более подходящая для коротких транзакций, когда отказы узла не частые.

Hekaton [28] это оптимизированный под память механизм OLTP, полностью интегрированный в сервер Microsoft SQL, где доступ к таблицам Hekaton {такие таблицы объявлены "оптимизированными под память" в сервере SQL, чтобы отличать их от обычных таблиц} и стандартным таблицам сервера SQL может осуществляться одновременно, тем самым предоставляя пользователям много гибкости. Они разработаны для OLTP с высокой степенью одновременности, причём с применением структур данных свободных от блокировок и фиксаций (к примеру, свободный от фиксации хэш и индексация диапазона), а также оптимистической методологии MVCC. Он также содержит некую инфраструктуру с названием Siberia для управления горячими и холодными данными по отдельности, экономично и эффективно оснащая их способностью обработки Больших данных.

Более того, для облегчения вызываемых механизмом обработки запросов на основе интерпретатора в традиционных базах данных накладных расходов, Hekaton приспосабливает стратегию скомпилированного- единожды- применяемого- многократно, сначала компилируя операторы SQL и хранимые процедуры в код C, который впоследствии преобразуется в естественный машинный код [28]. В частности, план запроса целиком стягивается в единственную функцию с применением меток и безусловных переходов для совместного применения кода, тем самым избегая дорогостоящей передачи параметров между функциями и затратных вызовов функций, причём при меньшем числе инструкций в окончательно компилируемом исполняемом файле. Дополнительно, надёжность в Hekatron обеспечивается применением инкрементально увеличивающихся контрольных точек, а также журналов транзакций со слиянием регистрируемых элементов и организацией групп фиксации, а доступность достигается сопровождением реплик с высокой доступностью [28].

Мы подробно рассмотрим его контроль одновременностью, индексацию и управление горячими/ холодными данными.

Hekaton приспосабливает оптимистичный MVCC для предоставления изоляции транзакции без замыканий и блокировок. По сути, транзакция делится на две фазы, а именно, обычный этап обработки, при котором эта транзакция никогда не блокируется во избежание дорогостоящего переключения контекста и фаза проверки, на которой проверяются видимости считываемого множества и фантомов {в некоторых проверках, в зависимости от уровней изоляции, нет необходимости; например, проверке не требуется для зафиксированного считывания и моментального снимка, а для считывания в повторе необходима лишь проверка видимости считываемого множества; обе проверки нужны лишь для выстраиваемой в последовательность изоляции}, а далее разрешаются незавершённые зависимости фиксаций и принудительно выполняется регистрация в журнале. В частности, обновления будут создавать новую версию записи вместо обновления имеющейся на её месте, причём видимыми являются только те записи, имеющее силу время которых (то есть диапазона времени, обозначенного временными метками начала и окончания) перекрывает логическое время считывания данной транзакции. Записи без фиксации, если такие записи достигли этапа проверки, могут умозрительно считаны/ проигнорированы/ обновлены для ускорения обработки вместо их блокировки на протяжении обычного этапа обработки. Однако умозрительная обработка принуждает к зависимостям фиксации, причём они способны вызывать каскадное прекращение и их необходимо разрешать перед фиксацией.

Hekaton для обновления действительного времени записей, проверки видимости и выявления конфликтов применяет атомарные операции вместо блокировок. Наконец, версия записи удаляется сборщиком мусора (GC, garbagecollected), когда она более не видна ни в одной активной транзакции, причём ни в совместном, ни в одновременном режиме. Тое есть, когда рабочим потокам встречается мусор, они могут удалять его, что также, естественно, предоставляет механизм одновременной сборки мусора. Специальный процесс GC будет собирать мусор в той области, к которой никогда не было обращений.

Hekaton предлагает индекс B- дерева без защёлки с названием Bw- дерева, который для выполнения изменений состояний пользуется обновлениями приращений (дельта), основываясь на атомарных инструкциях сравнения и перестановки (CAS, compare-and-swap), а также подсистемы управления эластичной виртуальной страницей {такая виртуальная страница не имеет отношения к применяемой в ОС; на размер данной страницы нет жёстких ограничений и страницы растут за счёт добавления "дельта страниц" к их базовой странице} - LLAMA. LLAMA предоставляет интерфейс виртуальных страниц, причём поверх него Bw- дерево применяет идентификаторы логической страницы (PID) вместо указателей, которые могут транслироваться в физические адреса на основании таблицы соответствия. Это делает возможным изменение значения физического адреса узла Bw- дерева при каждом обновлении, причём без необходимости требования распространения до самого корня этого дерева такого изменения адреса. В частности, обновления приращением осуществляются путём добавления страницы приращения обновления к предыдущей странице и атомарного добавления таблицы соответствия, что позволяет избегать обновления на месте, способного приводить к дорогостоящей аннуляции кэша, в особенности в среде с несколькими сокетами, а также предотвращать применение данных, которые обновляются одновременно, предоставляя свободный доступ. Такая стратегия обновления приращениями применяется как к обновлению конечного узла, что достигается путём простого добавления страницы приращения к содержащей предыдущий конечный узел странице, так и к операциям изменения структуры (SMO, structure modifcation operations - то есть расщеплению и слиянию узлов) при помощи последовательности совместных и атомарных обновлений приращений без блокирования, в которых принимает участие любой рабочий поток, столкнувшийся с незавершёнными SMO. Страницы приращения и базовая страница для снижения вызываемого слишком длинной цепочкой страниц приращения действенности поиска объединяются в более поздний момент. Заменённые страницы восстанавливаются имеющимся механизмом эпох для защиты потенциально используемых прочими потоками данных от слишком раннего освобождения.

Ghjtrn Siberia [40] имеет целью позволить Hekaton автоматически и прозрачно сопровождать холодные данные в более экономичном вторичном хранилище, что даст возможность размещать в Hekaton больше данных, нежели того допускает память. Вместо того чтобы поддерживать некий список LRU подобно HStore Anti-Caching, Siberia осуществляет точную классификацию данных на холодные и горячие, изначально регистрируя доступ к кортежам, а впоследствии анализируя их для предсказания лучших K горячих кортежей с наивысшей оценкой частоты доступа, применяя действенный одновременный алгоритм классификации на основе экспоненциального сглаживания. Такой метод ведения журнала доступа к записи влечёт за собой меньшие накладные расходы нежели список LRU с точки зрения как загруженности памяти, так и ЦПУ. Кроме того, для снижения вызываемой вытесняемыми кортежами нагрузки на память Siberia не хранит в памяти никакие дополнительные сведения о вытесненных кортежах (скажем, ключи в её индексе, таблицу вытеснения), за исключением нескольких фильтров Блума переменного размера и приспосабливаемого диапазона, которые применяемые для фильтрации доступа к диску. Кроме того, для его превращения в подверженный транзакции, даже когда транзакция получает доступ как к горячим так и к холодным данным, она при помощи транзакции выполняет координацию между горячими и холодными данными с тем, чтобы обеспечивать согласованность, применяя длительную отметку обновления для временной записи, что определяет текущее состояние холодных записей [40].

HyPer [35] или её распределённая версия ScyPer [41] спроектированы как гибридная база данных OLTP и OLAP с высокой производительностью в памяти с предельной загрузкой современных аппаратных свойств. Транзакции OLTP исполняются последовательно в стиле без блокирования, что рекомендуется в первую очередь, а одновременность достигается за счёт логического разделения своей базы данных и одновременного исполнения множества ограниченных разделами транзакций. Это может приводить к беспрецедентно высокой скорости транзакций, достигающей 100 000 в секунду [35]. Такая превосходная производительность объясняется малой задержкой доступа к информации в базах данных в памяти, действенного адаптивного дерева оснований (Adaptive Radix Tree) с эффективным использованием пространства и применением хранимых процедур транзакций. Запросы OLAP проводятся в согласованном моментальном снимке, получаемым при помощи механизма моментальных снимков виртуальной памяти, основанных на аппаратно поддерживаемых теневых страницах и это представляет собой действенную модель управления одновременностью с низкими затратами на сопровождение. Кроме того, HyPer применяет схему динамической компиляции запросов, то есть запросы SQL сначала компилируются в ассемблерный код, который далее может выполняться непосредственно при помощи компилятора JIT (Just-in-Time, точно вовремя), предоставляемого LLVM. Такая оценка запроса следует ориентированной на данные парадигме, применяя к объекту данных как можно больше операций, тем самым удерживая в имеющихся регистрах данные как можно дольше для достижения локальности регистров.

Адаптированная версия HyPer, то есть ScyPer [41], адаптирует архитектуру первичный- вторичный, при которой такой первичный узел отвечает за все необходимые запросы OLTPи к тому же действует в качестве точки входа для запросов OLAP, в то время как вторичные узлы используются лишь для исполнения запросов OLAP. Для синхронизации необходимых обновлений от своего первичного узла к его вторичным узлам широковещательно во все вторичные узлы при помощи протокола PGM (Pragmatic General Multicast) рассылается соответствующий журнал redo, где этот журнал redo повторно воспроизводится для того чтобы навёрстывать свой первичный узел. Затем эти вторичные узлы могут подписываться на конкретные разделы, тем самым допуская предоставление вторичных узлов под конкретные разделы и делая возможной более гибкую модель со множеством арендаторов (tenancy). В текущей версии ScyPer имеется лишь один первичный узел, причём он удерживает все необходимые данные в памяти, тем самым ограничивая возможный размер базы данных или мощность обработки транзакции одним сервером.

Далее мы подробнее остановимся на механизме моментального снимка HyPer, осведомлённой о регистрах схеме компиляции и индексации ART.

HyPer строит согласованный моментальный снимок через ветвление дочернего процесса (посредством системного вызова fork()) при помощи копирования своего собственного пространства виртуальной памяти [42], что не вовлекает никакого программного механизма управления одновременностью, а лишь аппаратную поддержку управления виртуальной памятью с небольшими накладными расходами поддержки. После ответвления дочернего процесса все имеющиеся в родительском процессе данные виртуально "копируются" в его дочерний процесс. Тем не менее, это операция с достаточно небольшим весом поскольку данный механизмом копирования записью (copy- on- write) включает реальное копирование только тогда, когда какой- либо процесс пытается изменять страницу и что достигается самой ОС и блоком управления памятью (MMU, memory management unit). Как сообщается в [43], такая репликация страницы эффективна, поскольку её можно достигать за 2мс. Следовательно, согласованный моментальный снимок для запросов OLAP может действенно создаваться без больших затрат на синхронизацию.

В [44] проводилось эталонное тестирование механизмов моментальных снимков: записи в Теневую память кортежа (Tuple Shadowing) программным образом, котрое создаёт новую версию при изменении кортежа, создание Кортежа близнеца (Twin Tuple), которое всегда сохраняет две версии каждого кортежа, аппаратную запись Теневой памяти страницы, применяемой HyPer, а также Теневой памяти Горячих- Холодных (HotCold Shadowing), которое сочетает Теневую память кортежа с аппаратной Теневой памятью страницы через кластеризацию объектов с интенсивными обновлениями. Данное исследование показывает, что Теневая память страницы с точки зрения производительности OLTP, времени отклика на запрос OLAP и потребления памяти наилучший вариант. При создании моментального снимка для такого механизма Теневой памяти страницы наиболее трудоёмкой задачей выступает копирование страниц процесса, которое можно понижать применяя гигантскую страницу (huge page, в x86 это 2МБ) для холодных данных. Горячие или холодные данные отслеживаются и группируются при помощи аппаратного подхода через считывание/ сброс флагов страниц молодых и изменённых (young and dirty). Для последующего повышения производительности рабочей нагрузки OLAP и снижения потребления памяти к холодным данным применяется сжатие.

Моментальные снимки применяются не только для запросов OLAP, но также и для транзакций с длительным исполнением, поскольку такие долго выполняемые транзакции будут блокировать прочие короткие транзакции естественной природы в применяемой модели последовательного исполнения. В HyPer такие неприветливые транзакции выявляются и предварительно исполняются в неком дочернем процессе с согласованным моментальным снимком, а полученные такими транзакциями изменения приводятся в действие активацией детерминированного "применения транзакции" причём обратно в основной процесс базы данных. Такое применение транзакции удостоверяет исполнение выполненной предварительно транзакции через проверку того, что все выполненные в текущем моментальном снимке считывания идентичны тем, которые были бы считаны из основной базы данных когда требуется сериализуемое представление или проверкой тех записей в таком моментальном снимке, которые были отсоединены от необходимых записей всех транзакций в своей основной базе данных после создания моментального снимка, когда требуется изоляция. В случае успешности такого удостоверения применяются все записи в состояние основной базы данных. В противном случае клиенту выдаётся сообщение о прекращении.

Для обработки запроса HyPer транслирует его в компактный и действенный машинный код, применяя структуру компилятора LLVM [45] вместо классической модели обработки запросов на основе итератора. Модель компиляции HyPer JIT предназначена для того чтобы избегать вызова функций через выполнение рекурсивных вызовов функций во фрагменте кода цикла, тем самым достигая лучшей локализации кода и локальности данных (а именно, временной локальности для регистров ЦПУ), поскольку каждый фрагмент кода осуществляет все действия над соответствующим кортежем в одном конвейере исполнения, на протяжении чего этот кортеж хранится в регистрах прежде чем материализовать получаемый результат в памяти для следующего конвейера. Поскольку оптимизированный компилятор языка высокого уровня (скажем, C++) работает медленно, HyPer для создания ассемблерного кода SQL запроса пользуется структурой компилятора LLVM. В частности, при обработке запроса SQL тот сначала обрабатывается как обычно, то есть запрос анализируется, транслируется и оптимизируется в некий алгебраический план логики. Однако, такой алгебраический план логики не транслируется в исполняемый физический план как в обычной схеме, а вместо этого компилируется в императивную программу (а именно, в код на ассемблере LLVM), которую затем можно исполнять непосредственно при помощи компилятора JIT, предоставленного LLVM. Тем не менее, сложная часть обработки запросов (например, управление сложной структурой данных, сортировка) по- прежнему пишутся на C++, который предварительно компилируется. Поскольку код LLVM способен напрямую вызывать собственный метод C++ без дополнительной оболочки, C++ и LLVM взаимодействуют друг с другом без потери производительности [45]. Однако с точки зрения чистоты кода, размера исполняемого файла, эффективности и тому подобного существует некий компромисс между определением функций и встраиванием кода в один компактный фрагмент кода.

Для действенной индексации HyPer пользуется адаптивным деревом оснований (ARX, adaptive radix tree) [46]. Основное свойство такого дерево оснований гарантирует что значения ключей упорядочены поразрядно лексикографически, предоставляя возможность сканирования диапазона, просмотра по префиксу и т.д. Увеличение размаха дерева оснований способно уменьшать высоту такого дерева, тем самым ускоряя процесс поиска, но при этом экспоненциально увеличивая потребление пространства. ART предоставляет эффективность потребления пространства и времени за счёт адаптивного применения различных размеров внутренних узлов с одним и тем же относительно большим диапазоном, но с при различных ответвлениях. В частности, существует четыре типа внутренних узлов с диапазоном 8 бит, но с разной ёмкостью: Node4, Node16, Node48 and Node256, которые получили свои названия в соответствии с их максимальной ёмкостью хранения указателей дочерних узлов. То есть, Node4/Node16 способны хранить до 4/16 дочерних указателей и для хранения сортированных ключей пользуются массивом с длиной 4/16 е ещё одним массивом той же длины для дочерних указателей. Node48 применяет массив из 256 элементов для непосредственной индексации битов ключа в массиве указателей с ёмкостью 48, в то время как Node256 представляет собой просто массив из 256 указателей в качестве обычного узла дерева оснований, которое применяется для хранения от 49 до 256 записей. Для ещё большего снижения потребления памяти применяются методы медлительного расширения (Lazy expansion) и сжатия пути.

SAP HANA [23] это распределённая база данных в памяти, обладающая функциональными возможностями интеграции как OLTP, так и OLAP [47], а также обработкой единообразных структур (а именно, реляционная таблица), частичной структурированности (то есть, графов) и не структурированных (то есть, текста). Все данные удерживаются в памяти пока доступно достаточно пространства, в противном случае объекты данных (например, таблицы или разделы) целиком выгружаются из памяти и повторно загружаются в память когда они потребуются снова.

HANA обладает следующими функциональными возможностями:

Мы подробнее рассмотрим лишь первые из приведённых трёх функциональных возможностей, поскольку остающееся свойство совершенно обычная методика применяемая в имеющейся литературе.

SAP HANA поддерживает физические представления реляционных таблиц, ориентированные как на строки, так и на столбцы. Хранилище строк полезно для интенсивных обновлений и вставок, а также для точечных запросов, которые распространены в OLTP, в то время как хранилище столбцов идеально подходит для приложений OLAP, поскольку они обычно обращаются ко всем значениям столбца совместно и к нескольким столбцам одновременно. Ещё одно преимущество представления в виде столбцов состоит в том, что оно способно применять более действенно и эффективно методики сжатия. В HANA таблица/ раздел могут быть настроены либо на хранение в своём хранилище строк, либо в хранилище столбцов, а также имеется возможность перестроения из одного хранилища в другое.

HANA также предоставляет советника по хранению, который порекомендует оптимальное представление на основе данных и характеристик запросов, принимая во внимание как стоимость запроса, так и степень сжатия. Поскольку таблица/ раздел существует либо в хранилище строк, либо в хранилище столбцов, а каждое из них обладает собственными недостатками, для обеспечения действенной поддержки рабочих нагрузок как для OLTP, так и для OLAP HANA разрабатывает трёхуровневую единообразную ориентированную на столбцы структуру таблицы, состоящую из приращения L1, приращения L2 и основного хранилища, что демонстрирует, что хранилище столбцов способно эффективно развёртываться и под OLTP [41]. Как правило, кортеж сначала сохраняется в L1- приращении в формате строки, затем распространяется на L2 в формате столбца и, наконец, сливается с основным хранилищем с наиболее сильным сжатием. Весь тот процесс из таких трёх этапов в терминах HANA носит название жизненного цикла кортежа.

HANA поддерживает различные программные интерфейсы для анализа данных (то есть OLAP), включая стандартный SQL для общей функциональности управления данными, а также более специфические языки программирования, например, сценарии SQL, MDX, FOX, WIPE и R. В то время как запросы SQL исполняются тем же образом как и в обычных базах данных, прочие специализированные запросы должны преобразовываться. Такие запросы сначала подвергаются синтаксическому разбору в в промежуточную модель абстрактного потока данных с названием "модели вычислительного графа", в которой исходные узлы представляют собой постоянные или временные таблицы, а внутренние узлы отражают логические операторы, выполняемые данными запросами, а затем преобразуются в планы выполнения аналогично запросу SQL. В отличие от прочих систем, HANA поддерживает сценарии R как часть своей системы, что делает возможным лучшую оптимизацию особых заданий анализа данных. В частности, сценарии R могут быть встроены в пользовательский оператор в графе расчёта. Когда требуется выполнение оператора R, вызывается отдельная среда времени выполнения R с применением пакета Rserve. Поскольку формат столбцов HANA ориентированной на столбцы таблицы аналогичен векторно ориентированному кадру данных R, преобразование таблицы в кадр данных требует малых накладных расходов. Передача данных осуществляется через совместную память, которая выступает действенным механизмом межпроцессного взаимодействия (IPC). Применяя пакет RICE, требуется лишь однократное копирование для доступности данных процессу R, то есть необходимые данные просто копируются из своей базы данных в раздел совместной памяти, а среда выполнения R способна получать доступ к этим данным напрямую.

HANA поддерживает временны́е запросы, такие как временна́я агрегация, перемещение по времени и соединение по времени, причём на основе единой структуры индекса, носящей название Индекса временно́й шкалы [48]. Для каждой логической таблицы HANA хранит текущую версию таблицы в текущей таблице и всю историю предыдущих версий во временно́й таблице, сопровождаемую индексом временно́й шкалы для облегчения временны́х запросов. Всякий кортеж временно́

й таблицы содержит допустимый интервал от времени его фиксации до последнего допустимого момента времени, в течении которого некая транзакция превращает это значение в недействительное. Время транзакции в HANA представлено дискретными, монотонно возрастающими версиями. По существу, значение Индекса временно́й шкалы сопоставляет каждую версию со всеми событиями записи (то есть с записями во временно́й таблице), которые были зафиксированы до или в самой этой версии. Индекс временно́й шкалы состоит из списка событий и Карты версий, в которой Список событий отслеживает каждое событие признанным несостоятельным или подтверждённым, а Карта версий отслеживает последовательность событий, которые можно наблюдать в каждой версии этой базы данных. Следовательно, благодаря тому факту, что все видимые строки временно́й таблицы в каждый момент времени отслеживаются, временны́е запросы могут быть реализованы путём одновременного сканирования списка событий и карты версий. Для снижения стоимости сканирования под создание временно́го представления, HANA дополняет основанный на отличиях индекс временно́й шкалы рядом полных представлений, носящих название контрольных точек, причём в определённый момент времени в истории. В частности, контрольная точка представляет собой битовый вектор с длиной, равной количеству строк во временно́й таблице, который представляет видимые строки временно́й таблицы в конкретный момент времени (то есть определённую версию). При помощи контрольных точек временно́е представление в заданный момент времени может быть получено путём сканирования от последней временной точки до этого момента времени, вместо сканирования всякий раз с самого начала списка событий.