Лучший способ выполнить большое количество запросов таблиц Azure?

Question

У меня есть таблица Azure, в которой содержится более миллиона записей, и я пытаюсь выполнить около 300 000 запросов программно в C# для передачи некоторых данных в другую систему. В настоящее время я делаю следующее, читая файл с ключами раздела и строки:

while (!reader.EndOfStream)
{
    // parse the reader to get partition and row keys
    string currentQuery = TableQuery.CombineFilters(TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, partKey), TableOperators.And, TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, rowKey));
    TableQuery<MyEntity> query = new TableQuery<MyEntity>().Where(currentQuery);

    foreach (MyEntity entity in table.ExecuteQuery(query))
    {
        Console.WriteLine(entity.PartitionKey + ", " + entity.RowKey + ", " + entity.Timestamp.DateTime);
    }

    Thread.Sleep(25);
}

На это уходит очень много времени (5+ часов). Запросы занимают в среднем около 200 миллисекунд из того, что я вижу. Я новичок в Azure, поэтому я полагаю, что делаю что-то не так. Как я могу улучшить это?

Answer 1

Несколько вещей:

1. Не уверен, почему у вас есть спящий вызов в вашей петле. Если вас не душат (хранилище поддерживает 20000 транзакций в секунду), вам это не нужно.
2. С данным ключом раздела и ключом строки вы получите ровно одну возвращаемую сущность (так как комбинация pk+rk уникальна). Не нужно перебирать свои результаты. Вы получите либо ноль, либо один.
3. Вы используете однопотоковый подход, поэтому маловероятно, что вы сможете очень сильно увеличить скорость транзакций хранения. Попробуйте распараллелить ваши поиски.
4. Я предполагаю, что ты не звонишь Console.Writeline() в вашем реальном приложении. Если это так, это также замедлит вас.
5. Рассмотрите возможность отключения алгоритма Нейгла через ServicePointManager.UseNagleAlgorithm = false;, В противном случае отдельные низкоуровневые вызовы в хранилище могут буферизироваться до 500 мс для более плотной упаковки пакетов tcp. Это будет важно, если вы тратите циклы на обработку прочитанного контента.