The 25 reference contexts in paper Alexander Boichenko V., Dmitry Rogojin K., Dmitry Korneev G., Александр Бойченко Викторович, Дмитрий Рогожин Константинович, Дмитрий Корнеев Геннадьевич (2016) “МЕТРИКИ ДЛЯ ДИНАМИЧЕСКОГО МАСШТАБИРОВАНИЯ БАЗ ДАННЫХ В ОБЛАЧНЫХ СРЕДАХ // METRICS FOR DYNAMIC SCALING OF DATABASE IN CLOUDS” / spz:neicon:statecon:y:2013:i:6:p:189-195

  1. Start
    638
    Prefix
    Эта способность позволяет повысить отказоустойчивость, уровень доступности и производительность сервиса путем перехода от статического выделения ресурсов сервису к динамическому выделению по требованию в соответствии с текущей нагрузкой.
    Exact
    [1]
    Suffix
    Рост интереса к горизонтальному масштабированию баз данных привел к появлению нового течения в хранении и обработке данных – NoSQL решениям, большинство из которых изначально проектировались с поддержкой устойчивости к разделению данных по сети.
    (check this in PDF content)

  2. Start
    1169
    Prefix
    Классические реляционные СУБД: Oracle, MySQL, MS SQL Server также стремятся к поддержке устойчивости к разделению по сети в специальных «кластерных» версиях своих продуктов, жертвуя полноценными ACID транзакциями в пользу eventual consistency – «согласованность в конечном итоге»
    Exact
    [4]
    Suffix
    . В условиях предоставления инфраструктуры для программных сред по требованию, актуальными стали вопросы возможности динамического масштабирования баз данных. Под динамическим масштабированием подразумевается свойство системы программно регулировать ресурсы, не требуя оперативного вмешательства пользователя.
    (check this in PDF content)

  3. Start
    1942
    Prefix
    Возможности динамического масштабирования серверов на основе набора триггеров и метрик предоставляют своим клиентам такие компании, как Amazon (на основе решений CloudWatch и ElasticCloud), Rackspace (на основе решений Rackspace Cloud Monitoring и Otter). Создаваемая система TIRAMOLA
    Exact
    [10]
    Suffix
    – совместный труд греческих университетов National Technical University of Athens и Ionian University – позволяет динамически масштабировать некоторые NoSQL СУБД с поколоночной моделью данных. Однако, общие методики динамического масштабирования БД с различными моделями данных, основанные на комплексном анализе метрик функционирования БД, в настоящий момент проработаны недостаточно.
    (check this in PDF content)

  4. Start
    6328
    Prefix
    Реализации репликации и шардинга в современных СУБД. База данныхРежимы репликацияМеханизм шардинга Документо-ориентированные MongoDBМастер-подчиненный Auto-sharding (на основе “осколков” (Shards) и “кусков” (Chunks))
    Exact
    [12]
    Suffix
    CouchDBМульти-мастер Встроенной поддержки нет. Осуществляется сторонними решениями [11]: CouchDb-Lounge, BigCouch, Gizzard Ключ-значение RiakМульти-мастерAuto-sharding (на основе Ring Partitions) RedisМастер-подчиненный Встроенной поддержки нет.
    (check this in PDF content)

  5. Start
    6414
    Prefix
    База данныхРежимы репликацияМеханизм шардинга Документо-ориентированные MongoDBМастер-подчиненный Auto-sharding (на основе “осколков” (Shards) и “кусков” (Chunks)) [12] CouchDBМульти-мастер Встроенной поддержки нет. Осуществляется сторонними решениями
    Exact
    [11]
    Suffix
    : CouchDb-Lounge, BigCouch, Gizzard Ключ-значение RiakМульти-мастерAuto-sharding (на основе Ring Partitions) RedisМастер-подчиненный Встроенной поддержки нет. Осуществляется сторонними решениями [15]: Redis Cluster, Twemproxy, Predis Поколоночные (Столбцовые) HBaseМастер-подчиненныйAuto-sharding(на основе Регионов (Regions)) CassandraМульти-мастер Auto-sharding (на основе Ring Partitions) [8
    (check this in PDF content)

  6. Start
    6606
    Prefix
    Осуществляется сторонними решениями [11]: CouchDb-Lounge, BigCouch, Gizzard Ключ-значение RiakМульти-мастерAuto-sharding (на основе Ring Partitions) RedisМастер-подчиненный Встроенной поддержки нет. Осуществляется сторонними решениями
    Exact
    [15]
    Suffix
    : Redis Cluster, Twemproxy, Predis Поколоночные (Столбцовые) HBaseМастер-подчиненныйAuto-sharding(на основе Регионов (Regions)) CassandraМульти-мастер Auto-sharding (на основе Ring Partitions) [8] Графовые Neo4jМастер-подчиненный Полноценной поддержки нет.
    (check this in PDF content)

  7. Start
    6796
    Prefix
    Осуществляется сторонними решениями [15]: Redis Cluster, Twemproxy, Predis Поколоночные (Столбцовые) HBaseМастер-подчиненныйAuto-sharding(на основе Регионов (Regions)) CassandraМульти-мастер Auto-sharding (на основе Ring Partitions)
    Exact
    [8]
    Suffix
    Графовые Neo4jМастер-подчиненный Полноценной поддержки нет. Частично реализован в технологии Cache Sharding [18] OrientDBМульти-мастерНет Реляционные Oracle DatabaseМульти-мастер, Мастер-подчиненный Только для Oracle Real Application Clusters [16] MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster) [19] MS SQL ServerМастер-подчиненный,
    (check this in PDF content)

  8. Start
    6903
    Prefix
    Осуществляется сторонними решениями [15]: Redis Cluster, Twemproxy, Predis Поколоночные (Столбцовые) HBaseМастер-подчиненныйAuto-sharding(на основе Регионов (Regions)) CassandraМульти-мастер Auto-sharding (на основе Ring Partitions) [8] Графовые Neo4jМастер-подчиненный Полноценной поддержки нет. Частично реализован в технологии Cache Sharding
    Exact
    [18]
    Suffix
    OrientDBМульти-мастерНет Реляционные Oracle DatabaseМульти-мастер, Мастер-подчиненный Только для Oracle Real Application Clusters [16] MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster) [19] MS SQL ServerМастер-подчиненный, Multi-source Data-Dependent Routing (для MS SQL Server), Federation (для SQL Azure) [13] PostgreSQL Мульти-масте
    (check this in PDF content)

  9. Start
    7031
    Prefix
    (Столбцовые) HBaseМастер-подчиненныйAuto-sharding(на основе Регионов (Regions)) CassandraМульти-мастер Auto-sharding (на основе Ring Partitions) [8] Графовые Neo4jМастер-подчиненный Полноценной поддержки нет. Частично реализован в технологии Cache Sharding [18] OrientDBМульти-мастерНет Реляционные Oracle DatabaseМульти-мастер, Мастер-подчиненный Только для Oracle Real Application Clusters
    Exact
    [16]
    Suffix
    MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster) [19] MS SQL ServerМастер-подчиненный, Multi-source Data-Dependent Routing (для MS SQL Server), Federation (для SQL Azure) [13] PostgreSQL Мульти-мастер, Мастер-подчиненный Встроенной поддержки нет.
    (check this in PDF content)

  10. Start
    7135
    Prefix
    Частично реализован в технологии Cache Sharding [18] OrientDBМульти-мастерНет Реляционные Oracle DatabaseМульти-мастер, Мастер-подчиненный Только для Oracle Real Application Clusters [16] MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster)
    Exact
    [19]
    Suffix
    MS SQL ServerМастер-подчиненный, Multi-source Data-Dependent Routing (для MS SQL Server), Federation (для SQL Azure) [13] PostgreSQL Мульти-мастер, Мастер-подчиненный Встроенной поддержки нет. Осуществляется сторонними решениями [14]: PL/Proxy, HadoopDB, PgBouncer. стоящее время среди существующих методов горизонтального масштабирования, имеющих поддержку в реляционных БД и NoSQL решениях,
    (check this in PDF content)

  11. Start
    7247
    Prefix
    Cache Sharding [18] OrientDBМульти-мастерНет Реляционные Oracle DatabaseМульти-мастер, Мастер-подчиненный Только для Oracle Real Application Clusters [16] MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster) [19] MS SQL ServerМастер-подчиненный, Multi-source Data-Dependent Routing (для MS SQL Server), Federation (для SQL Azure)
    Exact
    [13]
    Suffix
    PostgreSQL Мульти-мастер, Мастер-подчиненный Встроенной поддержки нет. Осуществляется сторонними решениями [14]: PL/Proxy, HadoopDB, PgBouncer. стоящее время среди существующих методов горизонтального масштабирования, имеющих поддержку в реляционных БД и NoSQL решениях, принято выделять репликацию, секционирование (партицирование) и шардинг. [2, 3] Репликация – это процесс, под которым пони
    (check this in PDF content)

  12. Start
    7355
    Prefix
    Только для Oracle Real Application Clusters [16] MySQL Мульти-мастер, Мастер-подчиненный, «Круговая» репликация Auto-Sharding (только в версии MySQL Cluster) [19] MS SQL ServerМастер-подчиненный, Multi-source Data-Dependent Routing (для MS SQL Server), Federation (для SQL Azure) [13] PostgreSQL Мульти-мастер, Мастер-подчиненный Встроенной поддержки нет. Осуществляется сторонними решениями
    Exact
    [14]
    Suffix
    : PL/Proxy, HadoopDB, PgBouncer. стоящее время среди существующих методов горизонтального масштабирования, имеющих поддержку в реляционных БД и NoSQL решениях, принято выделять репликацию, секционирование (партицирование) и шардинг. [2, 3] Репликация – это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот.
    (check this in PDF content)

  13. Start
    7594
    Prefix
    Осуществляется сторонними решениями [14]: PL/Proxy, HadoopDB, PgBouncer. стоящее время среди существующих методов горизонтального масштабирования, имеющих поддержку в реляционных БД и NoSQL решениях, принято выделять репликацию, секционирование (партицирование) и шардинг.
    Exact
    [2, 3]
    Suffix
    Репликация – это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот. Существует около 10 видов репликации серверов баз данных: мульти-мастер (multi-master, master-master), мастер-подчинённый (master-slave), мульти-источник (multysource), мастер-подчинённый-мастер (master-slave-master), мульти-сервер (multi-server parallel query execution
    (check this in PDF content)

  14. Start
    8049
    Prefix
    Существует около 10 видов репликации серверов баз данных: мульти-мастер (multi-master, master-master), мастер-подчинённый (master-slave), мульти-источник (multysource), мастер-подчинённый-мастер (master-slave-master), мульти-сервер (multi-server parallel query execution), сектор-подчинённый (mirror data partitioning) и др.
    Exact
    [5]
    Suffix
    Несмотря на то, что репликация теоретически является бесконечно наращиваемым решением, она способна решить только проблемы чтения данных из БД. Увеличение числа серверов становится нецелесообразным, когда появляются проблемы с записью данных в БД. [3] Секционирование (партицирование) – средство масштабирования многих современных реляционных баз данных, которое позволяет разбивать таблиц
    (check this in PDF content)

  15. Start
    8302
    Prefix
    (master-slave-master), мульти-сервер (multi-server parallel query execution), сектор-подчинённый (mirror data partitioning) и др. [5] Несмотря на то, что репликация теоретически является бесконечно наращиваемым решением, она способна решить только проблемы чтения данных из БД. Увеличение числа серверов становится нецелесообразным, когда появляются проблемы с записью данных в БД.
    Exact
    [3]
    Suffix
    Секционирование (партицирование) – средство масштабирования многих современных реляционных баз данных, которое позволяет разбивать таблицы, индексы и индекс-таблицы на части, таким образом, обеспечивая контроль и доступ к данным объектам базы данных на более низком уровне.
    (check this in PDF content)

  16. Start
    8916
    Prefix
    Таблицы секционируются с использованием «ключа секционирования», набора столбцов, определяющих, в какой секции будет располагаться заданная запись. Более подробно механизмы реализации секционирования описаны в
    Exact
    [6, 7]
    Suffix
    . Существенным минусом механизма секционирования применительно к горизонтальному масштабированию уровня БД является то, что секционирование не выходит за рамки одного сервера. То есть, полученные в результате секции объектов физически располагаются на том же сервере.
    (check this in PDF content)

  17. Start
    9925
    Prefix
    Подобно процессу секционирования, при шардинге выбирается «ключ шардирования», определяющий, на каком сервере будут располагаться части данных. Логика поиска сервера, на котором располагаются необходимые данные, заимствована из алгоритма разбиения пространства ключей DHT (англ. Distributed Hash Table – «распределённая хеш-таблица»).
    Exact
    [8]
    Suffix
    В основе этого способа разбиения лежит функция δ(k1, k2), определяющая абстрактное понятие расстояния между ключами k1 и k2. Каждому узлу присваивается единичный ключ, называемый его идентификатором (ID).
    (check this in PDF content)

  18. Start
    10242
    Prefix
    Distributed Hash Table – «распределённая хеш-таблица»). [8] В основе этого способа разбиения лежит функция δ(k1, k2), определяющая абстрактное понятие расстояния между ключами k1 и k2. Каждому узлу присваивается единичный ключ, называемый его идентификатором (ID). Узел с ID in владеет всеми ключами km, для которых in – самый ближайший ID, вычисленный с помощью δ(km, in).
    Exact
    [9]
    Suffix
    Наиболее удобным является механизм так называемого авто-шардинга (auto-sharding), при котором реализация логики процесса шардинга осуществляется средствами самой СУБД. В таком случае нет необходимости реализовывать ее самостоятельно в рамках программного кода приложения или применять сторонние решения в качестве дополнительного промежуточного слоя.
    (check this in PDF content)

  19. Start
    12155
    Prefix
    Такое ограничение в реляционных БД волне логично – проектировщику БД предоставляется выбор: что важнее – полноценная поддержка транзакций в нераспределенной среде или поддержка устойчивости к разделению по сети с согласованностью в конечном итоге (ограничения теоремы CAP
    Exact
    [17]
    Suffix
    ). Для графовых БД отсутствие шардинга объясняется теми же ограничениями, поскольку большинство СУБД, основанных на графовых моделях, имеют полноценную поддержку ACID транзакций подобно традиционным реляционным базам данных. [18] В свою очередь, реляционные СУБД имеют более широкий диапазон выбора методов репликации, апробированных в процессе многолетнего использования реляционных БД. 3.
    (check this in PDF content)

  20. Start
    12387
    Prefix
    Для графовых БД отсутствие шардинга объясняется теми же ограничениями, поскольку большинство СУБД, основанных на графовых моделях, имеют полноценную поддержку ACID транзакций подобно традиционным реляционным базам данных.
    Exact
    [18]
    Suffix
    В свою очередь, реляционные СУБД имеют более широкий диапазон выбора методов репликации, апробированных в процессе многолетнего использования реляционных БД. 3. Масштабирование в облачной инфраструктуре Динамическое масштабирование в облачной инфраструктуре возможно благодаря использованию технологии виртуализации и предоставляемому облачной платформой открытому API.
    (check this in PDF content)

  21. Start
    12978
    Prefix
    Виртуализация позволяет выделять ресурсы сервису по требованию в виде порций – виртуальных машин, а открытое API позволяет это делать программными средствами. Большое распространение получила библиотека euca2ools
    Exact
    [20]
    Suffix
    , совместимая с публичным облаком Amazon AWS и приватными облаками на базе Eucalyptus и OpenStack. Используя API облачной платформы напрямую или через euca2ools, клиенты могут производить запуск и остановку виртуальных машин в облаке, основываясь на собственных алгоритмах выделения ресурсов по требованию.
    (check this in PDF content)

  22. Start
    13951
    Prefix
    Большинство реализованных систем динамического масштабирования используют для организации процесса масштабирования метрики, основанные на базовых показателях жизнедеятельности сервера, на котором располагается база данных: информацию о процессоре, оперативной памяти, жестком диске и сети. В частности, система динамического масштабирования кластера поколоночных (столбцовых) СУБД TIRAMOLA
    Exact
    [10]
    Suffix
    – совместная разработка греческих университетов National Technical University of Athens и Ionian University – использует в качестве основной метрики текущую загрузку процессора (CPU Usage). Подсистема динамического масштабирования системы TIRAMOLA реализует следующий алгоритм.
    (check this in PDF content)

  23. Start
    14531
    Prefix
    В случае, когда хотя бы для одного из серверов в кластере верно условие CPU Usage > 40%, срабатывает триггер добавления виртуальных машин в кластер. В случае, когда для всех серверов кластера справедливо условие CPU Usage < 15%, срабатывает триггер высвобождения виртуальных машин из кластера. В
    Exact
    [10]
    Suffix
    приводятся положительные результаты работы такого алгоритма для СУБД HBase, Cassandra и Riak, имеющих схожую реализацию механизмов авто-шардинга на основе Ring Partitions. Однако, на наш взгляд, базовых метрик жизнедеятельности серверов недостаточно для комплексного подхода к масштабированию БД с различными моделями данных.
    (check this in PDF content)

  24. Start
    15736
    Prefix
    Метрики, используемые для масштабирования Современные системы мониторинга обладают широкими возможностями для наблюдения за показателями СУБД. Многие из них предоставляют модули для мониторинга популярных БД в базовой комплектации или, в противном случае, расширение функционала через сторонние плагины. В частности, плагин mikoomi
    Exact
    [22]
    Suffix
    для популярной системы мониторинга Zabbix поддерживает около 80 метрик для документо-ориентированной СУБД MongoDB. Такое большое количество показателей связано, в первую очередь, со сложной архитектурой любой из Рис. 1.
    (check this in PDF content)

  25. Start
    16112
    Prefix
    Такое большое количество показателей связано, в первую очередь, со сложной архитектурой любой из Рис. 1. Модель архитектуры системы динамического масштабированиясовременных СУБД. Примерно такое же число метрик приведено в
    Exact
    [21]
    Suffix
    для нескольких популярных реляционных СУБД. В контексте статьи метрики, значения которых предоставляются непосредственно системой мониторинга, будем называть базовыми. Поскольку кластер БД, как объект мониторинга, является комплексным, получаемые метрики целесообразно разделить на логические группы.
    (check this in PDF content)