С.Д. Кузнецов Институт системного программирования РАН ЦИТФорум kuzloc@ispras.ru Московская секция ACM SIGMOD 23 декабря 2010 г. 1. - презентация

1 С.Д. Кузнецов Институт системного программирования РАН ЦИТФорум Московская секция ACM SIGMOD 23 декабря 2010 г. 1

2 Возможность дешевого построения неограниченно горизонтально масштабируемых кластерных привела к активизации исследований и разработок архитектур систем управления данных без совместного использования ресурсов (shared nothing) Два фронта работ: – «NoSQL»: отказ от существующих решений – «один размер непригоден для всех»: прошло время универсальных СУБД; необходимо пользоваться всеми полезными технологиями и идеями, накопленными в сообществе баз данных Московская секция ACM SIGMOD 23 декабря 2010 г. 2

3 Представители обоих фронтов сходятся по первому пункту Второй пункт их разделяет люди из первого лагеря, что технологии баз данных являются тяжким грузом прошлого второй лагерь относится к ним, как к ценному наследию, жертвовать которым нельзя Московская секция ACM SIGMOD 23 декабря 2010 г. 3

4 Ведутся работы в двух наиболее важных направлениях управления данными аналитические системы управления данными транзакционные системы управления данными В прошлые годы разделяло отношение к NoSQL- технологии анализа данных MapReduce Однако это время, как кажется, миновало см. « MapReduce: внутри, снаружи или сбоку от параллельных СУБД? » ( 4

5 Московская секция ACM SIGMOD 23 декабря 2010 г. Цель: разобраться в происходящем в области средств управления данными категории OLTP Значительную часть современных Interner- приложений составляют транзакционные приложения Необходимо уметь легко, быстро и эффективно масштабировать свои системы управления данными речь идет именно о горизонтальном масштабировании 5

6 Московская секция ACM SIGMOD 23 декабря 2010 г. Горизонтальное масштабирование (scaling out) СУБД является необходимым условием развития бизнеса Транзакции обычно являются очень короткими и состоят из простых операций время реакции неперегруженного запросами приложения обычно пользователей вполне устраивает 6

7 Московская секция ACM SIGMOD 23 декабря 2010 г. Однако при взаимодействии пользователя с онлайновым приложением могут возникать задержки из-за недоступности каких-либо ресурсов на уровне управления данными Такие задержки могут оказаться губительными для бизнеса Поэтому не менее важным требованием к СУБД является доступность (availability), гарантирующая отсутствие таких задержек 7

8 Московская секция ACM SIGMOD 23 декабря 2010 г. Хуже всего на отношение клиентов к Internet-компании действуют сообщения типа service unavailable Поэтому многие онлайновые компании готовы согласиться с тем, что в некоторых случаях результаты выполнения транзакций системой управления данными будут некорректными, если при этом доступность системы будет максимально возможной Выстраивается некоторая "теоретическая" база, оправдывающая перед пользователями возможное некорректное поведение приложений тем, что "потребность в извинениях возникает в любом бизнесе" 8

9 Московская секция ACM SIGMOD 23 декабря 2010 г. Более серьезным «теоретическим» основанием NoSQL- разработок, в которых общепринятые полезные свойства СУБД приносятся в жертву доступности этих систем, является так называемая «теорема CAP» впервые сформулированная Эриком Брювером (Eric Brewer) Теорема в кавычках, поскольку утверждение, названное Брювером теоремой, поскольку отсутствует какая-либо четкая и хотя бы немного формальная постановка задачи Распространено мнение, что она означает невозможность поддержки в одной распределенной системе управления данных свойств Consistency, Availability и Partitioning 9

10 Московская секция ACM SIGMOD 23 декабря 2010 г. Обобщая consistency в смысле Брювера до полного набора свойств ACID классических транзакций баз данных, сообщество NoSQL с готовностью отказывается от реальной поддержки транзакций в своих системах NoSQL -> NoACID Не буду касаться "экстремистских" решений для поддержки оналайновых "OLTP"-приложений С практической точки зрения они очень важны, но, не вписываются в контекст доклада у разработок этой категории нет какой-либо общей идеологии, кроме отрицания SQL и ACID 10

11 Московская секция ACM SIGMOD 23 декабря 2010 г. Имеется и другая ветвь - ETH Цюрих и, прежде всего, Дональд Коссманн (Donald Kossmann) Для поддержки ACID-транзакций требуются дополнительные расходы, оплачивать которые пользователи должны только в тех случаях, когда это качество службы управления данными им действительно требуется Вокруг этих идей выполняются интересные исследования и разработки, заслуживающие анализа 11

12 Московская секция ACM SIGMOD 23 декабря 2010 г. Среди работ, в которых не затрагиваются свойства ACID и обеспечивается горизонтальное масштабирование параллельных СУБД, наиболее интересен проект H-Store, в котором участвуют исследователи MIT, Yale и Brown при участии Майкла Стоунбрейкера и Стенли Здоника (Stanley Zdonik) Основана компания VoltDB, выпустившая коммерческий программный продукт с открытыми исходными текстами и лицензией GPL3 12

13 Московская секция ACM SIGMOD 23 декабря 2010 г. Основной упор делается на достижение высокой эффективности и обеспечение линейной горизонтальной масштабируемости при полной поддержке ACID- транзакций Майкл Стоунбрейкер доказывает, что отказ от свойств ACID никоим образом не способствует повышению уровня доступности распределенных систем управления данными Высокой производительности и горизонтальной масштабируемости массивно-параллельных систем баз данных в наибольшей степени мешают распределенные транзакции и, в особенности, их двухфазная фиксация 13

14 Московская секция ACM SIGMOD 23 декабря 2010 г. Устранению отрицательного влияния распределенных транзакций и посвящается большая часть исследований проекта H-Store Кроме того, в параллельных СУБД shared-nothing база данных должна быть разделена на части, каждая из которых управляется локальным компонентом СУБД в отдельном узле кластера Важно научиться так разделять базу данных, чтобы в рабочих нагрузках появлялось как можно меньше распределенных транзакций Предлагается интересный подход к обнаружению методов таких разделений 14

15 Московская секция ACM SIGMOD 23 декабря 2010 г. Параллельным транзакционным СУБД свойственна еще одна проблема, к которой, на мой взгляд, недостаточно внимательно относятся участники проекта H-Store Они отказываются от использования общих ресурсов даже внутри одного узла, в котором установлен компьютер с многоядерным процессором Такой компьютер используется как набор виртуальных изолированных узлов, каждому из которых соответствует ядро процессора В статье Айламаки (Ailamaki ) и др. обосновывается неэффективность такого подхода и предлагается оригинальная архитектура параллельной "одноузловой" СУБД, работающей на машине с многоядерным процессором 15

16 Московская секция ACM SIGMOD 23 декабря 2010 г. Аббревиатура ACID появилась в 1983 г. в статье Тео Хаердера (Theo Haerder) и Адреаса Рейтера (Andreas Reuter) «Транзакция, достигающая своего нормального завершения (EOT – end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвертого свойства – долговечности.» 16

17 Московская секция ACM SIGMOD 23 декабря 2010 г. «Эти четыре свойства – атомарность, согласованность, изоляция и долговечность (ACID) – описывают основные черты парадигмы транзакций, которые влияют на многие аспекты разработки систем баз данных. Поэтому мы считаем, что способность какой-либо системы к поддержке транзакций является пробным камнем (ACID test) качества этой системы.» 17

18 Московская секция ACM SIGMOD 23 декабря 2010 г. Свойства ACID, с одной стороны, можно рассматривать как требования к любой СУБД, претендующей на поддержку транзакций, а с другой стороны, – как определение транзакции в системе баз данных Это определение полностью соответствует житейской практике. Трудно представить, например, чтобы клиент, выполняющий банковскую транзакцию, не расчитывал на удовлетворение банком всех свойств ACID 18

19 Московская секция ACM SIGMOD 23 декабря 2010 г. Свойства ACID являются нераздельными, отбрасывание любого из них делает оставшуются комбинацию бессмысленной Если отбросить свойство согласованности, то мы потеряем критерий корректности транзакции СУБД не сможет каким-либо осмысленным образом принимать решение о допустимости или недопустимости фиксации транзакций, и все проверки корректности выполнения операций при текущем состоянии базы данных придется выполнять в коде приложений 19

20 Московская секция ACM SIGMOD 23 декабря 2010 г. Речь идет о логической согласованности Клиенту банка нужно, чтобы банк работал по установленным им и известным клиентам правилам Клиенту онлайнового магазина нужно, чтобы заказанный и оплаченный им товар был своевременно ему доставлен Ни клиенту банка, ни клиенту Internet-магизина нет никакого дела до внутренней кухни предприятия Нет дела до того, каким образом поддерживается физическая согласованность этого предприятия, каким образом выполняются операции на физическом уровне 20

21 Московская секция ACM SIGMOD 23 декабря 2010 г. Отказ от ACID-транзакций создает немеренные трудности для разработчиков приложений, которым, придется самим реализовывать нечто похожее, чтобы удовлетворить естественные потребности своих клиентов. Свойства ACID, фактически, определяют понятие транзакции Чтобы иметь возможность говорить о транзакционной системе управления данными, в которой не поддерживается свойство согласованности транзакций, необходимо определить, что в этом случае понимается под термином транзакция Сегодня во многих случаях люди говорят о поддержке OLTP- приложений, совершенно не уточняя, что за транзакции имеются в виду 21

22 Московская секция ACM SIGMOD 23 декабря 2010 г. В области распределенных систем имеется свое толкование тех же терминов Термин мгновенная согласованность (immediate consistency) означает, что после того как пользователь получает от системы извещение об успешном выполнении некоторой операции обновления данных, результат этой операции становится мгновенно видимым для всех наблюдателей 22

23 Московская секция ACM SIGMOD 23 декабря 2010 г. Согласованность в конечном счете (eventual consistency) означает, что если в течение достаточно долгого периода времени в систему не поступают новые операции обновления данных, то можно ожидать, что результаты всех предыдущих операций обновления данных в конце концов распространятся по всем узлам системы, и все реплики данных согласуются Скорее всего, Брювер под согласованностью понимал именно мгновенную согласованность данных 23

24 Московская секция ACM SIGMOD 23 декабря 2010 г. Имея в виду этот смысл понятия согласованности, можно считать "теорему" Брювера вполне понятной и очевидной: в любой распределенной системе с разделенными данными можно одновременно обеспечить только любые два свойства из согласованности, доступности и устойчивости к разделению сети 24

25 Московская секция ACM SIGMOD 23 декабря 2010 г. Брювер даже противопоставляет набор свойств ACID предлагаемому им набору свойств BASE Basically Available, Soft-state, Eventual consistency – доступность в большинстве случаев; неустойчивое состояние; согласованность в конечном счете Но это противопоставление неправомерно, поскольку в первом случае речь идет о логических характеристиках транзакций, а во втором – о физических свойствах распределенных систем 25

26 Московская секция ACM SIGMOD 23 декабря 2010 г. Сет Гильберт (Seth Gilbert) и Нэнси Линч (Nancy Lynch) доказали невозможность одновременного обеспечения в одной распределенной системе свойств атомарной согласованности, доступности и устойчивости к разделению сети Но какое отношение это имеет к транзакциям баз данных вообще и к ACID-транзакциям в частности? 26

27 Московская секция ACM SIGMOD 23 декабря 2010 г. «Гильберт и Линч используют вместо термина согласованность термин атомарность, что с технической точки зрения более осмысленно, потому что, строго говоря, согласованность в смысле ACID относится к идеальным свойствам транзакций баз данных и означает, что никакие данные не станут долговременно хранимыми, если они нарушают некоторые заранее установленные ограничения.» 27

28 Московская секция ACM SIGMOD 23 декабря 2010 г. Согласованность по Брюверу не имеет ничего общего с согласованностью в смысле ACID, но именно в системах, ориентированных на обеспечение высокого уровня доступности за счет репликации данных, желательно поддерживать строгую согласованность реплик Это не свойство ACID, а техническая (физическая) особенность массивно- параллельных СУБД, облегчающая разработку приложений 28

29 Московская секция ACM SIGMOD 23 декабря 2010 г. В области транзакционных параллельных систем баз данных отказ consistency по Брюверу в пользу availability и partitioning является плохим компромиссом, поскольку согласованность реплик является очень полезным свойством системы транзакционные массивно-параллельные СУБД не нуждаются в кластерах с очень большим числом узлов, так что ситуации разделения сети маловероятны система может легко стать недоступной не из-за разделения сети, а, например, из-за наличия регулярно проявляющихся программных ошибок 29

30 Московская секция ACM SIGMOD 23 декабря 2010 г. Таким образом, высокая активность представителей лагеря NoSQL связана не с теоретической невозможностью построения массивно-параллельных транзакционных СУБД, поддерживающих ACID- транзакции, а с тем, что упрощенные системы, не поддерживающие не только ACID- транзакции, но и согласованность реплик, создаются проще и быстрее Из-за своей упрощенной организации они способны обеспечивать очень быструю обработку данных, и для ряда приложений это оказывается более важным, чем все удобства, свойственные технологии баз данных 30

31 Московская секция ACM SIGMOD 23 декабря 2010 г. На рынке OLTP с традиционными системами может конкурировать только СУБД, обладающая некоторыми принципиально отличными качествами Потенциально достижимыми новыми качествами является существенно большая пропускная способность транзакций и горизонтальная масштабируемость Такие качества можно обеспечить только при использовании архитектур (shared-nothing) Свидельством правильности этого мнения являются проект H-Store и достижения компании VoltDB 31

32 Московская секция ACM SIGMOD 23 декабря 2010 г. Впервые краткое описание исходных идей проекта H-Store появилось в 2007 г. The End of an Architectural Era (It's Time for a Complete Rewrite) Специализированные транзакционные системы, основанные на следующих пяти основных соображениях 32

33 Московская секция ACM SIGMOD 23 декабря 2010 г. В основной памяти недорогой массивно- параллельной системы уже сейчас можно разместить базу данных объемом до одного терабайта Этого достаточно для большинства приложений OLTP Поэтому будущее за системами транзакционных баз данных, полностью размещаемых в основной памяти 33

34 Московская секция ACM SIGMOD 23 декабря 2010 г. В системах OLTP транзакции являются очень легковесными При работе с базой данных в основной памяти время выполнения наиболее тяжелой транзакции из тестового набора TPC-C составляет менее одной миллисекунды В большинстве приложений отсутствуют задержки по вине пользователей Поэтому имеет смысл выполнять все операции каждой транзакции последовательно в одном потоке управления 34

35 Московская секция ACM SIGMOD 23 декабря 2010 г. В следующем десятилетии будут доминировать компьютерные системы без общих ресурсов, и все СУБД следует оптимизировать в расчете на использование такой архитектуры Если система с N узлами не обеспечивает достаточной мощности, должна иметься возможность добавления к ней дополнительных K узлов без потребности в каких-либо сложных действиях над используемой СУБД 35

36 Московская секция ACM SIGMOD 23 декабря 2010 г. В будущем высокий уровень доступности и отказоустойчивость станут важными чертами рынка OLTP, поэтому: потребуется согласованная репликация данных наиболее эффективной является поддержка архитектуры shared-nothing на всех уровнях системы наилучший способ поддержки архитектуры без общих ресурсов состоит в использовании нескольких машин в одноранговой (peer-to-peer) конфигурации 36

37 Московская секция ACM SIGMOD 23 декабря 2010 г. Основные расходы IT-подразделений уходят на содержание персонала Единственным выходом из этого положения является перевод систем на «самообслуживание» Требуется полный пересмотр процесса настройки системы без явных ручек управления Из всего этого следуют выводы: 37

38 Московская секция ACM SIGMOD 23 декабря 2010 г. Основным препятствием для достижения высокой производительности системы почти наверняка станет журнал повторного выполнения операций, сохраняемый в дисковой памяти Без него можно обойтись за счет подсистемы поддержки высокого уровня доступности и обработки отказов 38

39 Московская секция ACM SIGMOD 23 декабря 2010 г. Следующим по значимости узким местом системы является вызов в ней операций и возврат результатов в приложение Наиболее эффективным способом решения этой проблемы является выполнение логики приложений в виде хранимых процедур внутри системы баз данных 39

40 Московская секция ACM SIGMOD 23 декабря 2010 г. Во всех возможных случаях следует отказаться от поддержки и журнала откатов транзакций, поскольку он тоже будет сдерживать производительность Следует приложить все усилия, чтобы максимально освободиться от затрат на синхронизационные блокировки 40

41 Московская секция ACM SIGMOD 23 декабря 2010 г. Желательно освободиться и от синхронизации на основе "защелок" при доступе к одним и тем же структурам данных из нескольких потоков управления С учетом кратковременности транзакций эти накладные расходы можно устранить путем перехода к однопотоковой модели выполнения транзакций По мере возможности следует избегать применения двухфазного протокола фиксации распределенных транзакций 41

42 Московская секция ACM SIGMOD 23 декабря 2010 г. H-Store выполняется в кластере компьютеров При конфигурировании системы можно указать желаемый уровень ее надежности – число узлов, при выходе из строя которых система может восстановить работоспособность без потери выполняемых транзакций в течение заданного времени В каждом узле строки разделов таблиц размещаются вплотную одна к другой, и доступ к ним производится на основе B-деревьев 42

43 Московская секция ACM SIGMOD 23 декабря 2010 г. В каждом узле H-Store поддерживает ровно один поток управления, в котором полностью, без каких-либо задержек выполняется каждая поступающая операция SQL Узлы, в процессорах которых имеется несколько ядер, разбиваются на соответствующее число логических узлов В H-Store каждый логический узел трактуется так же, как и любой физически независимый узел, и основная память многоядерного компьютера разделяется между логическими узлами 43

44 Московская секция ACM SIGMOD 23 декабря 2010 г. Транзакции представляются в виде хранимых процедур базы данных, и в системе поддерживается только одна внешняя операция Execute transaction (parameter_list) Внутри таких хранимых процедур сочетается логика приложений и операции манипулирования базами данных, причем вызовы SQL производятся, как локальные вызовы Журнал повторного выполнения операций не поддерживается, а журнал отката ведется только для транзакций, не являющихся двухфазными 44

45 Московская секция ACM SIGMOD 23 декабря 2010 г. Для обеспечения возможности использования H- Store без потребности в "ручках управления" планировалось создание средства автоматического проектирования физических схем баз данных (дизайнера баз данных), определяющего горизонтальное разделение, репликацию и выбор ключей индексов Цель дизайнера состоит в том, чтобы сделать как можно больше транзакций одноузловыми (т.е. избежать распределенных транзакций) 45

46 Московская секция ACM SIGMOD 23 декабря 2010 г. Выполнение транзакций в соответствии с временными метками Для выделенных «хороших» классов транзакций не требуются блокировки и двухфазная фиксация Для распределенных транзакций – оптимистические методы (с отслеживанием наборов чтения и записи) На практике исследование методов продолжается 46

47 Московская секция ACM SIGMOD 23 декабря 2010 г. Low Overhead Concurrency Control for Partitioned Main Memory Databases sigmod2010/ sigmod2010/ Многораздельные транзакции поступают через центральный координатор, устанавливающий их глобальный порядок Координатор разбивает транзакцию на фрагменты и посылает их потокам управления соответствующих разделов После получения ответов от этих потоков управления в координаторе выполняется код приложения, может потребоваться рассылка по потокам управления разделов дополнительных фрагментов В каждом разделе фрагменты выполняются последовательно. 47

48 Московская секция ACM SIGMOD 23 декабря 2010 г. Основная идея спекулятивного выполнения состоит в том, что когда в некотором потоке управления основного раздела возникает задержка из-за выполнения двухфазного протокола распределенной фиксации транзакций, этот поток не простаивает, а выполняет другие фрагменты транзакций из своей входной очереди 48

49 Московская секция ACM SIGMOD 23 декабря 2010 г. Это выполнение на фоне фиксации транзакции является спекулятивным результаты спекулятивно выполненных транзакций будут некорректными, если транзакция, на фоне фиксации которой эти транзакции выполняются, не зафиксируется, а откатится Спекулятивно выполненные транзакции не фиксируются до тех пор, пока не будет зафиксирована первая транзакция, в случае ее отката – все тоже откатываются Очевидно, что спекулятивная схема обеспечивает сериальный план выполнения транзакций 49

50 Московская секция ACM SIGMOD 23 декабря 2010 г. Блокировочная схема почти всегда существенно уступает и спекулятивной схеме, и схеме с синхронизационными блокировками Спекулятивная схема работает значительно лучше двух других схем при наличии многораздельных транзакций с одним циклом коммуникаций транзакции с координатором и небольшой доли аварийно завершающихся транзакций Схема с синхронизационными блокировками обеспечивает наилучшие результаты при наличии многих транзакций с несколькими циклами коммуникаций 50

51 Московская секция ACM SIGMOD 23 декабря 2010 г. The Case for Determinism in Database Systems При детерминированной сериализации смеси транзакций {T1, T2,..., Tn} требуется эквивалентность плана выполнения этих транзакций некоторому предопределенному последовательному плану их выполнения (T i1, T i2,..., T in ) Предлагается использовать синхронизационные блокировки, но с гарантией эквивалентности получаемого сериального плана предопределенному плану 51

52 Московская секция ACM SIGMOD 23 декабря 2010 г. Если двум транзакции Ti и Tj требуются блокировки одной и той же записи r, и в предопределенном плане Ti находится раньше, чем Tj, то Ti должна запросить блокировку r раньше, чем Tj Каждая транзакция, не ожидающая удовлетворения запроса блокировки, должна продолжать выполняться до тех пор, пока не зафиксируется или не будет завершена аварийным образом детерминированным образом Если выполнение какой-либо транзакции задерживается, то система должна поддерживать эту транзакцию активной, пока она не завершится, или пока не будет ликвидирована сама система 52

53 Московская секция ACM SIGMOD 23 декабря 2010 г. Детерминированная схема непригодна для СУБД, работающих с базами данных в дисковой памяти Однако в системах, обрабатывающих данные исключительно в основной памяти, ситуация меняется В ряде случаев детерминизм позволяет повысить производительность систем, упрощая при этом репликацию и избавляя от потребности в двухфазном протоколе фиксации распределенных транзакций 53

54 Московская секция ACM SIGMOD 23 декабря 2010 г. Для поддержки упорядоченности запросов блокировок в предлагается запрашивать все блокировки, требуемые для каждой транзакции, перед началом ее выполнения Если это возможно, то после этого транзакция выполняется вплоть до своего завершения (над данным разделом), не освобождая блокировок Однако не для всех транзакций заранее известно, какие записи в них будут читаться и изменяться 54

55 Московская секция ACM SIGMOD 23 декабря 2010 г. T(x): y := read(x) write(y) Зависимость первого порядка; преобразуется в T1(x): y := read(x) запрос_следующей_транзакции(T2(x, y)) T2(x, y): y´ := read(x) if (y´ y) запрос_следующей_транзакции(T2(x, y)) abort() else write(y) 55

56 Московская секция ACM SIGMOD 23 декабря 2010 г. Возможны зависимости более высокого порядка, но встречаются редко Детерминированная обработка многораздельных транзакций описана только на уровне общей идеи Перспектива обойтись без двухфазного протокола фиксаций за счет детерминированного выполнения транзакций кажется очень привлекательной и потенциально достижимой Как бы только не оказалось, что для этого требуется еще более сложный статический анализ транзакций 56

57 Московская секция ACM SIGMOD 23 декабря 2010 г. Schism: a Workload-Driven Approach to Database Replication and Partitioning Многораздельные транзакции останутся более дорогостоящими, чем однораздельные Нужно стремится к тому, что в любой рабочей нагрузке OLTP их было как можно меньше Для этого нужно должным образом физически организовать разделенную и реплицированную базу данных 57

58 Московская секция ACM SIGMOD 23 декабря 2010 г. Методы циклического разделения и хэш- разделения, как правило, не подходят для транзакционных массивно-параллельных систем баз данных, поскольку способствуют появлению большого числа многораздельных транзакций Хорошие результаты может обеспечить разделение по диапазонам значений кортежей, но выбор соответствующих диапазонов с учетом заданной рабочей нагрузки вручную производить очень трудно 58

59 Московская секция ACM SIGMOD 23 декабря 2010 г. В Schism на основе однораздельного представления базы данных и заданной рабочей нагрузки производится разделение базы данных на заданное число сбалансированных разделов с целью минимизации числа многораздельных транзакций в рабочей нагрузке Далее система пытается аппроксимировать полученное разделение разделением по диапазонам значений на основе автоматически производимого условного выражения 59

60 Московская секция ACM SIGMOD 23 декабря 2010 г. Наконец, производится сравнение числа распределенных транзакций в исходной рабочей нагрузке, получаемого при применении полученного метода разделения, с числом распределенных транзакций, которые возникают при использовании хэш- разделения и разделения на уровне таблиц, и для реального использования выбирается метод, обеспечивающий наилучший результат 60

61 Московская секция ACM SIGMOD 23 декабря 2010 г. Основные черты H-Store бескомпромиссное использование подхода shared- nothing – каждому разделу базы данных (основному или резервному) соответствует в точности один поток управления, и в потоках управления не используются общие ресурсы, даже если они реализуются ядрами одного и того же процессора поддержка баз данных в основной памяти; долговременность хранения обеспечивается только за счет репликации данных в разных узлах кластера 61

62 Московская секция ACM SIGMOD 23 декабря 2010 г. выполнение транзакций поблизости от данных без потребности в передаче по сети операций SQL и их результатов стремление к минимизации числа распределенных транзакций за счет статического анализа и преобразований транзакций, а также за счет разделения данных с учетом рабочей нагрузки 62

63 Московская секция ACM SIGMOD 23 декабря 2010 г. Чудеса производительности именно при наличии только однораздельных транзакций Появление распределенных транзакций полностью исключить не удастся, и поэтому основной текущей задачей проекта H-Store является нахождение способов выполнения распределенных транзакций, которые позволили бы свести к минимуму накладные расходы на их фиксацию Тем не менее, VoltDB успешно работает 63

64 Московская секция ACM SIGMOD 23 декабря 2010 г. В H-Store приносятся в жертву аппаратные возможности многоядерных процессоров, позволяющие на физическом уровне использовать все ресурсы компьютера в потоках управления всех ядер Кажется очень поучительным проект DORA, в котором разрабатывается архитектура СУБД, обладающая свойствами shared-nothing на логическом уровне, но использующая аппаратные возможности shared- everything на физическом уровне Data-Oriented Transaction Execution

65 Московская секция ACM SIGMOD 23 декабря 2010 г. В качестве экспериментальной аппаратной платформы в DORA использовался компьютер Sun T5220 "Niagara II« 8 ядер, в каждом из которых на аппаратном уровне поддерживается 8 потоков управления, т.е. на уровне операционной системы в компьютере имеется 64 процессора, каждому из которых доступны все остальные ресурсы системы 65

66 Московская секция ACM SIGMOD 23 декабря 2010 г. Используется транзакционная система управления базами данных Shore-NT полная изоляция на основе иерархических блокировок управление буферным пулом индексы на основе B-деревьев классическое управление журнализацией и восстановлением баз данных Каждой транзакции назначается отдельный поток управления 66

67 Московская секция ACM SIGMOD 23 декабря 2010 г. По мере роста числа активных транзакций растет объем работы, требуемой для удовлетворения запросов на получение или освобождение блокировок, поскольку удлиняются списки запросов блокировок Дополнительные обходы списков блокировок нужны для выявления синхронизационных тупиков Возникающие последствия губительны для производительности системы 67

68 Московская секция ACM SIGMOD 23 декабря 2010 г. 68

69 Основные идеи DORA (Data-ORiented Architecture) состоят в следующем: потоки управления связываются не с транзакциями, а с отдельными частями базы данных система распределяет работу каждой транзакции по потокам управления в соответствии с тем, к каким данным обращается транзакция при обработке запросов система по мере возможности избегает взаимодействий с централизованным менеджером блокировок Московская секция ACM SIGMOD 23 декабря 2010 г. 69

70 Несмотря на наличие многих неясностей, основная идея DORA – при наличии в системе физически общих ресурсов производить разделение данных не на физическом, а на логическом уровне – кажется очень привлекательной Прототип DORA рассчитан на традиционную работу с дисками, в нем поддерживаются общая система буферов и журнализация (на уровне Shore-NT) и поэтому: можно спокойно делить данные на логическом уровне с точностью до кортежа (все буферные страницы доступны всем потокам управления) в нем удается обойтись без двухфазного протокола фиксации транзакций и он плохо согласуется с общими идеями H-Store Московская секция ACM SIGMOD 23 декабря 2010 г. 70

71 Однако мне кажется, что возможен компромисс между архитектурами H-Store и DORA внутри одного многоядерного компьютера для поддержки баз данных в основной памяти без журнализации изменений Для этого нужно добиться полного отсутствия потребности в централизованных блокировках Подробности в моей статье Московская секция ACM SIGMOD 23 декабря 2010 г. 71

72 Будущее поколение ACID-транзакционных систем будет опираться на две основные параллельные архитектуры одноузловую и многоузловую Одноузловая архитектура предполагает наличие мощного многоядерного компьютера и использование энергонезависимой внешней памяти, в которой, в частности, должен поддерживаться журнал повторного выполнения транзакций И в этом направлении хороший фундамент закладывает DORA Московская секция ACM SIGMOD 23 декабря 2010 г. 72

73 Многоузловая архитектура строится на основе достаточно большого числа, вообще говоря, недорогих компьютеров, связанных сетью Базы данных хранятся только в основной памяти, для обеспечения отказоустойчивости используется репликация В этом направлении хорошей основой является H- Store (и VoltDB), хотя следовало бы учесть возможности использования физически общих ресурсах в многоядерных узлах подобных систем Московская секция ACM SIGMOD 23 декабря 2010 г. 73

74 К сожалению, эти две архитектуры являются взаимноисключающими Трудно представить компанию, которая хорошо потратилась на приобретение мощного многоядерного сервера с дорогой дисковой подсистемой, а потом решается отказаться от использования дисков и перейти к использованию многоузловой архитектуры Трудно представить себе и ситуацию, когда сначала был выбран подход с использованием дешевых кластерных архитектур почти без дисков, а потом вдруг покупается отдельный дорогой сервер, и компания переходит к использованию одноузловой архитектуры Так что, скорее всего, будет продолжать существовать и направление shared disks, свойственное, например, Oracle, поскольку оно позволяет достаточно эффективно использовать кластеры, построенные с использованием мощных дисковых серверов, которые до этого использовались автономно Московская секция ACM SIGMOD 23 декабря 2010 г. 74

75 Новый подход к оптимизации СУБД Rethinking Cost and Performance of Database Systems Новые тенденции: для многих Web-приложений строгая согласованность данных в соответствии с парадигмой ACID не требуется; требуется масштабируемость до миллионов пользователей и гарантированное время ответа использование SOA «облачные вычисления» Московская секция ACM SIGMOD 23 декабря 2010 г. 75

76 В «прошлой» жизни в системе управления данными при заданном наборе аппаратных ресурсов и полноценной поддержке ACID-транзакций требовалось минимизировать время ответов на запросы и максимизировать пропускную способность системы Московская секция ACM SIGMOD 23 декабря 2010 г. 76

77 В новых условиях при заданных требованиях к производительности приложений (пиковая пропускная способность, максимально допустимое время ответа) требуется минимизировать требуемые аппаратные ресурсы и максимизировать согласованные данные Московская секция ACM SIGMOD 23 декабря 2010 г. 77

78 Основным показателем системы баз данных, нуждающемся в оптимизации, является денежная оценка затрат Производительность является заданным ограничением приложения, а не целью оптимизации Московская секция ACM SIGMOD 23 декабря 2010 г. 78

79 Традиционная архитектура системы баз данных Московская секция ACM SIGMOD 23 декабря 2010 г. 79

80 Архитектура Sausalito (28msec.com) Московская секция ACM SIGMOD 23 декабря 2010 г. 80

81 Основные функции СУБД – обработка запросов и управление транзакциями – переносятся на прикладной уровень На нижнем уровне поддерживается только распределенное хранение данных за счет использования службы Amazon S3 Согласованность данных поддерживается не на уровне хранения, а на прикладном уровне Отсутствует какой-либо объект, контролирующий весь доступ к данным, и согласованность данных обеспечивается за счет применения во всех серверах приложений общих протоколов распределенных систем Московская секция ACM SIGMOD 23 декабря 2010 г. 81

82 Все данные и заранее откомпилированный код приложения сохраняются в среде Amazon S3 в виде BLOB'ов При обработке каждого HTTP-запроса (поступающего, например, по инициативе пользователя из Web-браузера) служба Amazon EC2 c учетом балансировки нагрузки выбирает доступный сервер EC2 В этом сервер из S3 загружается код приложения, который затем интерпретируется подсистемой поддержки времени выполнения Sausalito с доступом при необходимости к объектам базы данных, хранимым в S3 Особенностью Sausalito является то, что для реализации логики приложений и доступа к базе данных в системе используется язык XQuery, расширенный средствами обновления данных и написания скриптов Московская секция ACM SIGMOD 23 декабря 2010 г. 82

83 У системы с такой архитектурой с мало шансов сравняться с классическими системами баз данных в отношении производительности и согласованности данных – Это обратная сторона отказа от принципов контроля над данными и пересылки запросов Однако эта архитектура хорошо соответствует новым требованиям Архитектура экономически эффективно реализуется с использованием дешевых аппаратных средств, масштабируемость на всех уровнях обеспечивается автоматически Гибкость достигается за счет упрощения платформы и использования на всех уровнях единой модели программирования и данных (XML/XQuery) Для многих рабочих нагрузок обеспечивается предсказуемость расходов и производительности Московская секция ACM SIGMOD 23 декабря 2010 г. 83

84 Consistency Rationing in the Cloud: Pay only when it matters Основная идея исследования состоит в том, что не все данные требуется обрабатывать на одном и том же уровне согласованности Например, в онлайновом магазине данные о кредитных картах клиентов и состоянии их счетов должны поддерживаться на более высоком уровне согласованности, чем данные о предпочтениях покупателей Обеспечение дополнительных уровней согласованности значительно повышает стоимость выполнения операций С другой стороны, стоимость несогласованности данных также можно измерить, оценив относительное число операций, которые выполняются некорректно из-за отсутствия согласованности, и переведя эту оценку в денежные расходы Московская секция ACM SIGMOD 23 декабря 2010 г. 84

85 Нахождение баланса между стоимостью выполнения операций, согласованностью данных и их доступностью является нетривиальной задачей Этот баланс зависит от нескольких факторов, включая семантику приложений Предлагается использовать динамическую стратегию поддержки согласованности данных – снижать уровень требований к согласованности, когда это не приводит к слишком большим убыткам, и повышать их, если убытки могут оказаться слишком большими Этот подход называется рационализацией согласованности (consistency rationing) по аналогии с понятием рационализации управления запасами (inventory rationing), когда запасы отслеживаются в разной точности в зависимости от их наличного объема Московская секция ACM SIGMOD 23 декабря 2010 г. 85

86 Все управляемые данные разделяются на три категории A, B и C, и для каждой категории применяются свои методы обработки в зависимости от обеспечиваемого уровня согласованности К категории A относятся данные, нарушение согласованности которых привело бы к крупным убыткам Несогласованность данных категории C является приемлемой (несогласованность либо вызывает лишь небольшие убытки, либо в действительности не возникает) Наконец, категория B включает данные, требования к согласованности которых изменяются во времени Для данных категории B можно добиться оптимального соотношения расходов на выполнение операций и обеспечиваемого уровня согласованности Московская секция ACM SIGMOD 23 декабря 2010 г. 86

87 Гарантии согласованности в обеспечиваются для данных, а не для транзакций В результате ослабляются только свойства изоляции и согласованности ACID-транзакций, а атомарность и долговечность обеспечиваются в полном объеме Для данных возможны два уровня согласованности – сессионная согласованность (session consistency) и сериализуемость (serializability) Сессионная согласованность данных подразумевает, что клиенты подключаются к системе в контексте сессий Во время сессии система гарантирует монотонность по чтению собственных записей – результат записи процесса в элемент данных x всегда виден последующим операциям чтения x того же процесса За границы сессии гарантии монотонности не распространяются Московская секция ACM SIGMOD 23 декабря 2010 г. 87

88 Для данных категории A обеспечивается сериализуемость в традиционном транзакционном смысле Все транзакции, модифицирующие данные категории A, изолируются и оставляют данные согласованными – здесь имеются в виду и согласованность в смысле ACID, и строгая согласованность в смысле распределенных систем Для поддержки сериализуемости требуются значительные накладные расходы, и данные следует относить к категории A, только если их согласованность и актуальность являются обязательными Для поддержки сериализуемости используется двухфазный протокол синхронизационных блокировок Московская секция ACM SIGMOD 23 декабря 2010 г. 88

89 Для данных категории B во время работы системы на основе разработанных авторами политик производится переключение между режимами сессионной согласованности и сериализуемости Если одна транзакция работает с некоторой записью в режиме сериализуемости, а другая обновляет ее в режиме сессионной согласованности, то обеспечивается сессионная согласованность Если в одной транзакции одновременно обрабатываются данные категорий A и C, то при выполнении операции чтения данных категории A эта транзакция всегда получает их последнее согласованное состояние и оставляет их согласованными после своей фиксации При чтении данных категории C транзакция может получить их в несогласованном и/или устаревшем состоянии Московская секция ACM SIGMOD 23 декабря 2010 г. 89

90 Разработчики Sausalito вполне смогли справиться с поддержкой ACID-транзакций и ослабляют требования к согласованности совсем не на основе ограничений, которые ставит теорема CAP, а с целью вполне разумной оптимизации стоимости службы управления данными Московская секция ACM SIGMOD 23 декабря 2010 г. 90

91 Теорема CAP Эрика Брювера не имеет никакого отношения к возможности или невозможности поддержки ACID- транзакций в горизонтально масштабируемых кластерных системах Проект H-Store показывает, что в параллельной архитектуре shared-nothing основную проблему представляют распределенные транзакции, накладные расходы на фиксацию которых могут заметно снижать пропускную способность системы Однако полученные результаты показывают, что для ряда важных типов рабочей нагрузки этих расходов можно избежать Московская секция ACM SIGMOD 23 декабря 2010 г. 91

92 Другую проблему транзакционных параллельных систем без совместно используемых ресурсов составляет потребность в массовой физической пересылке данных при балансировке нагрузки И здесь может несколько помочь подход проекта DORA, в котором вместо физического разделения данных в многоядерном компьютере используется их логическое разделение за счет наличия общей памяти Московская секция ACM SIGMOD 23 декабря 2010 г. 92

93 Наконец, подход Sausalito показывает, что при отказе от основных принципов разработки СУБД – контроля над данными и передачи запросов – в угоду более точному следованию архитектуре SOA расходы на поддержку ACID-транзакций существенно возрастают эта поддержка по-прежнему возможна, и разумна оптимизация системы управления данными, позволяющая снизить расходы на управление транзакциями, если приложениям не требуется качественная согласованность данных Московская секция ACM SIGMOD 23 декабря 2010 г. 93

94 Исследования и разработки массивно- параллельных транзакционных СУБД в ближайшие годы будут активно продолжаться, и нам предстоит еще увидеть и услышать много интересного Полный текст статьи: Транзакционные параллельные СУБД: новая волна Московская секция ACM SIGMOD 23 декабря 2010 г. 94

95 Московская секция ACM SIGMOD 23 декабря 2010 г. 95