0

私は現在、データ追跡システムに取り組んでいます。このシステムは、Python で記述されたマルチプロセス アプリケーションであり、次のように動作します。

  1. S 秒ごとに、データベース (現在は Postgres) から N 個の最も適切なタスクを選択し、そのデータを見つけます。
  2. タスクがない場合は、N 個の新しいタスクを作成し、(1) に戻ります。

問題は次のとおりです-現在、私は約持っています。80 GB のデータと 36M のタスク、およびタスク テーブルへのクエリの動作がますます遅くなり始めます (これは、最もデータが取り込まれ、最も頻繁に使用されるテーブルです)。

パフォーマンスの主なボトルネックは、タスク追跡クエリです。

LOCK TABLE task IN ACCESS EXCLUSIVE MODE;
SELECT * FROM task WHERE line = 1 AND action = ANY(ARRAY['Find', 'Get']) AND (stat IN ('', 'CR1') OR stat = 'ERROR' AND (actiondate <= NOW() OR actiondate IS NULL)) ORDER BY taskid, actiondate, action DESC, idtype, date ASC LIMIT 36;

                                    Table "public.task"
   Column   |            Type             |                    Modifiers
------------+-----------------------------+-------------------------------------------------
 number     | character varying(16)       | not null
 date       | timestamp without time zone | default now()
 stat       | character varying(16)       | not null default ''::character varying
 idtype     | character varying(16)       | not null default 'container'::character varying
 uri        | character varying(1024)     |
 action     | character varying(16)       | not null default 'Find'::character varying
 reason     | character varying(4096)     | not null default ''::character varying
 rev        | integer                     | not null default 0
 actiondate | timestamp without time zone |
 modifydate | timestamp without time zone |
 line       | integer                     |
 datasource | character varying(512)      |
 taskid     | character varying(32)       |
 found      | integer                     | not null default 0
Indexes:
    "task_pkey" PRIMARY KEY, btree (idtype, number)
    "action_index" btree (action)
    "actiondate_index" btree (actiondate)
    "date_index" btree (date)
    "line_index" btree (line)
    "modifydate_index" btree (modifydate)
    "stat_index" btree (stat)
    "taskid_index" btree (taskid)

                               QUERY PLAN                          
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=312638.87..312638.96 rows=36 width=668) (actual time=1838.193..1838.197 rows=36 loops=1)
   ->  Sort  (cost=312638.87..313149.54 rows=204267 width=668) (actual time=1838.192..1838.194 rows=36 loops=1)
         Sort Key: taskid, actiondate, action, idtype, date
         Sort Method: top-N heapsort  Memory: 43kB
         ->  Bitmap Heap Scan on task  (cost=107497.61..306337.31 rows=204267 width=668) (actual time=1013.491..1343.751 rows=914586 loops=1)
               Recheck Cond: ((((stat)::text = ANY ('{"",CR1}'::text[])) OR ((stat)::text = 'ERROR'::text)) AND (line = 1))
               Filter: (((action)::text = ANY ('{Find,Get}'::text[])) AND (((stat)::text = ANY ('{"",CR1}'::text[])) OR (((stat)::text = 'ERROR'::text) AND ((actiondate <= now()) OR (actiondate IS NULL)))))
               Rows Removed by Filter: 133
               Heap Blocks: exact=76064
               ->  BitmapAnd  (cost=107497.61..107497.61 rows=237348 width=0) (actual time=999.457..999.457 rows=0 loops=1)
                     ->  BitmapOr  (cost=9949.15..9949.15 rows=964044 width=0) (actual time=121.936..121.936 rows=0 loops=1)
                           ->  Bitmap Index Scan on stat_index  (cost=0.00..9449.46 rows=925379 width=0) (actual time=117.791..117.791 rows=920900 loops=1)
                                 Index Cond: ((stat)::text = ANY ('{"",CR1}'::text[]))
                           ->  Bitmap Index Scan on stat_index  (cost=0.00..397.55 rows=38665 width=0) (actual time=4.144..4.144 rows=30262 loops=1)
                                 Index Cond: ((stat)::text = 'ERROR'::text)
                     ->  Bitmap Index Scan on line_index  (cost=0.00..97497.14 rows=9519277 width=0) (actual time=853.033..853.033 rows=9605462 loops=1)
                           Index Cond: (line = 1)
 Planning time: 0.284 ms
 Execution time: 1838.882 ms
(19 rows)

もちろん、関連するすべてのフィールドにインデックスが付けられます。現在、次の 2 つの方向性を考えています。

  1. クエリを最適化する方法と、実際にパースペクティブのパフォーマンスが向上するかどうか (現在、動的タスク追跡では受け入れられないクエリごとに約 10 秒かかります)
  2. タスク データをどこに、どのように格納するのがより効果的でしょうか? そのような目的のために別の DB (Cassandra、VoltDB、または別のビッグ データ ストア) を使用する必要がありますか?

実際のタスクをできるだけ早く取得するには、データを何らかの方法で事前に並べ替える必要があると思います。

また、私の現在の 80G のボリュームは、そのようなタスクの最大ではなく最小である可能性が高いことに注意してください.

前もって感謝します！

4

1 に答える 1

0

あなたのユースケースはよくわかりませんが、インデックスがうまく機能しているようには見えません。クエリは主に統計インデックスに依存しているようです。（アクション、ライン、統計）のような複合インデックスを調べる必要があると思います。

別のオプションは、カーディナリティの低いいくつかのキーでデータを分割して、複数のテーブルにまたがってデータを分割することです。私はpostgresを使用していませんが、最適化の対象を正確に把握していない限り、別のdbソリューションを検討してもうまくいくとは思いません。

于 2016-06-11T02:28:02.550 に答える