Как Azure Search хранит данные индекса

Question

У меня много данных, хранящихся в Поиске Azure. И я слишком жадный, поэтому решил понять, как хранятся данные индекса, чтобы предсказать его размер и стоимость обслуживания.

Спойлер: According to the experiment field name length does not impact the storage used for the index

Ввод (примеры в конце)

1. Структура данных с Id + 9 строковыми полями. Все поля имеют длинные имена. Длина имени до длины данных составляет 24 to 37

   Пример записи:

   {
       "Id": "55bd7474-1e48-464c-a54d-bc2f3d8b0383",
       "MySuperLongNameProperty": "0e2c5f5e-9464-4030-bf3f-9de41181faff",
       "MySuperLongName2Property": "aa521300-1925-4dd6-97f2-f27fed1b720e",
       "MySuperLongName3Property": "9eec9f1f-d970-4581-8677-92cd735c9d80",
       "MySuperLongName4Property": "e3b4619b-bb8c-4fa2-82b2-55287f4262ae",
       "MySuperLongName5Property": "e6b79880-650d-4733-b91a-e5a4e066811d",
       "MySuperLongName6Property": "d391c66c-f3c6-45e2-96ef-80ab682fa07b",
       "MySuperLongName7Property": "62a92d68-74e6-41b1-8f92-ac3795b649cd",
       "MySuperLongName8Property": "83510497-a6b0-4d6e-9130-0f8deefd73db",
       "MySuperLongName9Property": "977e397e-5fc9-4677-afaf-52b9ea0a8f23"
   }
   

2. Структура данных с Id + 9 строковыми полями. Все поля имеют короткие имена. Длина имени до длины данных составляет 3 to 37

   Пример записи:

   {
       "Id": "f403f9ce-b343-4e38-bc4b-24d300eb13fb",
       "mp": "10970b17-62fe-431a-bf4f-d5a17266c4dc",
       "m2p": "b338290b-069b-4494-8c9e-8da85aad0990",
       "m3p": "1be76d7f-07d2-4648-9888-ed15ec7b3857",
       "m4p": "327206c8-561c-4651-95e0-06c58f83739a",
       "m5p": "241b2be7-9aac-41f9-b669-c5c768acd42e",
       "m6p": "55a1691a-d525-442e-b369-380d2480f2b1",
       "m7p": "a1263c81-022b-4f59-97fe-8916e1457d35",
       "m8p": "b4a4819b-185b-46ab-8e34-838fbc8a598a",
       "m9p": "38bc1df8-81cf-4005-bb14-2fe8a1c6797a"
   }
   

Эксперименты

Для каждого эксперимента Iиспользовал данные Guid для заполнения всех полей (.NET Guid.NewGuid().ToString()).

Также эксперименты выполняются в виде N пакетов * 1000 элементов:

let insert<'t> (client: ISearchIndexClient) (docs: 't list) =
        let actions = docs |> Seq.ofList |> Seq.map(fun x -> IndexAction.Upload x) |> Seq.cast<IndexAction<'t>>
        let batch = IndexBatch.New(actions)
        client.Documents.Index batch |> ignore

for x in [1..1000] do
  let batch = [1..1000] |> List.map(fun i -> {.. generate record ..})
  insert batch

Итак, некоторые числа:

1. Добавление 1,2M записей в индекс

   Размер хранилища длинных имен: 1.68Gb

   Размер хранилища коротких имен: 1.65Gb

2. Добавление 3M записей в индекс

   Размер хранилища длинных имен: 5,53 ГБ (~ 2 ГБ необработанных текстовых данных JSON)

   Размер хранилища коротких имен: 4,11 ГБ (~ 1,5 ГБ сырых текстовых данных JSON))

   Через 10-20 минут, внезапно, общий размер автоматически уменьшился

   Размер хранилища длинных имен: 4.04Gb

   Размер хранилища коротких имен: 4.06Gb

Изначально я ожидал увидеть поведение, описанное здесь . Но после 2-го эксперимента разница в размере была значительной (индекс еще не был сжат).

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

В результате, насколько я вижу, нет разницы в именовании полей, так как длина имени поля будетне влияет размер хранилища

Есть мысли или объяснения?

Answer 1

Действительно, имя, которое вы даете своим полям, должно, как правило, оказывать незначительное влияние на размер комбинезона в вашем индексе. Каждое поле документа существует на диске в нескольких различных формах (в зависимости от того, какие функции включены для этого поля, такие как поиск, фильтрация, сортировка и т. Д.). Большинство этих форм сильно оптимизированы для удовлетворения их конкретных потребностей, и в большинстве случаев имена полей не нужно включать в файлы, которые их содержат. Однако полные исходные документы json также хранятся вместе с индексированными версиями (поэтому документ можно получить). Поскольку «исходные» документы будут включать имена полей, технически, между длиной полей и общим размером вашего индекса будет некоторая линейная корреляция, однако корреляция должна иметь довольно слабый коэффициент. Лучший способ проверить, что это за коэффициент, - это тесты (которые вы уже сделали), поскольку каждый вариант использования будет отличаться.