我们最近更新了我们的日志记录以使用Azure表存储,由于它在行和分区查询时非常适合于此目的而具有低成本和高性能.
我们正在尝试遵循为Azure表存储设计可扩展分区策略文档中给出的准则.由于我们正在为此表格进行大量插入(并且希望随着我们的扩展而增加数量),我们需要确保不会达到我们的限制,从而导致日志丢失.我们的设计结构如下:
我们在每个环境(DEV,TEST,PROD)上都有一个Azure存储帐户.
我们每个产品都有一张桌子.
我们对Row Key使用TicksReversed + GUID,这样我们就可以在特定时间内以高性能查询结果块.
我们最初选择使用Logger对表进行分区,对于我们来说,这是产品的广泛领域,如API,应用程序,性能和缓存.然而,由于分区数量较少,我们担心这导致所谓的"热"分区,其中在给定时间段内在一个分区上执行了许多插入.所以我们改为上下文分区(对我们来说,类名或API资源).
然而,在实践中我们发现这不太理想,因为当我们一目了然地查看我们的日志时,我们希望它们按时间顺序出现.我们最终会得到按上下文分组的结果块,如果我们想按时间排序,我们必须得到所有分区.
我们有一些想法
使用时间块(比如1小时)分区键按时间排序(导致热分区1小时)
使用一些随机的GUID进行分区键尝试分发日志(我们无法快速查询Context等功能).
由于这是Azure表存储的常见应用程序,因此必须有某种标准过程. 分区用于存储日志的Azure表的最佳做法是什么？
使用便宜的Azure存储(表存储似乎是显而易见的选择)
快速,可扩展的写入
丢失日志的可能性很小(即,超过Azure表存储中每秒2000个实体的分区写入速率).
阅读按日期排序,最近一次.
如果可能的话,对可能对查询有用的东西进行分区(例如产品区域).