Back to Search
Start Over
Способи організації сумісного доступу до розподілених сторінок пам'яті в системах хмарних обчислень
- Publication Year :
- 2017
- Publisher :
- КПІ ім. Ігоря Сікорського, 2017.
-
Abstract
- В роботі запропоновано спосіб доступу до спільних ресурсів, який дозволяє виключити пов'язані з блокуванням перевантаження та знизити вимоги до каналів передачі даних. Його впровадження дозволить використовувати глобальну мережу як транспорт хмарних СКБД, внаслідок уникання перевантажень при доступі до спільних ресурсів. У роботі обґрунтовується необхідність скорочення часу відклику для зниження ймовірності перевантаження. Для вирішення проблеми використовуються три методи: метод двофазного виконання транзакції, метод конвеєризації фаз та метод призначення обробника ресурсу. Перші два використовують закешовані в процесі попередньої обробки версії сторінок для визначення списку необхідних спільних ресурсів на першій фазі, а під час другої фази повторно виконують транзакцію вже з актуальними сторінками. Метод конвеєризації фаз виконує фази в конвейері, що ефективніше для транзакцій зі слабозакешованими ресурсами. Метод призначення обробника ресурсу зменшує черги до сторінок, що інтенсивно оновлюються. Суть методу - фіксація для кожної «гарячої» сторінки вузлу обробки, для мінімізації кількості мережевих пересилань при обробці ресурсів в черзі. Для оцінки ефекту способу розроблена математична модель, яка складається з моделі затримок, для оцінки тривалості доступу до сторінок пам'яті, моделі конфліктів – для оцінки ефекту блокувань, та модель трафіків для синтезу трафіків. The thesis is devoted to the problem of shared resource processing optimization in a cloud computing systems. There is proposed access technique to shared resource, which allows exclude the overloadings, associated with locks in the cloud environment and reduce the requirements for data transfer channels. The paper substantiates the need to reduce response time for reducing overloading probability. To solve the problem are used three methods: the method of two-phase transaction execution, method of piping phases and method of resource handler assigning. The first two use cached old versions of pages to determine required list of resources during first phase, and reexecute transaction on second phase to confirm ACID. The piping phase method is more efficient for transactions with low-cached resources due to piping approach. Method of resource handler assigning reduces queues to intensively updated resource pages. The key idea of method is fixing for each "hot" page processing node, thereby minimizing the number of network hops during page access. To estimate the effect of the method the author offers three-component mathematical model consisting of: delay models to determine the duration of access to memory page, the model of conflict - to evaluate the effect of blocking, and traffic model – to synthesize traffic. Диссертация посвящена проблеме оптимизации работы с общими ресурсами в глобальных системах облачных вычислений. В условиях растущих требований к объёмам накопления, преобразования и обеспечения жизненного цикла информации, возникает тенденция по переносу баз данных в облачную среду. Особенности обработки общего ресурса в современных СУБД выдвигают повышенные требования по времени отклика к каналам передачи данных между узлами СУБД. Предлагаемый в работе способ доступа к общим ресурсам позволяет исключить перегрузки, связанные с блокировками в облачной среде, снизить требования к каналам передачи данных при её развёртывании как по времени отклика, так и по пропускной способности. Применение предлагаемых новаций позволяет рассматривать в качестве транспорта в облачных СУБД не только высокопродуктивные коммутаторы, расположенные внутри одного ЦОДа, но и глобальную сеть, объединяющую ресурсы нескольких ЦОДов, в том числе распределённых географически. Предлагаемый способ доступа является дополняющим к способу, используемому в современных облачных СУБД на базе shared everything архитектуры, что предполагает включение в себя традиционных алгоритмов доступа, успешно зарекомендовавших себя в реализации shared everything архитектуры (на примере Oracle RAC). Это позволяет динамически выбирать наиболее адекватный обрабатываемому трафику алгоритм как из набора традиционных алгоритмов, так и инновационных, предлагаемых в работе. Основной акцент предлагаемых новаций посвящен проблеме возникновения перегрузок при доступе к общим ресурсам. В работе обосновывается необходимость сокращения времени отклика для снижения вероятности перегрузки. В качестве способов решения проблемы предлагаются 2 подхода, реализованные в трёх методах. Первый подход реализован в методе двухфазного выполнения транзакции и методе конвейеризации фаз. Предлагается использовать закешированные в процессе предыдущей обработки версии страниц при определении списка необходимых общих ресурсов. Использование этих страниц данных – оптимистический подход, поскольку страницы инвалидированы, и, возможно, именно из-за запрашиваемых данных. Но оптимистичность позволяет асинхронно разослать запросы на общие ресурсы, не выстраивая цепочку последовательных обращений, увеличивающих время отклика. Это целесообразно также и потому, что оценка времени определения взаимозависимости транзакций и ресурсов сопоставима с выполнением транзакции без её фиксации. Таким образом, первый раз (первая фаза) транзакция выполняется, используя неактуальные страницы. Завершающим этапом метода (второй фазой) является повторное выполнение транзакции с уже полученными актуальными страницами, а затем проверка и исправление ошибок, возникших из-за оптимистического подхода первой фазы для удовлетворения требований ACID. Различие методов, реализующих подход в том, что конвейеризация рассмотренных фаз показывает лучшую эффективность транзакций включающих слабо закешированные ресурсы. В качестве «платы» за выигрыш во времени выступает более чем двукратное увеличение объёма операций на каждом узле, что требует определения области целесообразности применения методов. Второй подход – метод назначения обработчика ресурса – позволяет уменьшить возникающие при высоких интенсивностях обращения к страницам очереди к страницам. Эта проблема для традиционного способа доступа shared everything, реализованного в Oracle RAC, выдвигает высокие требования ко времени отклика между узлами, и, в контексте переноса в облачную среду, является ключевой. Суть метода – зафиксировать для каждой «горячей» страницы узел обработки, минимизировав таким образом количество сетевых пересылок при последовательной обработке ресурсов в очереди. Негативным эффектом метода является увеличение объёма межузлового трафика. Для оценки эффекта способа в контексте исследования области целесообразности автором предложена трёхкомпонентная математическая модель. Первый компонент – модель задержек, описывающая сценарии обработки страницы памяти необходима для вычисления времен обработки страницы. Второй компонент – модель конфликтов отражает существующий в shared everything архитектуре (на примере Oracle RAC) способ блокирования ОР в контексте взаимосвязей этих ресурсов с транзакциями. Модель конфликтов предполагает стационарность потока входящих заявок, разбиваемых на последовательности обработки. И третьим компонентом является модель трафика, главной целью которой является определение входящих параметров для модели конфликтов и модели задержек. В работе рассматриваются 3 вида трафиков – первые 2 предложены автором для наиболее полного освещения особенностей предлагаемых новаций, а 3й является синтетическим тестом (TPC BENCHMARK Standard Specification Revision 5.11) широко используемым для определения производительности программно-аппаратных комплексов в ИТ индустрии.
- Subjects :
- перевантаження
shared everything architecture
очередь
cloud computing
СКБД
черга
locks
shared everything архітектура
СУБД
хмарні обчислення
блокування
облачные вычисления
overloading
страница памяти
page of memory
сторінка пам'яті
queue
перегрузка
004.07(043.3) [004.65]
блокировка
shared everything архитектура
DBMS
Oracle RAC
Subjects
Details
- Language :
- Ukrainian
- Database :
- OpenAIRE
- Accession number :
- edsair.od......2635..fe7602e882ca028f8672baeb98d8c6af