#c# #bytearray #azure-storage #value-type #azure-blob-storage
#c# #массивы #azure-хранилище #тип значения #azure-blob-storage
Вопрос:
Я начну с того, что это будет немного сложнее, чем слепое объединение byte[]
вместе.
Моя общая цель — оптимизировать приложение, которое в настоящее время загружает много страниц объемом 512 байт на веб-сервер (Azure Page Blob), и сократить это до одной большой загрузки в 4 мегабайта или меньше. Смотрите ссылки внизу этого вопроса для получения дополнительной информации о том, почему.
Краткий ответ на вопрос, почему: эта оптимизация увеличит скорость (меньше iOS) и сэкономит деньги в долгосрочной перспективе за счет использования разреженных файлов Azure
Теперь о деталях:
Классу потребуется
-
Принимать данные и сохранять их (данные, определенные как
alignment start
,alignment stop
и сопутствующая полезная нагрузка. -
После того, как поступит N фрагментов данных или
event
произойдет,ProcessData()
. Это означает, что пришло время собрать данные в соответствии с границами (конечное значениеblob1
должно совпадать с начальным значениемblob2
) -
Последовательные данные могут на самом деле поступать не по порядку.
-
Непоследовательные данные определяются как когда вызывающее приложение не отправляет их до
processData()
возникновения. Кроме того, если весь диапазон в 512 байт == ноль, то он получает специальную передачу и рассматривается как непоследовательный. -
Мы имеем дело с типами byte[], поэтому эффективные списки здесь могут быть сложными. Я бы хотел избежать ненужных копий и расширений массива.
Имеет смысл? (как mud, я надеюсь, что нет)
Самое близкое, к чему я пришел до сих пор, — это написание подписи метода: (хромает, я знаю)
// This can't be bigger than 4Mb, or smaller than 512
byte[] BigBlobToUpload = new byte[];
/// <summary>
/// Collects consecutive data ranges that will be uploaded
/// </summary>
/// <param name="NameOfTarget">The name of the target (unique per host)</param>
/// <param name="range">The data to be collected, in 512K multiples</param>
/// <param name="offsetToTransfer">The "start point" or offset of the data stored in range to be included. Almost always 0.</param>
/// <param name="sizeToTransfer">The length, or end of the range to include. Almost always 512.</param>
/// <param name="cloudOffset">The location this data should be placed in the BigBlobToUpload global var for eventual upload</param>
private void AddToQueue(string NameOfTarget, byte[] range, int offsetToTransfer, int sizeToTransfer, int cloudOffset)
{
}
Мне просто нужно, чтобы кто-нибудь дал мне указания о том, как эффективно отслеживать эти вещи… Я могу справиться с этим оттуда. Даже абстрактное направление помогло бы
Может ли кто-нибудь направить меня в правильном концептуальном направлении о том, как я должен отслеживать и условно присоединять последовательные диапазоны данных?
Не говоря уже о том, что я пытаюсь иметь эффективную логику, которая только расширяет или копирует массив, когда это необходимо.
Комментарии:
1. Можете ли вы объяснить: «Это немного сложнее, чем слепое объединение byte[] вместе, потому что приложение может пропустить диапазон, чтобы воспользоваться преимуществами разреженной файловой системы Azure. (запись нулей никогда не требуется и никогда не оплачивается) » ?
2. @GianT971 Мне нужно пропускать, а не загружать, каждый раз, когда я получаю все нули на границе 512 выровненных байтов. Это может произойти либо из-за того, что хост записывает все нули, либо просто опуская данные и не вызывая мою функцию. Вот почему я думаю, что мне нужно отслеживать начальные / конечные точки каждой страницы размером 512 байт… а затем выполнять итерацию по каждой отправленной странице, объединять и отправлять. Я не уверен, как отследить это (или начать).
3. Связанный блог Blob-объектов Azure Page
4. Интересно. Таким образом, ваш диапазон может быть разделен на куски по 512 байт, и любой фрагмент, который будет содержать все нули, будет просто удален, это правильно?
5. По сути, но поскольку хост может захотеть фактически стереть сохраненные данные, я создам специальный
page clear
заголовок для удаления этого диапазона. Я полагаю, что я буду отслеживать последовательные очистки страниц с тем же шаблоном, который я использую для отслеживания действительных данных. Результирующее действие будет отличаться только.