java - 具有 180 个属性的分片计数器

Question

数据存储中每个实体有 180 个具有整数/长整型类型的未索引属性(列)听起来很糟糕吗？

出于分析原因，我需要计算每个用户每天节省的 6 个请求，并且我正在根据分片计数器文章和网络广播做所有事情: https://cloud.google.com/appengine/articles/sharding_counters

所以基本上每天有 6 个值，每个新请求都会增加，所以我正在考虑:

每月 1 种6 种分析 * 月日 = 180

Google 数据存储区属性中多少才算是过多？

谢谢

Answer 1

可能不是一个好主意。

请记住，每次您想要更新单个属性值时，整个实体都必须重写(即从数据存储中检索、反序列化、更新、重新序列化并重新-发送到数据存储)。实体越大，性能越慢。

恕我直言，在这种情况下，拥有多个较小的实体比拥有一个大的实体更好。可以将一个大实体拆分为多个较小的实体，并有效地相互关联 - 请参阅 re-using an entity's ID for other entities of different kinds - sane idea?

沿着同一路线，我相信甚至可以找到一种方法将日期信息和用户 ID 编码为唯一的自定义 key ID，以便于访问。类似 <userid>_YYMMDD或者只是 <userid>_DD