Научно-образовательный IT-форум

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » Научно-образовательный IT-форум » Доклады и заметки » Гибридные технологии консервативных СУБД больших объемов

Гибридные технологии консервативных СУБД больших объемов

Страница: 1
Ответить

Сообщений 1 страница 5 из 5

1

  • landwatersun
  • Автор: landwatersun
  • Последний визит:
    Сегодня 19:50:28

ГИБРИДНЫЕ ТЕХНОЛОГИИ КОНСЕРВАТИВНЫХ СУБД БОЛЬШИХ ОБЪЕМОВ,
ДОСТУПНЫЕ ШИРОКОМУ КРУГУ ОРГАНИЗАЦИЙ
В.А. Райхлин, Р.К. Классен (КНИТУ-КАИ)

Обсуждаются новые принципы организации консервативных СУБД (с эпизодическим обновлением данных в специально выделяемое время) на сравнительно недорогих кластерных платформах с применением средств MySQL и GPU-акселераторов на исполнительном уровне. Актуальность принятой ориентации на работу с базами данных больших объемов определяется современными тенденциями интеллектуальной обработки больших информационных массивов. Повышение объема баз данных требует их хеширования по узлам кластера. Это обуславливает необходимость использования регулярного плана обработки запросов. Применение однородных кластерных технологий (СУБД Clusterix) требует дополнительно динамической сегментации промежуточных и временных отношений. В отличие от СУБД Clusterix и более совершенной мультикластерной СУБД Clusterix-M для управления базами данных больших объемов предложены гибридные технологии (проекты Clusterix-N и Clusterix-G) с разделением кластера на две части, что позволяет исключить динамическую сегментацию. Одна из них выполняет селектирование и проецирование над хешированной по узлам базой данных (блок IO). Другая – соединение по схеме «ядро на запрос» (блок JOIN). Отличительной особенностью СУБД Clusterix-G с GPU-акселераторами является работа со сжатыми базами данных, что позволяет увеличить их объем при ограниченных объемах оперативной памяти узлов. Функции графических ускорителей в разных частях своеобразны. В блоке IO они выполняют функции разжатия-селектирования исходных отношений и сжатия получаемых промежуточных отношений. В блоке JOIN – функцию разжатия поступивших промежуточных отношений. Проведенный теоретический анализ показал, что предложенные технологий значительно более эффективны в сравнении с Clusterix-M, а по производительности СУБД Clusterix-G должна в разы превышать Clusterix-N для интерконнекта среднего быстродействия.

ПРЕЗЕНТАЦИЯ ДОКЛАДА

ВИДЕО ДОКЛАДА:

2

  • Автор: Ghoooster
  • Последний визит:
    2018-03-14 18:04:28

1. Что можно предпринять если запрос(-ы) с большим объемом операций join не были выполнены системой?
2.Почему Clusterix-N увеличивает быстродействие, преимущественно перед Clusterix-G, если использовать более быструю сеть?
3. Чем объясняется преимущество СУБД Clusterix перед MySQL Cluster?

Отредактировано Ghoooster (2017-12-26 15:10:44)

3

  • rozh
  • Автор: rozh
  • Последний визит:
    2019-04-12 08:56:54

1. Что можно предпринять если запрос(-ы) с большим объемом операций join не были выполнены системой?

Можно дождаться освобождения памяти на исполнительных узлах и запустить запрос заново. Или использовать диски для хранения промежуточных отношений (медленно, но зато отказа не будет). Еще можно просто вернуть ошибку пользователю :)

Почему Clusterix-N увеличивает быстродействие, преимущественно перед Clusterix-G, если использовать более быструю сеть?

В многоядерной системе с большим количеством узлов узкое место - сеть и передача данных. В Clusterix-G GPU используются для сжатия/разжатия данных. При увеличении пропускной способности сети время сжатия/разжатия может не только приблизиться к времени передачи данных, но и превзойти его, что сделает операцию сжатия/разжатия новым узким местом системы.

Чем объясняется преимущество СУБД Clusterix перед MySQL Cluster?

У MySQL Cluster есть 2 хорошие вещи: резервирование и отказоустойчивость. Скорость работы оставляет желать лучшего, особенно для больших аналитических запросах. Это происходит в первую очередь из-за стратегии работы "клиент на ядро", т.е. для выполнения одного запроса от одного клиента будет задействовано всего 1 ядро.

Clusterix же нацелен на возможность совмещения различных операций на разных узлах и не ограничивается 1 ядром для одного запроса. Он может работать как в режиме "все узлы и ядра на 1 запрос", так и в режимах "узел на запрос", "ядро на запрос". Как раз первый режим и обеспечивает максимальную производительность на большом объеме данных.

Если моя информация по MySQL Cluster устарела - поправьте :)

4

  • Автор: Vitaly Nikitin

Добрый день!
Насколько оправдано использование Clusterix-G с графическими ускорителями для сжатия/разжатия перед Clusterix-N на высокоскоростной сети, например, InfiniBand? Не является ли использование бОльшей пропускной способности и низкой задержкой сети, т.е. переход на современную коммутируемую компьютерную сеть, более приоритетным направлением для работы с хранилищем данных?
Так же вопрос по СУБД. Как я понимаю, MySQL не является принципиально влияющей СУБД на скорость тестов, предложенных в докладе?

5

  • rozh
  • Автор: rozh
  • Последний визит:
    2019-04-12 08:56:54

Насколько оправдано использование Clusterix-G с графическими ускорителями для сжатия/разжатия перед Clusterix-N на высокоскоростной сети, например, InfiniBand?

С сетью 10 Gigabit Ehernet выигрыш G системы перед N составляет ~30%. InfiniBand обладает пропускной способностью близкой к шины PCI-e. Поэтому никакого существенного выигрыша G системы перед N не будет. Даже наоборот, разжатие данных и передача их по PCI-e (в GPU и обратно) может занять время большее, чем просто передача по InfiniBand.

Главный недостаток InfiniBand - это его стоимость. Далеко не каждая организация может себе ее позволить.

MySQL не является принципиально влияющей СУБД на скорость тестов, предложенных в докладе?

MySQL является отправной точкой для расчетов и реализации. Если использовать другую СУБД, то цифры изменятся. Например, СУБД PostgreSQL выполняет запросы теста TPCH за примерно то же время, что и СУБД MySQL, но некоторые запросы обрабатываются дольше, другие быстрее.

Объем передаваемых данных по сети не зависит от СУБД. Выбор СУБД по большей части влияет на скорость выполнения JOIN и SORT.

Поскольку узкое место в системе - сеть, то да. MySQL не является принципиально влияющей СУБД на скорость тестов, предложенных в докладе.

Ответить
Страница: 1

Быстрый ответ

Напишите ваше сообщение и нажмите «Отправить»


Вы здесь » Научно-образовательный IT-форум » Доклады и заметки » Гибридные технологии консервативных СУБД больших объемов