Почему Query_parallelism влияет на результат соединения двух столбцов UUID

avatar
C.Vergnaud
1 июля 2021 в 16:49
55
2
0

Я запускаю следующий тест на ignite 2.10.0

У меня есть 2 таблицы, созданные с параметром query_parallelism=1 и без ключа сходства. Когда я присоединяюсь к двум следующим таблицам, я получаю ожидаемый результат.

0: jdbc:ignite:thin://localhost:10800> SELECT "id" AS "_A_id", "source_id" AS "_A_source_id" FROM PUBLIC."source_ml_blue";
+--------------------------------------+--------------------------------------+
|                _A_id                 |             _A_source_id             |
+--------------------------------------+--------------------------------------+
| 86c068cd-da89-11eb-a185-3da86c6c6bb3 | 86c068cc-da89-11eb-a185-3da86c6c6bb3 |
+--------------------------------------+--------------------------------------+
1 row selected (0.004 seconds)
0: jdbc:ignite:thin://localhost:10800> SELECT "id" AS "_B_id", "flx_src_ip_text" AS "_B_src_ip" FROM PUBLIC."source_nprobe_tcp_blue";
+--------------------------------------+-----------+
|                _B_id                 | _B_src_ip |
+--------------------------------------+-----------+
| 86c068cc-da89-11eb-a185-3da86c6c6bb3 | 1.1.1.1   |
+--------------------------------------+-----------+
1 row selected (0.003 seconds)
0: jdbc:ignite:thin://localhost:10800> SELECT _A."id" AS "_A_id", _A."source_id" AS "_A_source_id", _B."id"  AS "_B_id", _B."flx_src_ip_text" AS "_B_src_ip" FROM PUBLIC."source_ml_blue" AS "_A" INNER JOIN  PUBLIC."source_nprobe_tcp_blue" AS "_B" ON "_A"."source_id"="_B"."id";
+--------------------------------------+--------------------------------------+--------------------------------------+-----------+
|                _A_id                 |             _A_source_id             |                _B_id                 | _B_src_ip |
+--------------------------------------+--------------------------------------+--------------------------------------+-----------+
| 86c068cd-da89-11eb-a185-3da86c6c6bb3 | 86c068cc-da89-11eb-a185-3da86c6c6bb3 | 86c068cc-da89-11eb-a185-3da86c6c6bb3 | 1.1.1.1   |
+--------------------------------------+--------------------------------------+--------------------------------------+-----------+
1 row selected (0.005 seconds)

Если я удалю и создам те же таблицы с query_parallelism = 8, у меня не будет ошибки SQL (параллелизм будет одинаковым для 2 таблиц), НО результат объединения будет пустым.

есть идеи, почему у меня такое поведение?

Источник
Alex K
2 июля 2021 в 22:31
1

Я не получаю те же результаты с CREATE TABLE table1 ( id int PRIMARY KEY, x int, ) WITH «template = cacheTemplate». То же самое для table2 и соединения: SELECT * FROM table1 a INNER JOIN table2 b ON a.ID = b .ID Здесь CacheTemplate определен с QueryParallelism из 8. Опубликуйте все свои определения таблицы/кэша, и я посмотрю.

C.Vergnaud
5 июля 2021 в 12:59
0

использование int не проблема, попробуйте использовать uuid.

Ответы (2)

avatar
C.Vergnaud
5 июля 2021 в 14:11
0

Проблема связана с клиентом SQL: он должен учитывать параллелизм.

В DBeaver мне пришлось включить ignite.jdbc.distributedJoins в свойствах подключения, чтобы запрос работал правильно.

avatar
Vladimir Pligin
5 июля 2021 в 15:02
1

Такое поведение наблюдается из-за оптимизации параллельного выполнения запросов. Скорее всего, ваши записи попали в разные разделы (обрабатываются другим потоком). Если вы увеличите количество записей в обеих таблицах, в результате вы увидите подмножество этого соединения. Наиболее элегантным вариантом здесь является использование "_A"."source_id" и "_B"."id" в качестве родственных ключей. Скорее всего, ignite.jdbc.distributedJoins повлияет на производительность кластерной установки. При совместном размещении элементы с совпадающими "_A"."source_id" и "_B"."id" будут находиться в одном разделе, чтобы избежать взаимодействия между разделами (для кластерных сред это приведет к дополнительным сетевым переходам).

C.Vergnaud
5 июля 2021 в 15:55
0

Тест проводился на кластере с одним узлом. Без параметра DistributedJoins DBeaver не может получить все данные.

Vladimir Pligin
5 июля 2021 в 16:05
0

Вы имеете в виду, что близость не помогает? Логично, что без сходства это не работает, поскольку ключи распределяются и обрабатываются для каждого раздела отдельно.

C.Vergnaud
6 июля 2021 в 08:32
0

Тест был проведен без аффинити-ключа специально, я добавлю эту информацию в вопрос.