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

         

Многопотоковость и управление ресурсами


OLTP-транзакции являются очень легковесными. Например, в наиболее тяжелой транзакции из TCP-C считывается около 400 записей. При работе с базами данных в основной памяти полезная работа такой транзакции занимает менее одной миллисекунды даже при использовании низкопроизводительных компьютеров. Кроме того, в большинстве известных авторам статьи средах OLTP отсутствуют «задержки по вине пользователей» («user stall»). Например, когда на сайте Amazon пользователь нажимает на кнопку «buy it», он активизирует OLTP-транзакцию, данные от которой будут возвращены пользователю только после ее завершения. По причине отсутствия дисковых операций и задержек по вине пользователей фактическая продолжительность OLTP-транзакции является минимальной. В таком мире имеет смысл выполнять все команды SQL в рамках последовательных транзакций с использованием однопотоковой модели исполнения, а не тратить время и другие ресурсы на изоляцию параллельно выполняемых операторов.

Современные РСУБД представляют собой тщательно разработанные многопотоковые системы, ориентированные на полное использование ресурсов ЦП и дисков. Это позволяет выполнять в параллель много запросов. Кроме того, в этих системах имеются подсистемы, предназначенные для предотвращения перегрузки системных ресурсов, чтобы не возникла ситуация исчерпания IP-соединений, дескрипторов файлов, основной памяти, требуемой для выполнения сортировок, и т.д. В однопотоковой системе не требуется подсистема регулирования ресурсов.

При использовании однопотоковой модели исполнения не требуются структуры данных, для которых поддерживается параллельный доступ. Поэтому можно полностью обойтись, например, без сложного кода, требуемого для поддержки параллельного доступа к B-деревьям. Это позволяет создавать более надежные системы, обладающие более высокой производительностью.

Может возникнуть вопрос: «А как быть с долго выполняемыми командами?». Ответ состоит в том, что в реальных OLTP-системах таких команд просто нет. Во-первых, операции, которые могли бы привести к долговременно выполняемым транзакциям, такие как ввод данных для покупки в Internet-магазине, обычно расщепляются на несколько транзакций, чтобы время выполнения каждой из них оставалось небольшим. Другими словами, в правильно разработанном OLTP-приложении поддерживаются только короткие транзакции. Во-вторых, долго выполняемые произвольные (ad-hoc) запросы направляются в систему хранилища данных, которая оптимизируется для выполнения именно таких операций. Нет никаких оснований заставлять систему OLTP решать проблемы, не относящиеся к OLTP. Такой подход применяется только в «безразмерном» мире.



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