Медленное ЛЕВОЕ СОЕДИНЕНИЕ на CTE с временными интервалами - PullRequest
Новая
       38

Медленное ЛЕВОЕ СОЕДИНЕНИЕ на CTE с временными интервалами

0 голосов
/ 07 мая 2018

Я пытаюсь отладить запрос в PostgreSQL, который я построил для хранения рыночных данных в временных интервалах в произвольных временных интервалах . Вот мое определение таблицы: 

CREATE TABLE historical_ohlcv (
  exchange_symbol TEXT                     NOT NULL,
  symbol_id       TEXT                     NOT NULL,
  kafka_key       TEXT                     NOT NULL,
  open            NUMERIC,
  high            NUMERIC,
  low             NUMERIC,
  close           NUMERIC,
  volume          NUMERIC,
  time_open       TIMESTAMP WITH TIME ZONE NOT NULL,
  time_close      TIMESTAMP WITH TIME ZONE,
  CONSTRAINT historical_ohlcv_pkey
  PRIMARY KEY (exchange_symbol, symbol_id, time_open)
);

CREATE INDEX symbol_id_idx
  ON historical_ohlcv (symbol_id);

CREATE INDEX open_close_symbol_id
  ON historical_ohlcv (time_open, time_close, exchange_symbol, symbol_id);

CREATE INDEX time_open_idx
  ON historical_ohlcv (time_open);

CREATE INDEX time_close_idx
  ON historical_ohlcv (time_close);

В настоящее время в таблице ~ 25 миллионов строк. Мой запрос в качестве примера на 1 час, но может быть 5 минут, 10 минут, 2 дня и т. Д. 

EXPLAIN ANALYZE WITH vals AS (
    SELECT
      NOW() - '5 months' :: INTERVAL AS frame_start,
      NOW() AS frame_end,
      INTERVAL '1 hour'        AS t_interval
)
  , grid AS (
      SELECT
        start_time,
        lead(start_time, 1)
        OVER (
          ORDER BY start_time ) AS end_time
      FROM (
             SELECT
               generate_series(frame_start, frame_end,
                               t_interval) AS start_time,
               frame_end
             FROM vals
           ) AS x
  )
SELECT max(high)
FROM grid g
  LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
WHERE exchange_symbol = 'BINANCE'
AND symbol_id = 'ETHBTC'
GROUP BY start_time;

Предложение WHERE может быть любым допустимым значением в таблице.

Эта техника была вдохновлена:

Идея состоит в том, чтобы создать общую таблицу и оставить ее вместе с данными, чтобы указать, в каком сегменте ведра она находится. Этот запрос действительно медленный! В настоящее время это занимает 15 секунд. Основываясь на планировщике запросов, у нас есть очень дорогой вложенный цикл: 

QUERY PLAN
HashAggregate  (cost=2758432.05..2758434.05 rows=200 width=40) (actual time=16023.713..16023.817 rows=542 loops=1)
  Group Key: g.start_time
  CTE vals
    ->  Result  (cost=0.00..0.02 rows=1 width=32) (actual time=0.005..0.005 rows=1 loops=1)
  CTE grid
    ->  WindowAgg  (cost=64.86..82.36 rows=1000 width=16) (actual time=2.986..9.594 rows=3625 loops=1)
          ->  Sort  (cost=64.86..67.36 rows=1000 width=8) (actual time=2.981..4.014 rows=3625 loops=1)
                Sort Key: x.start_time
                Sort Method: quicksort  Memory: 266kB
                ->  Subquery Scan on x  (cost=0.00..15.03 rows=1000 width=8) (actual time=0.014..1.991 rows=3625 loops=1)
                      ->  ProjectSet  (cost=0.00..5.03 rows=1000 width=16) (actual time=0.013..1.048 rows=3625 loops=1)
                            ->  CTE Scan on vals  (cost=0.00..0.02 rows=1 width=32) (actual time=0.008..0.009 rows=1 loops=1)
  ->  Nested Loop  (cost=0.56..2694021.34 rows=12865667 width=14) (actual time=7051.730..16015.873 rows=31978 loops=1)
        ->  CTE Scan on grid g  (cost=0.00..20.00 rows=1000 width=16) (actual time=2.988..11.635 rows=3625 loops=1)
        ->  Index Scan using historical_ohlcv_pkey on historical_ohlcv ohlcv  (cost=0.56..2565.34 rows=12866 width=22) (actual time=3.712..4.413 rows=9 loops=3625)
              Index Cond: ((exchange_symbol = 'BINANCE'::text) AND (symbol_id = 'ETHBTC'::text) AND (time_open >= g.start_time))
              Filter: (time_close < g.end_time)
              Rows Removed by Filter: 15502
Planning time: 0.568 ms
Execution time: 16023.979 ms

Полагаю, эта строка много делает: 

LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
                                AND ohlcv.time_close < g.end_time

Но я не уверен, как это сделать по-другому.

P.S. извиняюсь, если это принадлежит dba.SE. Я прочитал FAQ, и это показалось слишком простым для этого сайта, поэтому я разместил здесь.

Редактировать в соответствии с просьбой:

SELECT avg(pg_column_size(t)) FROM historical_ohlcv t TABLESAMPLE SYSTEM (0.1); возвращает 107,632

Для exchange_symbol есть 3 уникальных значения, для symbol_id ~ 400

Версия PostgreSQL: PostgreSQL 10.3 (Ubuntu 10.3-1.pgdg16.04 + 1) на x86_64-pc-linux-gnu, скомпилированный gcc (Ubuntu 5.4.0-6ubuntu1 ~ 16.04.9) 5.4.0 20160609, 64 -битовый.

Таблица будет расти примерно на 1 миллион записей в день, поэтому не только для чтения. Все это делается локально, и я постараюсь перейти на RDS или помочь решить проблемы с оборудованием.

Связанный: если бы я хотел добавить другие агрегаты, в частности «сначала в корзину», «последний в корзину», min, sum, моя стратегия индексации изменилась бы?

1 Ответ

0 голосов
/ 08 мая 2018

Сначала корректность : Я подозреваю ошибку в вашем запросе: 

 LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
                                 AND ohlcv.time_close < g.end_time

В отличие от моего ссылочного ответа , вы присоединяетесь за время интервал : (time_open, time_close]. То, как вы это делаете, исключает строки в таблице, где интервал пересекает границы сегмента. Только интервалы, полностью содержащиеся в одном сегменте. Я не думаю, что это задумано?

Простым решением будет определение членства в корзине на основе только time_open (или time_close). Если вы хотите продолжать работать с обоими, вы должны точно определить как работать с интервалами, перекрывающимися с несколькими сегментами.

Кроме того, вы ищете max(high) на ведро, которое отличается по природе от count(*) в моем ссылочном ответе.

А ваши ведра - это простые интервалы в час?

Тогда мы можем радикально упростить. Работаем только с time_open: 

SELECT date_trunc('hour', time_open) AS hour, max(high) AS max_high
FROM   historical_ohlcv
WHERE  exchange_symbol = 'BINANCE'
AND    symbol_id = 'ETHBTC'
AND    time_open >= now() - interval '5 months'  -- frame_start
AND    time_open <  now()                        -- frame_end
GROUP  BY 1
ORDER  BY 1;

Связанный:

Трудно говорить о дальнейшей оптимизации производительности, хотя основы неясны. И нам нужно больше информации.

Являются ли условия WHERE переменными?
Сколько различных значений в exchange_symbol и symbol_id?
Avg. размер строки? Что вы получаете за: 

SELECT avg(pg_column_size(t)) FROM historical_ohlcv t TABLESAMPLE SYSTEM (0.1);

Таблица доступна только для чтения?

Предполагая, что вы всегда фильтруете по exchange_symbol и symbol_id, а значения являются переменными, ваша таблица доступна только для чтения, или автоочистка может справиться с нагрузкой записи, поэтому мы можем надеяться на сканирование только по индексу, вам лучше иметь многоколонный индекс на (exchange_symbol, symbol_id, time_open, high DESC) для поддержки этого запроса. Индексируйте столбцы в этом порядке. Связанный:

В зависимости от распределения данных и других деталей, решение LEFT JOIN LATERAL может быть другим вариантом. Связанный:

Помимо всего этого, ваш EXPLAIN план демонстрирует некоторые очень плохие оценки :

Используете ли вы текущую версию Postgres? Возможно, вам придется поработать над конфигурацией вашего сервера - или, по крайней мере, установить более высокие цели статистики для соответствующих столбцов и более агрессивные настройки автоматического вакуума для большой таблицы. Связанный:

...