Почти "shared-nothing" в среде "shared-everything" – от переводчика
В последнее время специалисты в области баз данных больше всего говорят про архитектуры параллельных СУБД без совместного использования ресурсов, ориентированные на поддержку как аналитических, так и транзакционных приложений. Это, в частности, подтверждается выборкой статей, переводы которых были опубликованы в библиотеке CITForum в последние несколько лет. Активный интерес к архитектурам shared-nothing естественным образом объясняется возможностями неограниченного горизонтального масштабирования аппаратных средств за счет использования кластерных систем, в узлах которых применяются компьютеры из категории товаров широкого потребления (commodity).
Но задумаемся, что такое сегодня "компьютер массового спроса"? Этот компьютер снабжается, как минимум, двухъядерным (а завтра четырехъядерным, а послезавтра восьмиядерным) процессором, в ядрах которого на аппаратном уровне поддерживается выполнение нескольких потоков управления. Т.е. это мощная параллельная машина, и не использовать ее параллелизм для поддержки локальных СУБД, входящих в состав параллельной СУБД без совместного использования ресурсов, по меньшей мере, безнравственно, а по большому счету, экономически нецелесообразно.
Кроме того, на переднем крае развития микропроцессорной технологии находятся такие процессоры, как использованный в работе авторов представляемой вам статьи процессор Sun T5220 "Niagara II", уже сегодня обеспечивающий (с точки зрения операционной системы) 64-процессорную систему с общей памятью. При наличии правильно спроектированной СУБД мощности "однопроцессорной" системы, оснащенной таким процессором (а послезавтра процессором "массового спроса"), хватит для поддержки системы OLTP не самого мелкого предприятия.
Так что развитие технологии СУБД, выполняемых на машинах с общим использованием всех ресурсов, является очень актуальной задачей. Однако, как показывают авторы статьи, по мере роста числа ядер и совершенствования реального использования параллелизма в СУБД узким местом становится традиционный централизованный менеджер блокировок.
В представленной авторами архитектуре DORA эта проблема решается путем логического разделения таблиц базы данных по потокам управления. В каждом таком потоке управления (исполнителе) выполняются части транзакций (действия), обращающиеся только к данным соответствующего раздела, и логическая синхронизация доступа большей частью рассредоточена по исполнителям.
Иначе говоря, на основе аппаратной архитектуры с совместным использованием всех ресурсов строится архитектура СУБД, в которой на логическом уровне общие ресурсы не используются, хотя сам этот логический уровень реализуется с использованием общих ресурсов. Авторы особо подчеркивают, что именно наличие физической общности ресурсов позволяет добиться эффективности предлагаемой ими архитектуры СУБД.
Результаты экспериментов, приводимые в статье, убедительно показывают, что архитектура DORA обеспечивает производительность OLTP-ориентированной СУБД, существенно превосходящую производительность традиционных систем, в которых используются традиционные централизованные менеджеры блокировок. Однако при наличии массы технических подробностей (временами скрывающих суть архитектуры) некоторые важные, на мой взгляд, проблемы в статье затушевываются.
Во-первых, как и для всех архитектур с разделением данных (неважно, физических или логических) проблемой является выбор способа разделения (в статье соответствующие правила называются правилами маршрутизации). Авторы говорят об этих правилах, как о чем-то данном им свыше, хотя иногда говорится, что они могут меняться при работе системы. Как они будут меняться, в соответствии с каким критериями, остается непонятно.
Второе непонятное для меня место касается работы с индексами. Из контекста статьи понятно, что индексы организуются в виде B+-деревьев. Понятно, что для рабочих нагрузок OLTP, транзакции которых читают и изменяют считанные единицы записей, поиск в B+-дереве и особенно изменение B+-дерева могут составлять значительную часть работы, которую тоже было бы желательно распараллеливать.Однако в статье этот аспект полностью умалчивается.
Поскольку авторы статьи продолжают работу над DORA, очень может быть, что в будущих публикациях эти и другие темные места будут разумным образом прояснены. Пока же очевидно, что DORA прокладывает путь системам управления базами данных в будущий (не столь уж отдаленный) мир со сто- или даже тысячеядерными процессорами. И слава Богу, что становятся более понятными способы их использования.
Сергей Кузнецов
