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

Предположения о транзакциях, обработке и среде


Если предположить наличие grid’а из вычислительных систем с хранением баз данных в основной памяти, наличие встроенных средств поддержки высокого уровня доступности, отсутствие задержек транзакций по вине пользователей и продолжительность работы транзакций в пределах одной миллисекунды, то становятся очевидными следующие выводы:

  1. Долговременно хранимый журнал повторного выполнения операций почти гарантированно является существенным узким местом для достижения высокой производительности. Даже при использовании групповой фиксации транзакций принудительное выталкивание на диск записей о фиксации может добавить миллисекунды к общему времени выполнения каждой транзакции. Обсуждавшаяся ранее система поддержки высокого уровня доступности и обработки отказов позволяет легко освободиться от этой архитектурной особенности.
  2. Если отказаться от журнала повторного выполнения операций, то, вероятно, следующим по значимости узким местом будет вызов операций в системе и передача ответных параметров приложению. Накладные расходы интерфейсов в стиле JDBC/ODBC станут обременительными, и придется использовать что-либо более эффективное. В частности, авторы статьи выступают за выполнение логики приложения – в форме хранимых процедур – «в процессе» внутри системы базы данных вместо того, чтобы испытывать накладные расходы межпроцессных взаимодействий, свойственные традиционной клиент-серверной модели.
  3. Во всех случаях, когда это целесообразно, следует отказаться и от журнала откатов, поскольку он тоже будет являться существенным узким местом.
  4. Следует приложить все усилия, чтобы избавиться от затрат на традиционные динамические блокировки для управления параллелизмом, которые тоже будут являться узким местом.
  5. Вероятно, будет обременительной и синхронизация на основе «защелок» (latching), связанная с доступом к одним и тем же структурам данных из нескольких потоков управления. Притом, что время выполнения транзакций будет коротким, эти накладные расходы можно устранить с незначительным падением производительности путем перехода к однопотоковой модели исполнения.
  6. По мере возможности следует избегать применения двухфазного протокола фиксации (two-phase commit protocol, 2PC) распределенных транзакций, поскольку сетевые задержки, возникающие при двухсторонних коммуникациях в 2PC, часто достигают порядка миллисекунд.

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



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