做了一个GAE的应用, 在使用Datastore时碰到很多问题. Datastore有很多限制, 和以前使用的关系型数据库不同. 自己总结了一下, 以免以后自己忘记了. :-)
本文不是介绍怎么使用Google App Engine Datastore API.
任何查询都只能返回Entity, 所以必须Select * From SomeEntity. 不能只返回某些字段
GQL.fetch()可以带limit和offset参数, 返回从指定位置开始的指定条数记录. 但是, 其实datastore返回了offset+limit条记录, 只是在fetch方法中跳过offset条记录, 只返回最后limit条记录; 这一点不像通常的RMDB. 分页时我们经常会用到类似功能, 因此使用fetch(limit, offset)的话效率会是问题.
GQL.fetch()最多只返回1000条记录, 不管你把limit值设多大. 应该是出于性能的考虑
痛苦的Count, 在Groups里面被说的最多的Count: 不象在RMDB里面, count()方法其实是把所有符合条件的记录都读出来再算, 因此性能是个大问题. 出于性能考虑Google文档不建议你多使用count, 不建议在可能数据量很大的查询上用count().
count()最多也只能返回1000. 原因同fetch().
关于count(), Group里面讨论了很多解决方法. 一般是建议你自己实现count(): 在数据库中创建几个计数器, 创建新entity时随机拿出一个计数器加一. 把几个计数器的值相加, 就是最终的count值;
事务中所有的entity必须在一个entity group中, 事务中不能有select 查询
非等式过滤条件只能在一个属性(或字段)上. 以下查询就不可以
SELECT * FROM Person WHERE birth_year >= :min_year
AND height >= :min_height
你只能对birth_year属性用不等式
SELECT * FROM Person WHERE birth_year >= :min
AND birth_year <= :max
如果查询中有不等式,并且有Order By, 不等式查询的字段必须第一个被order by; 以下这两个查询都是错误的:
SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY last_name, birth_year"
SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY last_name
这个才行: SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY birth_year, last_name
看到这么多限制, 是不是觉得很奇怪. Google就拿这么个东西出来现眼吗? Google的解释是这是为了datastore的伸缩性(Scalability). 我的猜测是每个创建的entity会被随机的保存在成百上千的servers中的某个server node上, 使得数据库中aggregation计算代价非常高, 所以更多的计算会被推到app层. 同样的, 事务中所有的entity必须在一个entity group中也是要保证事务中的entity在一个node(或cluster)上. 这仅仅是我的猜想. 有谁知道得更多请留言;
本文不是介绍怎么使用Google App Engine Datastore API.
任何查询都只能返回Entity, 所以必须Select * From SomeEntity. 不能只返回某些字段
GQL.fetch()可以带limit和offset参数, 返回从指定位置开始的指定条数记录. 但是, 其实datastore返回了offset+limit条记录, 只是在fetch方法中跳过offset条记录, 只返回最后limit条记录; 这一点不像通常的RMDB. 分页时我们经常会用到类似功能, 因此使用fetch(limit, offset)的话效率会是问题.
GQL.fetch()最多只返回1000条记录, 不管你把limit值设多大. 应该是出于性能的考虑
痛苦的Count, 在Groups里面被说的最多的Count: 不象在RMDB里面, count()方法其实是把所有符合条件的记录都读出来再算, 因此性能是个大问题. 出于性能考虑Google文档不建议你多使用count, 不建议在可能数据量很大的查询上用count().
count()最多也只能返回1000. 原因同fetch().
关于count(), Group里面讨论了很多解决方法. 一般是建议你自己实现count(): 在数据库中创建几个计数器, 创建新entity时随机拿出一个计数器加一. 把几个计数器的值相加, 就是最终的count值;
事务中所有的entity必须在一个entity group中, 事务中不能有select 查询
非等式过滤条件只能在一个属性(或字段)上. 以下查询就不可以
SELECT * FROM Person WHERE birth_year >= :min_year
AND height >= :min_height
你只能对birth_year属性用不等式
SELECT * FROM Person WHERE birth_year >= :min
AND birth_year <= :max
如果查询中有不等式,并且有Order By, 不等式查询的字段必须第一个被order by; 以下这两个查询都是错误的:
SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY last_name, birth_year"
SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY last_name
这个才行: SELECT * FROM Person WHERE birth_year >= :min_year
ORDER BY birth_year, last_name
看到这么多限制, 是不是觉得很奇怪. Google就拿这么个东西出来现眼吗? Google的解释是这是为了datastore的伸缩性(Scalability). 我的猜测是每个创建的entity会被随机的保存在成百上千的servers中的某个server node上, 使得数据库中aggregation计算代价非常高, 所以更多的计算会被推到app层. 同样的, 事务中所有的entity必须在一个entity group中也是要保证事务中的entity在一个node(或cluster)上. 这仅仅是我的猜想. 有谁知道得更多请留言;
分类:
GAE&Python
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述