Однопотоковый режим в системах OLTP
Во всех современных СУБД имеется обширная поддержка многопотокового режима, включая набор протоколов транзакционного управления параллелизмом, а также насыщенность кода командами кратковременных блокировок («защелок», latch), обеспечивающими корректность доступа нескольких потоков управления к совместно используемым структурам, таким как буферные пулы и индексные страницы. Традиционные аргументы в пользу многопотокового режима состоят в том, что он позволяет избежать простоя при обработке нескольких транзакций, когда одна или несколько транзакций ждут поступления данных с диска, а также предотвратить торможение длинными транзакциями выполнения коротких транзакций.
Авторы утверждают, что ни один из этих аргументов более не является весомым. Во-первых, если базы данных постоянно находятся в основной памяти, то никогда не возникает потребность в ожидании обменов с диском. Кроме того, производственные транзакционные системы не предполагают какого-либо ожидания действий пользователей – транзакции почти всегда выполняются на основе хранимых процедур. Во-вторых, рабочие нагрузки в системах OLTP являются очень простыми. Типичная транзакция состоит в выполнении нескольких индексных поисков и обновлений, которые в системе баз данных в основной памяти могут быть выполнены за сотни микросекунд. Более того, при разделении современной индустрии баз данных на рынки обработки транзакций и хранилищ данных долговременные (аналитические) запросы теперь обслуживаются системами хранилищам данных.
Одна из проблем состоит в том, что многопотоковый режим требуется для поддержки машин с несколькими процессорами. Однако авторы полагают, что эту проблему можно решить путем трактовки одного физического узла с несколькими процессорами как нескольких узлов кластера без совместно используемых ресурсов, возможно, управляемого монитором виртуальной машины, которая динамически распределяет ресурсы между этими логическими узлами [BDR97].
Еще одной проблемой является то, что сети становятся новыми дисками, привнося задержки в распределенные транзакции и требуя повторного выполнения транзакций. Безусловно, это верно в общем случае, но для многих транзакционных приложений можно разделить рабочую нагрузку таким образом, чтобы она стала «одноузловой» («single-sited») [Hel07, SMA+07], и каждая транзакция могла полностью выполняться в одном узле кластера.
Следовательно, в некоторых классах приложений баз данных не требуется поддержка многопотокового режима. В таких системах унаследованный код для поддержки блокировок и защелок становится неоправданным накладным расходом.
