Azure Search如何存储索引数据

我在Azure Search中存储了大量数据。我太贪婪了，所以决定了解索引数据是如何存储的，以预测其大小和服务成本

扰流板：

根据实验，字段名称长度不影响用于索引的存储

输入（结尾的示例）

带有

Id

+9个字符串字段的数据结构。所有字段都有长名称。名称长度与数据长度之比为

24到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"
}

{
    "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"
}

带有

Id

+9个字符串字段的数据结构。所有字段都有短名称。名称长度与数据长度之比为

3到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"
}

{
    "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"
}

实验

对于每个实验，我都使用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

---

insert Seq.ofList |>Seq.map（fun x->IndexAction.Upload x）|>Seq.cast事实上，您为字段指定的名称通常对索引的工作服大小的影响可以忽略不计。文档的每个字段都以多种不同的形式存在于磁盘上（取决于该字段启用了哪些功能，如可搜索、可筛选、可排序等）。大多数表单都经过了大量优化以满足其特定需求，而且在大多数情况下，字段名不需要包含在包含它们的文件中。但是，完整的json原始文档也存储在索引版本旁边（因此可以检索文档）。由于“原始”文档将包括字段名，从技术上讲，字段长度与索引的总体大小之间存在某种线性相关性，但是，相关性应该具有相当弱的系数。验证该系数的最佳方法是通过测试（您已经完成了测试），因为每个用例都是不同的
 因此，对于索引，所有名称在索引过程中都会缩短。还有一个后台服务压缩所有原始JSON文档？不，索引名在索引期间不会缩短。此外，没有对原始JSON文档进行“压缩”。您应该假设推送到服务的文档实际上在索引中的占用空间大于原始文档的大小。正如我在回答中提到的，当您推送文档时，该文档将被大量分析/转换，并且将在索引中的多个表单（包括原始表单）下存在。因此，它在磁盘上的大小将是原始大小（因为我们保留原始文档）加上它转换的所有附加格式的大小，而不知道您在测试中采取了什么步骤，很难解释为什么索引大小在10-20分钟后会发生变化。一般的解释是索引中的每个文件都是“只读”的。当您修改索引（更新、删除、添加文档）时，我们将一些旧文件标记为“将来删除”，因为它们已过时。有一个后台服务将最终删除这些文件，并合并其他一些文件，以提高索引的性能。通过这种方式，索引的大小可能会在没有您直接参与的情况下变小。我在测试中只插入了记录，所以没有任何东西可以回收（我假设）。据我所知，总体索引大小应为
原始数据大小
+
索引数据大小
（其中索引数据取决于配置，例如可搜索、可排序字段等）。因此，我假设字段名长度不同的记录数量完全相同，索引大小也应该不同。但根据我的测试，没有区别。看起来原始数据被压缩了。测试2中规定了原始数据大小，即540B和730B*1.2M和3M记录。因此，应该有前面提到的不同之处，在将文件插入索引时，后台工作人员会合并/删除索引中的文件。即使只“插入”新文档，也需要删除并重新创建索引中的各种文件。例如，所有文本统计（如文档频率）都需要更新，以包括新添加的文档。合并计划确实很难预测，因为它取决于许多因素，如资源利用率、摄取率等。您可以使用完全相同的数据重新创建完全相同的索引，并且每次的大小略有不同。