5. Сравнение производительности

TPC-C выполняется над схемой, показанной на рис. 1, и для этого тестового набора определяются пять классов транзакций (new_order, payment, order status, delivery и stock_level).

Рис. 1. Схема TPC-C (воспроизводится из спецификации TPC-C версии 5.8.0, стр. 10)

По причине ограниченности объема в этой статье не приводится код этих транзакций; читатели отсылаются к спецификации TPC-C [TPCC]. В табл. 1 резюмируется их поведение.

Таблица 1. Классы транзакций TPC-C

new_order	Размещает заказ пользователя. 90% всех заказов может быть полностью удовлетворено со складов, находящихся неподалеку от месторасположения пользователей («домашних» складов пользователей); для 10% заказов требуется доступ к удаленным складам. Эта транзакция производит выборки из базы данных и модифицирует данные. Минимальное процентное соотношение таких транзакций в смеси запускаемых транзакций не задается, но их должно быть около 50%.
payment	Обновляет остаток средств пользователей и поля sales в таблицах Warehouse и District. 85% обновлений относится к «домашним» складам, 15% – к удаленным складам. Транзакция производит выборки из базы данных и модифицирует данные. В смеси должно присутствовать не менее 43% таких транзакций.
order-status	Запрашивает состояние последнего заказа пользователя. Только читающая транзакция. В смеси должно присутствовать не менее 4% таких транзакций.
delivery	Выбирает склад и для каждого из 10 районов «доставляет» заказ, что означает удаление записи из таблицы new_order и обновление остаток средств пользователя. Каждая доставка может быть отдельной транзакцией. В смеси должно присутствовать не менее 4% таких транзакций.
stock-level	Находит изделия с уровнем запасов, меньшим некоторого порогового значения. Только читающая транзакция. Должна читать зафиксированные данные, но не требует сериализуемости. В смеси должно быть не менее 4% таких транзакций.

Имеются три возможных подхода к эффективной реализации TPC-C на основе H-Store. Во-первых, этот тестовый набор можно было бы выполнить на компьютере с одним одноядерным процессором. Это автоматически привело бы к тому, что все классы транзакций стали бы одноузловыми, и каждая транзакция могла бы выполняться от начала до завершения в однопотоковой среде. В парном узле, обеспечивающем высокий уровень доступности, будет поддерживаться тот же порядок выполнения. Как будет показано немного ниже, все классы транзакций TPC-C могут быть сделаны строго двухфазными. Поэтому все транзакции в обоих узлах будут либо зафиксированы, либо аварийно прекращены. Следовательно, при работе системы в одном узле при наличии парного узла, обеспечивающего высокий уровень доступности, свойства ACID удается достичь без каких бы то ни было накладных расходов.

Для использования компьютеров с одним или несколькими многоядерными процессорами требуется тщательное кодирование транзакций TPC-C для достижения их свойств стерильности или одноразового использования результатов и обеспечения функционирования без накладных расходов в многоузловой среде. Сначала авторы обсуждают разделение данных.

Схема базы данных TPC-C не является древовидной. Такой ее делает наличие таблицы Item и связи между таблицами Order-line и Stock. Однако таблица Item только читается, и ее можно реплицировать в каждом узле. Таблицу Order-line можно разделить между всеми узлами в соответствии со значениями столбца Order. При проведении таких репликации и разделения схема декомпозируется таким образом, что в каждом узле содержится подмножество кортежей, относящихся к некоторому разделу таблицы складов по районам. Это далее будет называться основной стратегией H-Store для разделения и репликации.

5.1 Классы запросов

Все классы транзакций, кроме new_order, уже являются двухфазными, поскольку для них никогда не требуется аварийное завершение. Для транзакций класса new_order может потребоваться аварийное завершение, поскольку во входных данных могут быть указаны неверные номера товаров. Однако в спецификации TPC-C допускается выполнение в начале таких транзакций запросов для каждого номера товара для проверки правильности этих номеров. За счет такой трансформации логики этой транзакции все классы транзакций становятся двухфазными. На самом деле, все они являются строго двухфазными, поскольку таблица Item никогда не модифицируется, и, следовательно, по поводу всех транзакций new_order, отправляемых ко всем репликам, принимается одно и то же решение о продолжении или аварийном завершении.

После применения основной стратегии разделения и репликации все пять классов транзакций оказываются стерильными. В связи с этим поводу авторы делают три наблюдения.

Во-первых, транзакция new_order вставляет кортежи в таблицы Order table и New_Order, а также заносит данные о позициях заказа в таблицу Order-line. В каждом узле эти операции будут являться частью некоторого единственного подплана, и перекрывающихся операций не будет. Это гарантирует, что транзакция order_status не сможет увидеть данные еще не полностью обработанного заказа. Во-вторых, поскольку транзакции new_order и payment в TPC-C являются строго двухфазными, между узлами не требуется какая-либо дополнительная координация даже при обновлении данных удаленного склада.

В третьих, транзакцию stock_level разрешается выполнять как несколько транзакций, которые могут наблюдать уровни запасов разных товаров в разные моменты времени, лишь бы соответствующие данные происходили от зафиксированных транзакций. Но, поскольку, транзакции new_orders при необходимости аварийно завершаются до выполнения каких-либо модификаций, любая информация о запасах будет происходить только от зафиксированных транзакций (или транзакций, которые скоро будут зафиксированы).

Следовательно, все классы транзакций являются стерильными и строго двухфазными. По существу, уже это позволяет правильно выполнить TPC-C без какого-либо управления параллелизмом. Хотя можно было производить тестирование на этой конфигурации, авторы решили еще более повысить производительность, сделав все классы транзакций TPC-C классами с одноразовым использованием результатов.

После применения основной стратегии все классы транзакций, кроме new_order и payment являются одноузловыми и, следовательно, классами с одноразовым использованием результатов. Класс транзакций payment уже является классом с одноразовым использованием результатов, поскольку при обновлении кортежей удаленного склада отсутствует потребность в обменах данными. Однако транзакциям класса new_order требуется вносить в таблицу Order-line информацию о районе, в котором имеется в наличии товар, и эта информация может находиться в другом узле. Поскольку это поле никогда не изменяется, и в таблице Stock отсутствуют удаления и вставки, можно вертикально разделить эту таблицу и реплицировать ее только читаемые части во всех узлах. После применения этой схемы репликации совместно с основной стратегией класс транзакций new_order становится классом с одноразовым использованием результатов.

Таким образом, удается добиться того, что все классы транзакций становятся строго двухфазовыми классами с одноразовым использованием результатов. Если при обработке добавить короткую задержку, упоминавшуюся в подразделе 4.4, то свойства ACID достигаются без каких-либо накладных расходов.

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

Трудно представить, чтобы какая-либо автоматическая программа смогла понять, что требуется для того, чтобы сделать классы транзакций TPC-C стерильными или классами с одноразовым использованием результатов. Эти классы транзакций пришлось бы кодировать знающему человеку. Однако авторам кажется, что большинство классов транзакций анализировать будет проще. Таким образом, успешность автоматического анализа классов транзакций является открытым вопросом.

5.2 Реализация

Авторы реализовали некоторый вариант TPC-C на H-Store и на очень популярной коммерческой РСУБД. Для обеих систем использовался один и тот же драйвер, генерирующий транзакции с наивысшей скоростью без моделирования времени на размышления. В обе системы транзакции доставлялись с использованием TCP/IP. Все классы транзакций реализовывались как хранимые процедуры. В H-Store логика транзакций кодировалась на C++, и для обращения к подсистеме выполнения запросов использовались локальные вызовы процедур. Для коммерческой системы логика транзакций программировалась с применением проприетарного языка хранимых процедур. Ни в одну из систем не включались средства высокой доступности и коммуникаций с терминалами пользователей.

Обе СУБД запускались на компьютере с двухъядерным процессором, работающим на частоте в 2.8 Ггц, с 4 Гб основной памяти и четырьмя жесткими дисками SATA емкостью по 250 Гб. В обеих СУБД использовалось горизонтальное разделение данных.

5.3 Результаты

В этой конфигурации на H-Store выполнялось 70416 транзакций TPC-C в секунду, а на коммерческой системе авторы смогли достичь скорости всего лишь в 850 транзакций в секунду, и для этого потребовалось несколько дней интенсивной работы профессионального администратора баз данных, специализирующегося на администрировании именно этого продукта. Тем самым, H-Store оказалась быстрее в 82 раза (почти на два порядка).

В соответствии с предыдущими обсуждениями, приведенными в этой статье, узким местом коммерческих систем являются накладные расходы на журнализацию. В данном случае коммерческая система проводила 2/3 времени в подсистеме журнализации. Один из авторов статьи потратил много часов в попытках настроить подсистему журнализации (ведение журнального файла на выделенном диске, изменение размера записи о групповой фиксации; все, что было можно). При полном отключении журнализации и отсутствии других узких мест пропускная способность возрастала до 2500 транзакций в секунду.

Как кажется авторам, следующим узким местом традиционной СУБД была подсистема управления параллелизмом. В будущих экспериментах они планируют выяснить, какой вклад в общие накладные расходы этой подсистемы вносят журнализация повторного выполнения операций, журнализация откатов, защелки (latching) и блокировки.

Наконец, хотя авторы не реализовали полностью всю спецификацию TPC-C (например, они не моделировали время ожидания), они считают полезным сравнить свою частичную реализацию с данными об наилучших результатах прогонов TPC-C, представленными на Web-сайте TPC. Наилучшим результатом прогона эталонных тестов TPC-C является показатель 4 миллиона транзакций в минуту, или 133000 транзакций в секунду. Этот результат был получен на машине с разделяемой общей памятью и 128 процессорными ядрами, так что в этой реализации пришлось примерно 1000 транзакций в секунду на одно ядро. Рекомендуется сравнить этот результат с 425 транзакциями в секунду на одно ядро в коммерческой системе, выполняемой на небольшом настольном компьютере, и с 35000 транзакциями на одно ядро в H-Store!

Результаты этого тестирования показывают, что на системе, разработанной в соответствии с принципами H-Store, можно добиться повышения производительности при выполнении тестов TPC-C примерно на два порядка величин.