2

フラット化されたデータセットがあり、各行にはユーザー属性 (年齢、場所など)、登録および訪問日時が含まれています。1 日あたりのパーティション。1 日あたり最大 1,000 万行の訪問、2,500 万人のユーザー、毎日 500 万人のユーザー。これは現在、数か月のデータで機能しており、1 年間で約 30 億行以上になります。

効率とサイズの削減のために、ネストされた行に移動することを考えていました。各ユーザーは、登録と訪問の日時のみを含むネストされたレコードを持ちます。

大きな変更を行う前に、1 行あたり 64K の制限を超えないと仮定して、それに応じてクエリを変更します。これは、行を平坦化するよりも優れたパフォーマンスを発揮しますか?

問題：

  • ネストを使用すると、訪問日ごとに毎日のパーティションが失われます。これは、それらを 1 つのレコードにネストするためです。（月ごとに分割できますか？）

  • ロードするときは、CSV を JSON に変換し、各行をロードするパーティションを知る必要があるため、パーティション分割をキャンセルすると思います。

  • より少ないパーティションでのクエリのパフォーマンスは向上しますが、ネストされた方が優れているはずですか?

ありがとう

4

1 に答える 1

0

1: The actual import row size limit for json data is 20 MB, not 64k. I've filed a doc bug to get this updated in our public documentation.

  1. Nesting your data may improve performance somewhat, but without knowing the actual queries, it is difficult to know. It is unlikely to have a large effect on performance. It will, however, likely make your queries less expensive.

  2. You may be able to do a union of multiple partitions and then group by or a group each by to collect visits per user. It would probably be a good idea to try this out with a smaller sample of your data before productionizing it.

My guess is that the more complex queries and loading logic will mean that you won't see much benefit by nesting your data. You will likely be better off just keeping your data denormalized and flattened, partitioning the data by day, and querying over the union of tables that are needed in the query. We're working on ways to make it easier to specify ranges of tables in a query, which may be helpful.

于 2012-12-27T18:02:20.060 に答える