我正处于开发体育统计网站(终极飞盘)的早期阶段,如果Google App Engine适合我,我想知道您的意见。
我使用Django在Python中编写它并且已经习惯了标准的RDBMS多年,但这个站点是一个长期项目,我期待非常大量的数据,所以我希望GAE数据存储的“无限”缩放提供。绝大多数对数据库的查询都会返回非常标准的结果,这会使数据存储看起来像是一个合理的选择。但是,我希望将来能够提出极其复杂的查询来提出新的统计指标,或者只是想出有趣的结果。我计划将来做很多这样的事情,但在收集数据之前不会知道这些查询是什么。
例如,你经常看到棒球统计数据分析师提出荒谬的统计数据,例如“这是过去50年来第一次两个左手投手,其姓氏以'Z'开头,一举击中背靠背的日子“。我希望将来能够灵活地提出任何疑问。 :)
但是,我的印象是像bigtable这样的非关系型数据库要求您预先提供包含冗余数据的模型,并且所有工作都在插入而不是提取上进行。我已经构建了几乎包含我需要查询的所有数据的django模型,但是我不知道从现在开始我想要一年或两年的非规范化模型。因此,我觉得将来在GAE数据存储区中进行复杂的查询会非常困难,并且需要我在python中处理之前从服务器上提取大量信息。
谷歌应用引擎数据存储区是否完全错误,我想做什么?或者我只是缺少一些东西。非常感谢提前!
更新 感谢到目前为止的回复。我意识到我还应该提到很多这些复杂的查询是我希望用户能够做的查询,因此使得脱机数据库不是一个真正的选择。例如,用户应该能够看到各种特定玩家在特定游戏或季节期间同时在场上时的比赛的各种统计数据。虽然这些查询并不像标准聚合统计数据那样频繁,但它们仍然会定期发生。
拥有关系数据库以及GAE数据存储区会很棒,但django默认情况下不支持多个数据库,并且一起修补解决方案听起来很困难而且很混乱。 Eric Florenzano对两个使用django模型的数据库都有nice solution,但如果我使用GAE数据存储,我将不得不使用app引擎的db模型。并且提出一个像他为这个复杂问题所做的一个很好的解决方案,在这一点上有点超出我的技能水平。
现在我最喜欢的两个选项是使用GAE任务队列来执行困难的查询,或者使用像webfaction这样的更标准的webhost,然后在我的数据增长后再对我的表进行反规范化,我需要提高性能。
答案 0 :(得分:13)
您所描述的内容基本上是OLAP - 在线分析处理。 OLAP是“传统”RDBMS非常擅长的一件事,部分原因在于SQL的灵活性和强大功能 - 而非关系型数据库(如App Engine数据存储区则不然)。听起来,与正常访问相比,您的OLAP类型查询相对较少,因此我建议使用以下两种方法之一:
答案 1 :(得分:6)
我想说bigtable-type存储不太适合统计应用程序,因为你提到的原因。但这是你必须做出的经典权衡。我很少发现自己使用了非常复杂的查询的灵活性,但是很多时候都被迫为那些本来不应该在db中的东西提出更专业的解决方案。
如果你坚持使用RDBMS,你可以很容易地进行逻辑分区和非规范化,例如通过Hibernates持久性策略和Hibernate Shards。如果你可以忍受稍微慢一点的处理,你也可以对bigtable类型的存储进行SQL查询(参见例如hadoop pig latin)。
答案 2 :(得分:2)
GAE数据存储与RDBMS完全不同。在关系数据库中很容易写出类似的东西:
SELECT STDEV(player_score)
FROM Table
WHERE player_id = 1234
AND game_date BETWEEN '2007-01-01' AND '2009-11-10'
AND city <> 'London'
GAE查询有很多限制 - see here - 因此翻译它并不容易。对于聚合函数(sum,stdev等),您必须将所有数据提取到应用程序层,并计算或维护在每个数据插入/更新时更新的聚合实体。
<强>更新强>
您可以考虑将GAE用于UI和业务逻辑,但在云中的其他地方使用单独的关系数据库,如:Microsoft SQL,Amazon上的DB2,其他地方的MySQL - 以及使用GAE数据存储来预先计算聚合和统计信息。因此,统计数据仍在RDBMS中计算,但您将结果(部分预先计算的统计数据)存储在GAE存储中;类似于分析立方体中的维度存储。
答案 3 :(得分:0)
我想支持MindWire使用Google的CloudSQL。
我当前的项目实际上来自数据存储,主要是在Cloud SQL中执行更多面向SQL的任务。