OLTP в Зазеркалье

         

Рабочая нагрузка OLPTP


Тестовый набор, используемый авторами, происходит от TPC-C [TPCC], в котором моделируется оптовый поставщик запасных частей, работающий с несколькими складами и связанными с ними торговыми участками. Тестовый набор TPC-C разработан для представления любой прикладной области, в которой требуется регулировать, продавать или распространять некоторые продукты или услуги. В нем учитывается потребность в масштабировании, когда поставщик расширяет свой бизнес и создаются новые склады. С каждого склада продукция должна поставляться в 10 торговых участков, и каждый торговый участок должен обслуживать 3000 заказчиков. Схема базы данных, в которой учитываются требования масштабирования (число складов W является параметром), показана на рис. 3. Размер базы данных для одного склада составляет около 100 мегабайт (авторы экспериментировали с пятью складами, т.е. с базой данных общим размером в 500 мегабайт).


Рис. 3. Схема TPC-C

TPC-C включает смесь из пяти параллельных транзакций разных типов и сложности. В их число входят транзакции регистрации заказов (New Order), учета платежей (Payment), доставки заказов, проверки состояния заказов и отслеживания уровня запасов на складах. В TPC-C также специфицируется, что около 90% времени выполняются первые две транзакции. Для лучшего понимания эффекта своих оптимизаций и модификаций авторы экспериментировали со смесью только первых двух транзакций. Структура их кода (вызовов Shore) показана на рис. 4. Для достижения повторяемости экспериментов в исходные спецификации внесены следующие небольшие изменения.


Рис. 4. Вызовы методов Shore в транзакциях New Order и Payment

New Order. Каждая транзакция New Order размещает заказ из 5-15 пунктов, и 90% заказов полностью удовлетворяется за счет запасов «соседнего» склада заказчика (для 10% заказов требуется доступ к запасам удаленного склада). Чтобы избежать изменчивости результатов авторы установили число пунктов заказа в 10 и всегда обслуживают заказы из локального склада. Эти два изменения не влияют на пропускную способность. Код на рис. 4 демонстрирует двухфазную оптимизацию, упоминавшуюся в подразделе 2.5, которая позволяет избежать аварийного завершения транзакции. Сначала читаются все пункты заказа, и если среди них обнаруживается что-то недопустимое, то приложение аварийно завершается без потребности в откате базы данных.

Payment. Это легковесная транзакция. Она обновляет баланс заказчика и поля «склад/торговый участок», а также генерирует запись истории. Здесь снова имеется выбор между соседним и удаленным складами, и авторы всегда выбирают соседний склад. Еще одна возможность случайного выбора состоит в том, ищется ли заказчик по имени, или же по идентификатору, и авторы всегда используют идентификаторы.



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