在Postgres中实现“已查看”功能
内容提要
文章讨论了在社交网站SupaBook中跟踪帖子浏览量的数据库解决方案，推荐使用HyperLogLog作为高效计数方法，尽管hstore也表现良好。分析了简单计数、hstore、关联表和HyperLogLog的性能，最终认为HyperLogLog在处理大量数据时更具优势，适合未来扩展。
延伸解读
HyperLogLog 的精度与适用场景
HyperLogLog 是一种概率数据结构，用于估算集合的基数，即不同元素的个数。它不存储原始元素，因此内存占用小且固定，适合大规模数据。但计数结果存在误差，例如实际 1000 可能报告 1004。文章指出，这种误差需要在 UI 上考虑，必要时可回退到关联表获取精确值。因此，HLL 适合对精度要求不苛刻的“已查看”计数，尤其是帖子可能被数百万人浏览的场景。
各方案性能对比与选择建议
文章通过基准测试比较了四种方案：简单计数器、hstore、关联表和 HyperLogLog。平均延迟分别为 2.03ms、2.15ms、2.58ms 和 2.16ms。简单计数器最快但会重复计数且并发更新易导致行膨胀；hstore 性能接近但扩展性差；关联表可精确记录用户但性能最差；HLL 性能居中且扩展性最佳。作者建议，尽管数据上 hstore 略优，但考虑到未来增长，HLL 更合适。
实施 HyperLogLog 的注意事项
使用 HyperLogLog 需要安装 citusdata 的 postgresql-hll 扩展，这不是官方 contrib 模块，因此需要自定义 Postgres 镜像。文章还提到，可以保留关联表用于精确查询，但可删除其主键索引以提升写入性能，并定期更新 HLL。此外，可将关联表放在较慢的存储上，以保持 posts 表的高速。这些措施有助于平衡性能与功能。
Q&A
在Postgres中如何实现帖子浏览量的跟踪？
可以通过使用HyperLogLog作为高效计数方法来实现帖子浏览量的跟踪，适合处理大量数据。
HyperLogLog与hstore相比有什么优势？
HyperLogLog在处理大量数据时更具扩展性，适合大规模应用，而hstore在性能上不如HyperLogLog。
简单计数方法在高并发情况下会遇到什么问题？
简单计数方法在并发更新时可能导致数据膨胀，性能不佳。
关联表方法在性能上如何表现？
关联表方法可以存储用户与帖子之间的关系，但在性能上不如hstore和HyperLogLog。
在实际应用中，HyperLogLog是否是最佳选择？
尽管hstore在某些情况下表现良好，但HyperLogLog可能是更好的选择，尤其是在处理大量数据时。
如何在Postgres中创建用于跟踪浏览量的表？
可以通过创建包含用户ID的HyperLogLog列来实现，使用SQL语句添加相应的扩展和列。
