Question

我在Azure搜索中存储了很多数据。而且我太贪心了，因此决定了解如何存储索引数据以预测其大小和服务成本。

剧透： According to the experiment field name length does not impact the storage used for the index

输入（末尾为示例）

具有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"
}

具有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"
}

实验

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

所以，一些数字：

为索引添加120万条记录

全名存储大小：1.68Gb

短名称存储大小：1.65Gb
将3M条记录添加到索引

全名存储大小：5.53Gb（〜2Gb原始JSON文本数据）

短名称存储大小：4.11Gb（〜1.5Gb原始JSON文本数据）

10到20分钟后，整体尺寸突然自动减小

长名存储大小：4.04Gb

短名称存储大小：4.06Gb

最初，我希望看到描述为here的行为。但是在第二次实验之后，大小差异很大（索引尚未压缩）。

毕竟，我假设关于如何存储索引数据的策略很少。对于小型索引，字段名称可能会自动压缩。对于较大的服务器，它按原样存储，但计划后台服务以进行进一步压缩。

结果，据我所知，字段的命名没有区别，因为字段名的长度不会影响存储空间

有什么想法或解释吗？

Answer 1

实际上，您为字段指定的名称通常对索引的总体大小的影响可以忽略不计。每个文档字段都以多种不同形式存在于磁盘上（取决于该字段启用了哪些功能，例如可搜索，可过滤，可排序等）。这些表单中的大多数都经过了优化，以满足其特定需求，并且在大多数情况下，字段名称不需要包含在包含它们的文件中。但是，完整的json原始文档也将与索引版本一起存储（以便可以检索该文档）。由于“原始”文档将包括字段名称，因此从技术上讲，字段的长度与索引的整体大小之间将存在一些线性相关性，但是，相关性应具有相当弱的系数。验证系数是什么的最好方法是通过测试（您已经完成），因为每种用例都不同。

Azure搜索如何存储索引数据

1 个答案: