GAE 数据存储性能（列与列表属性）
观看“Google IO 2009：在 App Engine 上构建可扩展的复杂应用”后，我执行了一些操作测试有助于了解对列表反序列化的影响，但结果相当令人惊讶。以下是测试说明。
- 所有测试均在 GAE 服务器上运行。
- 每个测试执行 5 次，并记录其时间和 CPU 使用率。
- 此测试是比较列与列表中获取（浮动）数据的速度。
- 列表和列表表都包含一个额外的日期时间列用于查询。
- 使用相同的查询来获取列表和列表上的数据。
测试1
- 获取单行
- 表大小：500 列与 500 列列表（均包含 500 行）
表：ChartTestDbRdFt500C500R <-- 500 列 x 500 行
OneRowCol 结果 <-- 获取一行
[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)
表：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 列与 500 列列表（均包含 500 行）
表：ChartTestDbRdFt500C500R
所有行列结果
[0] 11.54 (32753)
[1] 10.99 (31140)
[2] 11.07 (31245)
[3]11.55（37177）
[4] 10.96 (34300)
表：ChartTestDbRdFt500L500R
所有行列表结果
[0]7.46（20872）
[1]7.02（19632）
[2]6.8（18967）
[3]6.33（17709）
[4] 6.81 (19006)
测试 3
- 获取单行
- 表大小：4500 列与 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 列要快。有谁知道为什么会这样？我认为列表反序列化会影响性能？或者我的测试执行不正确？任何见解都会有所帮助，谢谢！
After watching "Google IO 2009: Building scalable, complex apps on App Engine" I performed some tests to help understand the impact on list de-serialization, but the results are quite surprising. Below are the test descriptions.
- All tests are run on GAE server.
- Each test is performed 5 times with its time and CPU usage recorded.
- This test is to compare the speed of fetching (float) data in Columns V.S List
- Both Column and List tables contain an extra datetime column for query.
- Same query is used to fetch data on both Column and List tables.
TEST 1
- Fetch Single Row
- Table size: 500 Columns vs List of 500 (both contain 500 rows)
Table:ChartTestDbRdFt500C500R <-- 500 Columns x 500 Rows
OneRowCol Result <-- Fetching one row
[0] 0.02 (52) <-- Test 0, time taken = 0.02, CPU usage = 52
[1] 0.02 (60)
[2] 0.02 (56)
[3] 0.01 (46)
[4] 0.02 (57)
Table:ChartTestDbRdFt500L500R <-- List of 500 x 500 Rows
OneRowLst Result
[0] 0.01 (40)
[1] 0.02 (38)
[2] 0.01 (42)
[3] 0.05 (154)
[4] 0.01 (41)
TEST 2
- Fetch All Rows
- Table size: 500 Columns vs List of 500 (both contain 500 rows)
Table:ChartTestDbRdFt500C500R
AllRowCol Result
[0] 11.54 (32753)
[1] 10.99 (31140)
[2] 11.07 (31245)
[3] 11.55 (37177)
[4] 10.96 (34300)
Table:ChartTestDbRdFt500L500R
AllRowLst Result
[0] 7.46 (20872)
[1] 7.02 (19632)
[2] 6.8 (18967)
[3] 6.33 (17709)
[4] 6.81 (19006)
TEST 3
- Fetch Single Row
- Table size: 4500 Columns vs List of 4500 (both contain 10 rows)
Table:ChartTestDbRdFt4500C10R
OneRowCol Result
[0] 0.15 (419)
[1] 0.15 (433)
[2] 0.15 (415)
[3] 0.23 (619)
[4] 0.14 (415)
Table:ChartTestDbRdFt4500L10R
OneRowLst Result
[0] 0.08 (212)
[1] 0.16 (476)
[2] 0.07 (215)
[3] 0.09 (242)
[4] 0.08 (217)
CONCLUSION
Fetching a list of N items is actually quicker than N columns. Does anyone know why this is the case? I thought there is a performance hit on list de-serialization? Or did I performed my tests incorrectly? Any insight will be helpful, thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
BigTable 是一个面向列的数据库。
这意味着获取 N 列的“行”实际上是 N 个不同的读取操作，所有操作都在同一个索引上。
BigTable is a column-oriented database.
That means that fetching a 'row' of N columns is in fact N different read operations, all on the same index.