我目前正在将一些工作从MySQL移植到Google App Engine/Java。我正在使用JDO,以及需要的低级java API。
我通读了关于分片计数器的优化指南:http://code.google.com/appengine/articles/sharding_counters.html
我还在构建我的应用程序的基础。我知道过早优化是万恶之源;但为了避免争执,这一点有明确的文档记录。所以我很难决定我是应该偏颇还是偏颇。
那么,我是否应该默认使用分片计数器(以及其他可能频率更高的写操作对象),还是应该不使用分片继续执行,并根据需要实现?
发布于 2011-09-27 12:40:32
“过早”在这里的突出含义是“在适当的时间之前”。当人们很好地理解这些限制时,设计避免这些限制还为时过早。
切分你的计数器。
发布于 2011-09-27 12:04:20
即使有了有效的分片,维护聚合也会给应用程序增加一些实质性的负载。如果您需要该聚合,并且您负担不起近似值;那么使用分片聚合并不是一个过早的优化;没有下一个最佳的替代方案。如果你实际上不需要计数器,那么实现它所需的时间可以花在其他地方。
https://stackoverflow.com/questions/7564016
复制相似问题