Я пытаюсь оптимизировать операцию, когда я вставляю несколько десятков тысяч Foo
s в таблицу Azure.
В настоящее время метод выглядит следующим образом:
public void AddBulk(IReadOnlyList<Foo> foos)
{
var parallelOptions = new ParallelOptions() { MaxDegreeOfParallelism = 4 };
Parallel.ForEach(foos.GroupBy(x => x.QueryingId), parallelOptions, groupedFoos =>
{
var threadTable = Table;
foreach (var chunkedAmounts in groupedFoos.ToList().Chunk(100))
{
var batchOperation = new TableBatchOperation();
foreach (var amount in chunkedAmounts)
{
// Echo content off. This further reduces bandwidth usage by turning off the
// echo of the payload in the response during entity insertion.
batchOperation.Insert(new FooTableEntity(amount), false);
}
// Exponential retry policies are good for batching procedures, background tasks,
// or non-interactive scenarios. In these scenarios, you can typically allow more
// time for the service to recover—with a consequently increased chance of the
// operation eventually succeeding. Attempt delays: ~3s, ~7s, ~15s, ...
threadTable.ExecuteBatchAsync(batchOperation, new TableRequestOptions()
{
RetryPolicy = new ExponentialRetry(TimeSpan.FromMilliseconds(deltaBackoffMilliseconds), maxRetryAttempts),
MaximumExecutionTime = TimeSpan.FromSeconds(maxExecutionTimeSeconds),
}, DefaultOperationContext);
}
});
}
Я обновил метод до библиотек .NET Core, , которые не поддерживают синхронизацию через асинхронные API.Поэтому я переоцениваю метод add и преобразую его в асинхронный.
Автор этого метода вручную сгруппировал foos по идентификатору, который используется для ключа раздела, вручную разбил их на пакеты100, а затем загрузил их с 4x параллелизмом.Я удивлен, что это будет лучше, чем некоторые встроенные операции Azure.
Какой самый эффективный способ загрузки, скажем, 100 000 строк (каждая из которых состоит из 2 направляющих, 2 строк, отметки времени иint) в хранилище таблиц Azure?