Получу ли я преимущества гипер-таблицы, если у меня есть запрос, в котором я присоединяюсь к гипер-таблице с нормальной (не гипер) таблицей в timescaledb

Question

Мне нужно выбрать запись из двух таблиц, одна таблица является гипер-таблицей, другая таблица является обычной таблицей.

Первичный ключ гипер-таблицы (UUID, а не столбец timestampz) используется в качестве внешнего ключа в 2-ая ​​нормальная таблица.

Гипер-таблица имеет отношение один-ко-многим с обычной таблицей.

Получу ли я все преимущества гиперт таблицы, если я выберу запись после присоединения к этой таблице?

Я использую postgresql базу данных для шкалы времени.

Ниже приведены запросы к таблицам. Демография_персонал - это гипертабильная таблица, а эмоции_персонал - это обычная таблица

CREATE TABLE public.demography_person
(
  start_timestamp timestamp with time zone NOT NULL,
  end_timestamp timestamp with time zone,
  demography_person_id character varying NOT NULL,
  device_id bigint,
  age_actual numeric,
  age_band integer,
  gender integer,
  dwell_time_in_millis bigint,
  customer_id bigint NOT NULL
);

SELECT create_hypertable('demography_person', 'start_timestamp');

CREATE TABLE public.emotions_person
(
  emotion_start_timestamp timestamp with time zone NOT NULL,
  demography_person_id character varying NOT NULL,
  count integer,
  emotion integer,
  emotion_percentage numeric
);

select sql Запрос выглядит так: -

SELECT * FROM crosstab
             (
               $$
                   SELECT * FROM  ( select  to_char(dur,'HH24') as duration , dur as time_for_sorting from 
                generate_series(
            timestamp '2019-04-01 00:00:00',
            timestamp '2020-03-09 23:59:59' ,
            interval  '1 hour'
                ) as dur   ) d
                   LEFT JOIN (  
                   select to_char(
                                    start_timestamp ,
                                   'HH24'
                                   )
                   as duration,
                   emotion,count(*) as count from demography_person dp INNER JOIN (
            select  distinct ON (demography_person_id)  demography_person_id, emotion_start_timestamp,count,emotion,emotion_percentage,
            (CASE emotion when 4 THEN 1 when 6  THEN 2 when 1 THEN 3  WHEN 3 THEN 4 WHEN 2 THEN 5  when 7 THEN 6  when 5 THEN 7  ELSE 8 END )  
             as emotion_key_for_sorting from emotions_person  where    demography_person_id in (select demography_person_id from demography_person where start_timestamp >= '2019-04-01 00:00:00'
            AND start_timestamp <= '2020-03-09 23:59:59' AND device_id IN ( 2052,2692,1797,2695,1928,2697,2698,1931,2574,2575,2706,1942,1944,2713,1821,2719,2720,2721,2722,2723,2596,2725,2217,2603,1852,2750,1726,1727,2754,2757,1990,2759,2760,2376,2761,2762,2257,2777,2394,2651,2652,1761,2658,1762,2659,2788,2022,2791,2666,1770,2026,2028,2797,2675,1780,2549 ))   
               order by demography_person_id asc,emotion_percentage desc, emotion_key_for_sorting asc 
                   ) ep ON
                   ep.demography_person_id = dp.demography_person_id
                   WHERE start_timestamp >= '2019-04-01 00:00:00'
AND start_timestamp <= '2020-03-09 23:59:59' AND device_id IN ( 2052,2692,1797,2695,1928,2697,2698,1931,2574,2575,2706,1942,1944,2713,1821,2719,2720,2721,2722,2723,2596,2725,2217,2603,1852,2750,1726,1727,2754,2757,1990,2759,2760,2376,2761,2762,2257,2777,2394,2651,2652,1761,2658,1762,2659,2788,2022,2791,2666,1770,2026,2028,2797,2675,1780,2549 ) AND gender IN ( 1,2 )
                   group by 1,2 ORDER  BY 1,2 ASC
                   ) t USING (duration) GROUP  BY 1,2,3,4 ORDER  BY time_for_sorting;           
               $$ ,
               $$
                 select emotion from (
                                                          values ('1'), ('2'), ('3'),('4'), ('5'), ('6'),('7'), ('8')
                                                    ) t(emotion)
              $$ 
         ) AS ct 
              (
                   duration text,
                   time_for_sorting  timestamp,
                  ANGER bigInt,
                  DISGUSTING bigInt,
                  FEAR bigInt,
                  HAPPY bigInt,
                  NEUTRAL bigInt,
                  SAD bigInt,
                  SURPRISE bigInt,
                  NO_DETECTION bigInt
             ); 

Answer 1

Получу ли я преимущества гипер-таблицы, если у меня есть запрос, в котором я присоединяюсь к гипер-таблице с обычной (не гипер) таблицей в timescaledb

Не полностью понять вопрос и посмотреть на него две интерпретации:

1. Получу ли я пользу от использования TimescaleDB и hypertable только для улучшения этого запроса?
2. Можно ли объединить гипертабильную и обычную таблицу и как чтобы сделать вышеупомянутый запрос, чтобы выполнить лучше?

Если вам просто нужно выполнить сложный запрос по большому набору данных, PostgreSQL может хорошо работать, если вы предоставляете индексы. TimescaleDB предоставляет преимущества для рабочих процессов временных рядов , особенно когда рабочий процесс включает в себя прием данных по порядку, связанные со временем запросы, операторы временных рядов и / или использование таких функций TimescaleDB c, как непрерывные агрегаты и сжатие , т. е. не просто запрос. TimescaleDB предназначен для больших объемов данных временных рядов. Я надеюсь, что это проясняет первый вопрос.

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

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

Я вижу, что запрос генерирует данные, и я сомневаюсь, что можно сделать многое для создания хорошего плана запроса. Так что это моя самая большая забота о получении хорошей производительности. Было бы здорово, если бы вы могли объяснить мотивацию вокруг генерирования данных внутри запроса.

Еще одна проблема, которую я вижу, - это вложенный запрос demography_person_id in (select demography_person_id from demography_person ... в условии where. И внешний запрос является частью внутреннего соединения с той же таблицей, что и во вложенном запросе. Я ожидаю, что он может быть переписан без вложенного подзапроса с использованием внутреннего соединения.

Я сомневаюсь, что TimescaleDB или PostgreSQL могут многое сделать для эффективного выполнения запроса. Запрос требует ручного переписывания человеком.