Здравствуйте.

На самом деле модуль MGM в данном случае совершенно не нагружен. С ним начинаются проблемы при работе с большим количеством конкурирующих запросов. Но это решается распараллеливанием конвейера обработки запросов в MGM. В данной версии параллелизм реализован только на долгих стадиях конвейера.

Конечно есть. Например, загрузка данных в СУБД занимает существенную долю времени обработки. Удаление данных из СУБД тоже занимает довольно много времени. Проблему можно решить заменой СУБД на более производительную с поддержкой In-Memory Database или использованием собственного движка.

Еще одно узкое место - это хеширование на GPU. В случае использования 10GigabitEthernet потребуется 5-6 видеокарт уровня Tesla M2075 для обеспечения скорости хеширования сопоставимой со скорость передачи по сети.

PerformSys обрабатывает сразу 72 запроса, против 1 у Clusterix-N. Вся база умещается в ОЗУ узла и система не ожидает получения данных с дисков (ровно как и Clusterix-N). Но Clusterix-N передает данные по сети и распределяет нагрузку по узлам. Как раз  на передачи и уходит большая часть времени.

Как раз хешированный JOIN на множестве узлов и был использован в экспериментах, он и обуславливает использования всего кластера для обработки всего запроса.

Интегрированный JOIN, требует загрузки всех временных отношений в память узлов JOIN для каждого запроса и исполняется на 1 ядре. Т.е. на GPU кластере КНИТУ-КАИ в конфигурации MGM 2xIO 4xJOIN одновременно будет обрабатываться до 48 запросов. Такой join выгодно применять для небольших БД, но, опять же, передача данных занимает большое количество времени и большая часть процессорных ядер на уровне JOIN будет простаивать. Так что производительность все равно была бы хуже, чем PerformSys, т.к. требуется передача по сети.

Последовательный JOIN требует наличия на узле всего двух отношений для выполнения операции join. Метод экономит память, но работает существенно медленнее интегрированного JOIN. Его можно применять при работе с большими БД с высокой интенсивностью запросов. Но при 60 ГБ PerformSys будет быстрее, т.к. он использует интегрированный JOIN и не передает промежуточные данные по сети.

MySQL Memory хранит данные в выровненной структуре, т.е. если максимальный размер одной строки таблицы 200 байт, то она и будет занимать в памяти 200 байт, даже если в строке не записано столько данных. Например, БД TPC-H размером 1 ГБ после загрузки в этот движок занимает более 1.5 ГБ и это еще без индексов. Хотелось бы применить сжатие, но сжатие требует дополнительных вычислительных ресурсов, а движок создан для максимального быстродействия.

Время удаления данных в этом движке увеличивается с фрагментацией памяти узла. Т.е. со временем память выделяется все меньшими блоками и очистка всех блоков (а она происходит последовательно) занимает значительное время.

К тому же этот движок, в отличии от остальных, не хранит данные на диске. При выключении питания все содержимое таблиц на этом движке будет очищено.

Еще у этого движка имеются проблемы с блокировками. Операции записи блокируют таблицу целиком, поэтому многопоточное изменение одной таблице невозможно. А операции изменения схемы (например, удаление таблицы) блокируют всю БД. Поэтому в Clusterix-N удаление начинается только после завершения всех операций.

На самом деле движок хороший. Быстрый, работает в ОЗУ, не требует диска (то, что нам и нужно ). И, самое главное, в PostgreSQL нет ничего подобного.

Первоначальная реализация хеширования на CPU позволяла выполнять хеширование со скоростью 20-25 МБ/с на 1 ядре. Параллельная реализация позволила ускорить хеширование до  50-60 МБ/с на 12 ядрах. Такой низкий прирост производительности, вероятно, получился из-за наличия всего 4-х каналов ОЗУ. Следующая реализация (которая и использовалась в экспериментах) была выполнена на GPU. Она показала производительность ~200-250 МБ/с на Tesla M2075.

Скорость передачи данных по GigabitEthernet не превышает 100 МБ/с. Поэтому процесс хеширования идет быстрее передачи данных по сети. Если бы эксперимент проводился с сетью 10GigabitEthernet, то узким местом системы было бы хеширование данных.

Здравствуйте!

После просмотра Вашего доклада у меня появилось несколько вопросов:
1. Какая конфигурация дисковой подсистемы использовалась в тестах PerformSys и Clusterix-N? Использовался ли RAID (программный или аппаратный)? Какие-нибудь СХД? Пробовали ли Вы использовать SSD? Насколько я понял из Вашего доклада, то главным "узким местом" в системе PerformSys являются именно операции ввода/вывода. Т.е. теоретически, если использовать более быстрый ввод/вывод, то результаты PerformSys будут лучше?
2. Немного не понял, как работает связь между инструментальной СУБД и параллельной СУБД. Вся работа идет через инструментальную СУБД, но "за кулисами" драйвер передает выполнение запросов в параллельную СУБД? Я правильно понимаю?
3. Инструментальной СУБД может быть только MySQL или есть драйверы для других СУБД (например, Oracle, MS SQL Server и т.д.)?
4. Клиент, который подключается к СУБД должен ли иметь какие-то специальные настройки (например, параметры строки подключения, использование каких-либо дополнительных драйверов и т.д.)? Или клиент вообще "не понимает", что работает с параллельной СУБД?

Отредактировано alex_spq (2018-04-22 20:10:46)