「Google IO 2009: Building scaling, complex apps on App Engine」を見た後、リストのデシリアライゼーションへの影響を理解するためにいくつかのテストを実行しましたが、結果は非常に驚くべきものでした。以下はテストの説明です。
- すべてのテストは GAE サーバー上で実行されます。
- 各テストは 5 回実行され、その時間と CPU 使用率が記録されます。
- このテストは、Columns VS List でのデータのフェッチ (フロート) の速度を比較することです。
- 列テーブルとリスト テーブルの両方に、クエリ用の追加の日時列が含まれています。
- 同じクエリを使用して、列テーブルとリスト テーブルの両方でデータをフェッチします。
テスト 1
- 単一行のフェッチ
- テーブル サイズ: 500 列 vs 500 のリスト (両方とも 500 行を含む)
Table:ChartTestDbRdFt500C500R <-- 500 列 x 500 行
OneRowCol 結果 <-- 1 行を取得中
[0] 0.02 (52) <-- テスト 0、所要時間 = 0.02、CPU 使用率 = 52
[1] 0.02 (60)
[2 ] 0.02 (56)
[3] 0.01 (46)
[4] 0.02 (57)
Table:ChartTestDbRdFt500L500R <-- 500 x 500 行の
リスト OneRowLst 結果
[0] 0.01 (40)
[1] 0.02 (38)
[2] 0.01 (42)
[3] 0.05 (154)
[4] 0.01 (41)
テスト 2
- すべての行をフェッチ
- テーブル サイズ: 500 列 vs 500 のリスト (両方とも 500 行を含む)
表:ChartTestDbRdFt500C500R
AllRowCol 結果
[0] 11.54 (32753)
[1] 10.99 (31140)
[2] 11.07 (31245)
[3] 11.55 (37177)
[4] 10.96 (34300)
表:ChartTestDbRdFt500L500R
AllRowLst 結果
[0] 7.46 (20872)
[1] 7.02 (19632)
[2] 6.8 (18967)
[3] 6.33 (17709)
[4] 6.81 (19006)
テスト 3
- 単一行のフェッチ
- テーブル サイズ: 4500 列 vs 4500 のリスト (どちらも 10 行を含む)
表:ChartTestDbRdFt4500C10R
OneRowCol 結果
[0] 0.15 (419)
[1] 0.15 (433)
[2] 0.15 (415)
[3] 0.23 (619)
[4] 0.14 (415)
表:ChartTestDbRdFt4500L10R
OneRowLst 結果
[0] 0.08 (212)
[1] 0.16 (476)
[2] 0.07 (215)
[3] 0.09 (242)
[4] 0.08 (217)
結論
N項目のリストを取得するのは、実際にはN列よりも高速です。なぜこれが事実なのか誰にも分かりますか？リストのデシリアライゼーションでパフォーマンスに影響があると思いましたか? または、テストを間違って実行しましたか? どんな洞察も役に立ちます、ありがとう！