Типичные специальные аналитические запросы должны обрабатывать гораздо больше данных, чем может поместиться в памяти. Следовательно, эти запросы, как правило, связаны с вводом / выводом. Когда в Couchbase 6.0 была представлена служба аналитики, она позволяла пользователям указывать несколько «путей к дискам аналитики» во время инициализации узла. В этой статье мы выполним пару экспериментов на разных экземплярах в облаке, чтобы показать, как правильно настроить несколько «путей к дискам Google Analytics» и как эту функцию можно использовать для ускорения запросов Google Analytics.
Рисунок 1: Указание путей к дискам Analytics во время инициализации узла
Во время инициализации узла любой уникальный путь к файловой системе может использоваться как «Путь к диску Analytics» независимо от фактического физического устройства хранения, в котором находится этот путь. Можно использовать несколько путей, которые находятся на одном устройстве. Данные в службе Google Analytics распределяются по всем указанным «путям к дискам Google Analytics» во всех узлах, на которых есть служба Google Analytics. Например, если в кластере есть два узла со службой Google Analytics, и на одном из узлов было указано 4 «Пути диска Analytics», а на другом узле было 8 «Пути диска Analytics», каждый созданный набор данных в Analytics будет иметь в общей сложности 12 разделов. (разделы данных).
Во время выполнения запроса механизм запросов MPP Analytics пытается одновременно считывать и обрабатывать данные из всех разделов данных. Поэтому операции ввода-вывода в секунду (IOPS) реального физического диска, на котором находится каждый раздел данных, играют основную роль в определении времени выполнения запроса.
Вам также может понравиться: Распределенные транзакции ACID с несколькими документами в Couchbase
Современные устройства хранения, такие как твердотельные накопители, имеют гораздо более высокие IOPS и могут лучше справляться с одновременным чтением по сравнению с жесткими дисками. Следовательно, наличие одного раздела данных на устройствах с высоким IOPS не будет полностью использовать их возможности. Чтобы упростить настройку типичного случая узла, имеющего одно современное устройство хранения, служба Google Analytics автоматически создает несколько разделов данных в одном и том же устройстве хранения, если и только если во время инициализации узла указан один «путь диска Analytics». Количество автоматически созданных разделов данных основано на этой формуле:
Простой текст
1
Maximum partitions to create = Min((Analytics Memory in MB / 1024), 16)
2
Actual created partitions = Min(node virtual cores, Maximum partitions to create)
Например, если узел имеет 8 виртуальных ядер и служба Google Analytics настроена с объемом памяти> = 8 ГБ, на этом узле будет создано 8 разделов данных. Точно так же, если узел имеет 32 виртуальных ядра и был сконфигурирован с памятью> = 16 ГБ, будет создано только 16 разделов, так как максимальное количество автоматически создаваемых разделов имеет верхний предел 16 разделов.
Чтобы продемонстрировать влияние производительности на количество разделов данных на диск, мы провели несколько экспериментов на разных типах экземпляров в Amazon Web Services EC2 с использованием Couchbase Server 6.5 . Данные, использованные в экспериментах, представляют собой версию JSONified известного набора данных, где каждая строка была преобразована в документ JSON с дополнительным полем, которое идентифицирует имя таблицы, к которой принадлежит документ. Образцы данных TPC-DS были сгенерированы и загружены в корзину с именем tpcds. В обоих экспериментах службе аналитики было выделено 32 ГБ памяти.
Эксперимент 1: один экземпляр с 8 виртуальными ядрами и 1 NVMe SSD
В этом эксперименте мы создали 3 набора данных в сервисе Google Analytics следующим образом:
SQL
x
1
/* Couchbase N1QL statements */
2
CREATE DATASET store_sales ON tpcds WHERE table_name='store_sales';
4
CREATE DATASET date_dim ON tpcds WHERE table_name='date_dim';
5
CREATE DATASET item ON tpcds WHERE table_name='item';
Мы использовали следующий квалификационный запрос TPC-DS после преобразования его в запрос N1QL for Analytics, чтобы измерить время ответа в двух разных конфигурациях:
SQL
xxxxxxxxxx
1
/* Couchbase N1QL query */
2
SELECT dt.d_year,
4
item.i_brand_id brand_id,
5
item.i_brand brand,
6
sum(ss.ss_ext_sales_price) sum_agg
7
FROM date_dim dt,
8
store_sales ss,
9
item
10
WHERE dt.d_date_sk = ss.ss_sold_date_sk
11
AND ss.ss_item_sk = item.i_item_sk
12
AND item.i_manufact_id = 128
13
AND dt.d_moy=11
14
GROUP BY dt.d_year,
15
item.i_brand,
16
item.i_brand_id
17
ORDER BY dt.d_year,
18
sum_agg DESC,
19
brand_id
20
LIMIT 100;
Для первой конфигурации мы указали два «Пути диска Google Analytics» на одном диске, в результате чего каждый набор данных имел 2 раздела данных. Что касается второй конфигурации, был задан только один «путь данных Google Analytics», который активировал опцию автоматической настройки. Поскольку узел имеет 8 виртуальных ядер, 8 разделов данных были созданы автоматически. На рисунке 2 ниже показано среднее время ответа на запрос для этих двух конфигураций.
Что касается среднего времени ответа на запрос, автоматическая конфигурация с 8 разделами была более чем в два раза быстрее, чем конфигурация только с 2 разделами данных. Это улучшение было вызвано лучшим использованием одного SSM-диска NVMe, поскольку этот тип диска может обрабатывать 8 одновременных операций чтения. Кроме того, поскольку этот запрос включает в себя группирование и сортировку, обработка данных одновременно на 8 разделах привела к значительному улучшению производительности запроса.
Рисунок 2: Среднее время ответа на запрос в эксперименте 1
Эксперимент 2: один экземпляр с 8 виртуальными ядрами и 6 жесткими дисками
В этом эксперименте мы попытаемся отсканировать больший объем данных, создав единый набор данных, содержащий все данные в корзине tpcds, следующим образом:
SQL
xxxxxxxxxx
1
/* Couchbase N1QL statement */
2
CREATE DATASET tpcds on tpcds;
Мы использовали следующий запрос N1QL для аналитики, который приводит к сканированию всех данных с использованием двух разных конфигураций:
SQL
x
1
/* Couchbase N1QL query */
2
SELECT SUM(ss_ext_sales_price)
4
FROM tpcds
5
WHERE table_name = "store_sales";
Для первой конфигурации был указан один «Пути данных Google Analytics»; в результате система автоматически создала 8 разделов на жестком диске. Во второй конфигурации было указано 6 «путей данных аналитики», и каждый путь располагался на отдельном физическом жестком диске, в результате чего было 6 разделов данных. На рисунке 3 ниже показано среднее время ответа на запрос для двух конфигураций. В первой конфигурации выполнение 8 одновременных операций чтения на одном жестком диске привело к снижению производительности.
Основной причиной этого является то, что он оставил полосу пропускания ввода / вывода других 5 жестких дисков неиспользованной. Кроме того, 8-сторонний параллелизм по отношению к одному жесткому диску привел к большему перемещению плеча диска, увеличив среднюю стоимость дискового ввода-вывода. Вторая конфигурация, в которой одновременно использовались все 6 жестких дисков, в результате увеличила производительность более чем в 7 раз.
Рисунок 3: Среднее время ответа на запрос в эксперименте 2
Заключение
Механизм аналитики - это полноценный процессор параллельных запросов, который поддерживает параллельные объединения, агрегации и сортировку - на основе «лучших в своем роде» алгоритмов, взятых из более чем 30-летних исследований и разработок MPP, но для данных JSON. Используя два эксперимента, мы показали значительное влияние на производительность, которое может быть вызвано различными вариантами, которые были сделаны при настройке «Пути диска Google Analytics». Мы также продемонстрировали, как механизм Analytics может использовать несколько физических дисков, если они доступны, для значительного ускорения запросов Analytics.