分片还是不分片？ GAE/java/jdo
我目前正在将一些工作从 MySQL 移植到 Google App Engine/Java。我正在使用 JDO，以及需要的较低级别的 java API。
我通读了有关分片计数器的优化指南：http://code.google.com/appengine /articles/sharding_counters.html
我仍在构建我的应用程序的基础。我知道过早的优化是万恶之源；但这是明确记录的以避免争用。所以我很难决定我是否应该以某种方式存在偏见。
那么我应该默认对计数器（以及其他可能更高频率的写入操作对象）进行分片，还是应该在不分片的情况下继续并根据需要实施？
I'm currently porting some work from MySQL to Google App Engine/Java. I'm using JDO, as well as the lower level java API where required.
I read through the optimization guide about sharding counters: http://code.google.com/appengine/articles/sharding_counters.html
I'm still building the foundation of my app. I know that premature optimization is the root of all evil; but this is clearly documented in order to avoid contention. So I'm having trouble deciding if I should be biased one way or the other.
So should I be sharding counters (and other possibly higher frequency write operation objects) by default, or should I go forward without sharding and implement on an as needed basis?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里“过早”的显着含义是“在适当的时间之前”。当这些限制被充分理解时，设计避免限制并不为时过早。
分割你的柜台。
The salient meaning of "premature" here is "before the proper time." Designing to avoid limits, when those limits are well understood, is not premature.
Shard your counters.
即使使用有效的分片，维护聚合也会给您的应用程序增加一些大量的负载。如果您需要该聚合，但又无法提供近似值；那么使用分片聚合不是是过早的优化；没有下一个最佳选择。如果您实际上不需要计数器，那么实现它所需的时间最好花在其他地方。
Even with effective sharding, maintaining aggregates can add some substantial load to your application. If you need that aggregate, and you can't afford an approximation; then using a sharded aggregate is not a premature optimization; there is no next best alternative. If you don't actually need the counter, then the time it will take to implement it could be better spent elsewhere.