2

このドキュメントで読んでいることを理解するのを手伝ってもらえますか? https://crate.io/docs/reference/sql/partitioned_tables.html

これらの表の例では、列id longはprimary_key;ではありません。実際、idここでは主キーにすることはできません。なぜなら、以下に示すように、「主キーが設定されている場合は、PARTITION BY句に存在する必要がある」ためです。

私のアプリでは、歴史的にprimary keyonがありましid string NOT NULLたが、今は、例のように生成された日付列で、このテーブルにパーティショニングを追加したいと考えていますpartition_date timestamp GENERATED ALWAYS AS date_trunc('day', created_at)。日付列でのパーティショニングは、期間によって範囲を絞ったクエリの速度に役立ち (たとえば、今日のすべてのレコードをカウントすると、今日のパーティションにしかヒットしない)、データの古いフレーム (たとえば、180 日を超えるもの) をアーカイブするのに役立つことを読みました。 )、しかし、単一の PK ルックアップのパフォーマンスを低下させたくありません。

では、ただではできないので、私がPARTITIONED BY (partition_date)...

ida) ?から主キー制約を削除します。これが単一行のルックアップのパフォーマンスに影響を与えるのではないかと心配しています! このコンテキストでは、PK がパーティション キーに含まれている必要があることは理にかなっています。これは、ルックアップWHERE id = "abc-123"が理想的には 1 つのノードにヒットするだけでよいためです。

また

b) 両方の列を次のようにパーティション キーとして使用するPARTITIONED BY (id, partition_date)-- これは奇妙に思えます。本能的に、これはidカーディナリティが高く、パーティション列には不適切な選択であり、「日」または「月」の方が適切であると想定したいからです。あなたのドキュメントの例にそのようなものが示されています。この場合、私の PK ルックアップはすべてのパーティションにヒットしていますか、それともどこに行くべきかを正確に知っていますか? 今日のみを対象とした集計クエリを実行すると、すべてのパーティションにヒットするのでしょうか?それとも今日のデータを保持しているパーティションだけにヒットするのでしょうか?

4

1 に答える 1

1

それは素晴らしい質問です！パーティションは並べ替えの「サブテーブル」であるため、クエリされたデータのサイズを減らすのに役立ちます。

主キーは CrateDB のルーティングに影響を与えるため、分割されたテーブル (より広範なルーティングが必要) に追加すると、 partitioned by 句の非主キー列が拒否されます。したがって、オプションは次のとおりです。

  • a) これにより PK ルックアップを効果的に実行する機能が削除されますが、これは賢明なオプションのように思えます -フルテキスト インデックスを使用することで通常の文字列ルックアップを高速化できますが、読み取り後書き込みの一貫性のある主キーも削除されます。ルックアップが追加されます。主キーを生成する方法によっては、_id代わりに内部列を (ルックアップ用に) 使用したりREFRESH TABLE、id-lookup の前に a を発行したりできる場合があります。
  • b）主キーと同じ数のパーティションが作成されます（そしてそれらは一意であるため...）-したがって、このオプションはあまりにも多くのパーティションを作成します

オプション b) は混乱を招くため、オプション a) をお勧めします。ただし、主キーのルックアップがアプリケーションにとって重要であり、予想されるデータ量がそれほど大きくない場合 (クラスターのサイズとマシンの仕様によっては、数百万でも問題ありません)、パーティショニングを行わなくても問題なく動作する可能性があります。

乾杯、クラウス

于 2017-01-12T18:18:47.003 に答える