问题
In a shared expenses app that shows payments dues and shared expenses details for each group. As a financial application, so many operations are transactional, which requires strong consistency to ensure data integrity. We used Entity Groups and ancestor queries which seems to have solved the issue of strong consistency, this caused the entity group to be large in size. As the shared 'group' is now the parent of members, expenses, payments, dues..etc. Until now we don't see a problem, but we are worried as this scales, expenses and/or payments can scale to the order of 10~100K entities.
After a bit of research we found these suggestions:
- Turning back to eventual consistency, and writing to memcache to overcome eventual consistency. Is this the best solution? We couldn't find enough docs on how to update an entity in memcache, if you know any please share! Also how can we ensure writes are transactional in that case?
- Keep things as is, as there is no entity group size. But we are worried of what would happen later, as the docs mentioned keeping entity groups no larger than a single user's worth of data
- Switch to RDBMS, might be too late for that now
We don't have a problem with the 1 write/sec rule right now as usually in those groups there isn't much going on per second for this to cause a problem, but we don't want to run into an issue later. It would be cumbersome to migrate or change the data models, specially that changing or removing ancestors, requires rewriting the entities, lots of delete and write requests which also costs!
Appreciate your input
来源：https://stackoverflow.com/questions/48613205/google-datastore-strong-consistency-and-entity-group-max-size