c# - Azure 表存储查询性能缓慢

Question

我正在针对 Azure 表存储运行一系列结构良好的查询，据我所知，这些查询应该返回亚秒级。事实上，如果我手动运行它们(例如，从 Visual Studio 内的 Azure 工具)，它们确实会立即返回。但当我在生产中运行它们时，它们有时需要 20-30 秒才能返回。

这是我调用 ATS 的 C# 代码:

public async Task<IList<T>> FindAsync(string filter, int maxRecords = int.MaxValue, IList<string> columns = null)
{
    var returnList = new List<T>();
    try
    {
        Interlocked.Increment(ref _outstandingRequests);
        var query = new TableQuery<T>().Where(filter);
        if (columns != null && columns.Any())
        {
            query = query.Select(columns);
        }
        TableQuerySegment<T> querySegment = null;
        var sw = new Stopwatch();
        sw.Start();
        while (returnList.Count < maxRecords && (querySegment == null || querySegment.ContinuationToken != null))
        {
            try
            {
                await 3.RetriesAsync(async x =>
                {
                    querySegment = await
                        Table.ExecuteQuerySegmentedAsync(query,
                            querySegment != null ? querySegment.ContinuationToken : null);
                });
                returnList.AddRange(querySegment);
            }
            catch (Exception ex)
            {
                _logger.Error("Error executing ATS query; table:{0}; filter:{1}; error:{2}",
                    typeof(T).GetFriendlyTypeName(), filter, ex.CompleteMessage());
                throw;
            }
        }
        sw.Stop();
        if (sw.ElapsedMilliseconds > 10000)
        {
            var stat = new RepoOperationStats(filter, sw, returnList.Count, _outstandingRequests);
            _logger.Warn("Long-running {0} query: secs:{1:0.0}, rc:{2}, or:{3}, fi:{4}",
                typeof(T).GetFriendlyTypeName(), stat.Milliseconds / 1000d, stat.ResultCount, stat.OutstandingRequests, stat.Filter);
        }
    }
    finally
    {
        Interlocked.Decrement(ref _outstandingRequests);
    }
    return returnList;
}

这是存储在表中的实体的示例:

一切都相当简单。但在我的日志中，我看到重复的错误，如下所示:

Long-running AtsOrganizationEventSummaryByCookie query: secs:33.3, rc:0, or:94, fi:(PartitionKey eq '4306.www-detail-mercury-mars-skywatching-tips.html-get') and ((RowKey ge '2015.02.05.00000000-0000-0000-0000-000000000000') and (RowKey le '2015.02.07.00000000-0000-0000-0000-000000000000'))

换句话说，返回零行需要 33 秒。请注意，它只命中一个分区，并且应该能够对该分区内的行索引进行简单的查找。 (事实上​​，相同的查询在其他上下文中会立即返回。)

我遇到了某种限制机制吗？我应该注意，我正在并行调用这些查询，因此在任何给定时间点，可能会有十几个到一百多个查询未完成。但看起来 (a) 我的客户和 (b) ATS 都应该能够处理该级别的负载。

关于如何解决此问题有什么建议吗？

Answer 1

你的过滤器是什么？从您拥有的日志来看，您似乎正在执行扫描操作

(RowKey '2015.02.05.00000000-0000-0000-0000-000000000000') 和 (RowKey '2015.02.07.00000000-0000-0000-0000-000000000000')

虽然 RowKey 已建立索引，但当您通过诸如 ge 或 le 之类的比较来按一系列行键进行筛选时，它会执行扫描，根据表的大小，这可能会非常慢。

您可以尝试将整个分区 4306.www-detail-mercury-mars-skywatching-tips.html-get 加载到内存中并进行过滤，看看是否更快。

顺便说一句，从您的实体数据结构来看，您似乎正在尝试记录事件来访问网页。如果是，您可能需要查看 Application Insights。它更适合遥测记录。