Конец архитектурной эпохи

         

Архитектура системы


H-Store выполняется в grid’е компьютеров. Все объекты разделяются между узлами grid’а. Подобно тому, как это делалось в C-Store [SAB+05], пользователь может указать желаемый уровень K-надежности (K – это число узлов, при одновременном отказе которых система может восстановить работоспособность без потери выполняемых транзакций в течение заданного времени t).

В каждом узле grid строки таблиц размещаются вплотную одна к другой с использованием традиционной индексации на основе B-деревьев. Размер блока B-дерева настраивается в соответствии с размером блока кэша второго уровня используемой машины. Хотя вместо традиционных B-деревьев можно было бы использовать более эффективные варианты, основанные на знании поведения кэша [RR99, RR00], авторы решили прибегнуть к этой оптимизации только в том случае, если код поддержки индексации окажется существенным узким местом для производительности системы.

Каждый узел H-Store является однопотоковым, и в нем полностью, без прерываний выполняется каждая поступающая на обработку команда SQL. Каждый узел разбивается на несколько логических узлов в соответствии с числом ядер в соответствующем процессоре. Каждый логический узел трактуется как независимый физический узел со своими собственными индексами и областью хранения кортежей. Основная память реального физического узла разделяется между логическими узлами. Таким образом, у каждого логического узла имеется выделенный ЦП и единственный поток управления.

В среде OLTP в большинстве приложений для сокращения числа двухсторонних коммуникаций между приложением и СУБД используются хранимые процедуры. Поэтому в H-Store поддерживается всего лишь одна возможность СУБД – возможность выполнения предопределенной транзакции (выполнение транзакции может инициироваться в любом узле): Execute transaction (parameter_list).

В текущем прототипе для написания хранимых процедур используется язык C++, хотя у авторов имеются соображения по поводу возможности применения более удобных языков (см. разд. 6). В данной реализации в одном и том же процессе сочетаются логика приложения и непосредственное манипулирование базой данных. Этот подход позволяет добиться адекватной производительности при выполнении всего приложения внутри одной хранимой процедуры, в которой вызовы SQL производятся как вызовы локальных процедур (не на основе ODBC/JDBC), а данные возвращаются через совместно используемые массивы данных (опять же не на основе ODBC/JDBC).

Так же, как и в C-Store, не поддерживается журнал повторного выполнения операций (redo), а журнал отката (undo) поддерживается только при необходимости (обсуждение см. в подразделе 4.4). Журнал отката (если он ведется) сохраняется только в основной памяти и ликвидируется при фиксации транзакции.



Содержание раздела