如何对用于存储日志的Azure表进行分区

Question

我们最近更新了我们的日志记录以使用Azure表存储,由于它在行和分区查询时非常适合于此目的而具有低成本和高性能.

我们正在尝试遵循为Azure表存储设计可扩展分区策略文档中给出的准则.由于我们正在为此表格进行大量插入(并且希望随着我们的扩展而增加数量),我们需要确保不会达到我们的限制,从而导致日志丢失.我们的设计结构如下:

• 我们在每个环境(DEV,TEST,PROD)上都有一个Azure存储帐户.

• 我们每个产品都有一张桌子.

• 我们对Row Key使用TicksReversed + GUID,这样我们就可以在特定时间内以高性能查询结果块.

• 我们最初选择使用Logger对表进行分区,对于我们来说,这是产品的广泛领域,如API,应用程序,性能和缓存.然而,由于分区数量较少,我们担心这导致所谓的"热"分区,其中在给定时间段内在一个分区上执行了许多插入.所以我们改为上下文分区(对我们来说,类名或API资源).

然而,在实践中我们发现这不太理想,因为当我们一目了然地查看我们的日志时,我们希望它们按时间顺序出现.我们最终会得到按上下文分组的结果块,如果我们想按时间排序,我们必须得到所有分区.

我们有一些想法

• 使用时间块(比如1小时)分区键按时间排序(导致热分区1小时)

• 使用一些随机的GUID进行分区键尝试分发日志(我们无法快速查询Context等功能).

由于这是Azure表存储的常见应用程序,因此必须有某种标准过程. 分区用于存储日志的Azure表的最佳做法是什么？

解决方案约束

• 使用便宜的Azure存储(表存储似乎是显而易见的选择)

• 快速,可扩展的写入

• 丢失日志的可能性很小(即,超过Azure表存储中每秒2000个实体的分区写入速率).

• 阅读按日期排序,最近一次.

• 如果可能的话,对可能对查询有用的东西进行分区(例如产品区域).

Answer 1

根据我的经验,我遇到过类似的情况,我可以说:

每当在azure存储表上触发查询时,如果未提供正确的分区键,它将执行全表扫描.换句话说,存储表在分区键上编制索引,正确分区数据是获得快速结果的关键.

也就是说,现在你将不得不考虑你会在桌面上发出什么样的查询.例如在一段时间内发生的日志,对于产品等.

一种方法是使用高达小时精度的反向刻度,而不是使用精确刻度作为分区键的一部分.这样,可以根据此分区键查询一小时的数据.根据落入每个分区的行数,您可以将精度更改为一天.此外,将相关数据存储在一起是明智的,这意味着每个产品的数据将转到不同的表.这样,您可以减少每个分区中的分区数和行数.

基本上,确保您事先知道分区键(精确或范围)并针对此类特定分区键触发查询以更快地获得结果.

要加快写入表格,您可以使用批处理操作.但要谨慎,好像批处理中的一个实体未能完成整批操作失败.正确的重试和错误检查可以节省您的时间.

同时,您可以使用blob存储来存储大量相关数据.这个想法是将一大块相关的序列化数据存储为一个blob.您可以点击一个这样的blob来获取其中的所有数据,并在客户端进行进一步的预测.例如,产品的一小时数据将转到blob,您可以设计特定的blob前缀命名模式,并在需要时点击确切的blob.这将帮助您快速获取数据,而不是为每个查询执行表扫描.

我使用blob方法并且已经使用它几年没有麻烦.我将我的集合转换为IList<IDictionary<string,string>>并使用二进制序列化和Gzip来存储每个blob.我使用基于Reflection.Emmit的辅助方法来快速访问实体属性,因此序列化和反序列化不会对CPU和内存产生影响.

在blob中存储数据可以帮助我以更少的价格存储更多内容并更快地获取数据.