Как отслеживать отдельные объекты, которые вышли из строя, а затем присоединять() к последовательным?

#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 заголовок для удаления этого диапазона. Я полагаю, что я буду отслеживать последовательные очистки страниц с тем же шаблоном, который я использую для отслеживания действительных данных. Результирующее действие будет отличаться только.