0

我们正在使用 Windows azure 表来记录我们在工作角色或 Web 角色中托管的应用程序中的错误。我们在表中记录了足够的信息，以便于识别哪个角色、哪个类的组件记录了错误。

组件 ID（完全限定的类名）用作分区键，随机唯一 Guid 用作行键。

此日志信息显示在 ASP.NET MVC 网站上，管理员可以在其中根据组件 ID、日期范围、角色标识符、严重性等过滤条件搜索此日志。

这工作正常，直到桌子很小。一旦 azure table 包含大量记录（200000 或更多），则在 azure table 上进行过滤会花费太长时间并且超时。我们正在使用 .NET azure storage API 来查询表。

我们还希望对返回的结果集进行分页，但看起来在 azure table 中我们没有得到返回记录的准确计数。

我们尝试使用 azure storage API 来应用过滤器并根据当前页码获取数据，但它不起作用。我知道我们可能需要重新设计我们的表结构，尤其是 partitionkey 和 rowkey，但不知道如何进行。

4

3 回答 3

1

使用表存储时，您只有 2 个“索引”属性，即分区键和行键。如果您有大量数据，则在其他字段上搜索会非常慢。

在实现分页系统或想要对数据进行排序时，您应该使用行键。行键定义数据的顺序（排序顺序是字典顺序）。

我建议您查看 Steve 的博客文章，了解有关对数据进行排序和排序的更多信息：在 Windows Azure 中使用数字作为键

于 2012-06-09T07:34:16.577 回答
0

如果您需要大量自定义过滤器，表存储可能无法提供最佳性能。如果可能，请考虑使用 SQL Azure。要提高表存储性能，您可以尝试：

  1. 不要使用自定义过滤器。仅使用分区/行键过滤结果。这将为您提供最佳性能。

  2. 使每个分区变小。扫描小分区比扫描大分区快。

至于分页，除非您有跨分区查询，否则分页应该按预期工作。如果您要求 20 个实体，则将返回正好 20 个实体（如果有这么多）。但如果遇到分区边界，则需要一个新页面。例如，如果在找到第 15 个匹配实体时遇到分区边界，则此请求中将仅返回 15 个实体。您必须创建一个新请求来查询下一个分区。如果您保持较小的分区，您可能会更频繁地遇到此问题。因此，您需要将系统设计为在需要时自动查询下一个分区。

还要记住，表存储的分页不是基于页码的。它基于延续令牌。有关详细信息，请参阅http://msdn.microsoft.com/en-us/library/dd135718.aspx。

于 2012-06-11T05:20:08.597 回答
0

在这种情况下，我会建议我为在 Azure 表中存储日志而编写的记录器 - QLog。您可以通过 NuGet 获得它。它带有一个 QLogBrowser，允许您以您想要的方式查询日志。GitHub 项目站点在这里。

于 2012-12-15T22:02:14.823 回答