优化器
与许多其他数据库一样，批量应用更改比单独执行每个更改要高效得多。Qdrant 在这方面也不例外。由于 Qdrant 操作的数据结构并不总是易于更改，有时需要完全重建这些结构。
Qdrant中的存储优化发生在段级别（参见存储）。 在这种情况下，重建期间要优化的段仍然可读。
通过将段包装到一个透明处理数据更改的代理中来实现可用性。 更改的数据被放置在写时复制段中，该段具有检索和后续更新的优先级。
真空优化器
需要重建段存储库的最简单示例是删除点。 与许多其他数据库一样，Qdrant 不会在查询后立即删除条目。 相反，它会将记录标记为已删除，并在未来的查询中忽略它们。
这种策略使我们能够最小化磁盘访问——这是最慢的操作之一。 然而，这种策略的一个副作用是，随着时间的推移，删除的记录会积累，占用内存并减慢系统速度。
为了避免这些不利影响，使用了Vacuum Optimizer。 如果段积累了太多已删除的记录，就会使用它。
优化器的启动标准在配置文件中定义。
以下是参数值的示例：
storage:
optimizers:
# The minimal fraction of deleted vectors in a segment, required to perform segment optimization
deleted_threshold: 0.2
# The minimal number of vectors in a segment, required to perform segment optimization
vacuum_min_vector_number: 1000
合并优化器
服务可能需要创建临时段。 例如，在优化过程中会创建写时复制段。
同样重要的是，至少需要有一个小段，Qdrant 将使用它来存储频繁更新的数据。 另一方面，过多的小段会导致搜索性能不佳。
合并优化器不断尝试减少段的数量，如果当前段的数量过多。所需的段数由default_segment_number指定，默认为CPU的数量。优化器可能会至少将三个最小的段合并为一个。
如果合并后的段大小超过配置的最大段大小max_segment_size_kb，则不会合并段。这可以防止创建过大的段，从而无法高效地进行索引。如果您有大量数据，增加此数值可能有助于减少段的数量，并可能提高搜索性能。
启动优化器的标准在配置文件中定义。
以下是参数值的示例：
storage:
optimizers:
# Target amount of segments optimizer will try to keep.
# Real amount of segments may vary depending on multiple parameters:
# - Amount of stored points
# - Current write RPS
#
# It is recommended to select default number of segments as a factor of the number of search threads,
# so that each segment would be handled evenly by one of the threads.
# If `default_segment_number = 0`, will be automatically selected by the number of available CPUs
default_segment_number: 0
# Do not create segments larger this size (in KiloBytes).
# Large segments might require disproportionately long indexation times,
# therefore it makes sense to limit the size of segments.
#
# If indexation speed have more priority for your - make this parameter lower.
# If search speed is more important - make this parameter higher.
# Note: 1Kb = 1 vector of size 256
# If not set, will be automatically selected considering the number of available CPUs.
max_segment_size_kb: null
索引优化器
Qdrant 允许您根据记录数量选择使用的索引类型和数据存储方法。 例如，如果点的数量少于10000，使用任何索引都会比暴力扫描效率低。
索引优化器用于在达到最小记录量时实现索引和内存映射存储的启用。
优化器的启动标准在配置文件中定义。
以下是参数值的示例：
storage:
optimizers:
# Maximum size (in kilobytes) of vectors to store in-memory per segment.
# Segments larger than this threshold will be stored as read-only memmaped file.
# Memmap storage is disabled by default, to enable it, set this threshold to a reasonable value.
# To disable memmap storage, set this to `0`.
# Note: 1Kb = 1 vector of size 256
memmap_threshold: 200000
# Maximum size (in kilobytes) of vectors allowed for plain index, exceeding this threshold will enable vector indexing
# Default value is 20,000, based on <https://github.com/google-research/google-research/blob/master/scann/docs/algorithms.md>.
# To disable vector indexing, set to `0`.
# Note: 1kB = 1 vector of size 256.
indexing_threshold_kb: 20000
除了配置文件外，您还可以为每个集合单独设置优化器参数。
动态参数更新可能很有用，例如，为了更有效地初始加载点。您可以在上传过程中使用这些设置禁用索引，并在完成后立即启用它。因此，您不会浪费额外的计算资源来重建索引。