关于数据库:一起体验-Milvus-20-新功能

50次阅读

共计 7191 个字符，预计需要花费 18 分钟才能阅读完成。

通过半年多的期待，Milvus 2.0 正式版终于和大家见面了。当初就让咱们一起来体验一下 Milvus 2.0 的一些新性能吧。

删除性能（Entity Deletion)

Milvus 2.0 新增了向量删除性能，容许用户通过向量 id 将某些向量从 Collection 中删除。用户再也不必为一些过期或有效的向量数据犯愁了。连忙试一下：

  1. 筹备数据：插入 300 条 128 维的向量数据
from pymilvus import connections, utility

from pymilvus import Collection, DataType, FieldSchema, CollectionSchema



# connect to milvus

host = 'x.x.x.x'

connections.add_connection(default={"host": host, "port": 19530})

connections.connect(alias='default')



# create a collection with customized primary field: id_field

dim = 128

id_field = FieldSchema(name="cus_id", dtype=DataType.INT64, is_primary=True)

age_field = FieldSchema(name="age", dtype=DataType.INT64, description="age")

embedding_field = FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=dim)

schema = CollectionSchema(fields=[id_field, age_field, embedding_field],

                          auto_id=False, description="hello MilMil")

collection_name = "hello_milmil"

collection = Collection(name=collection_name, schema=schema)



import random

# insert data with customized ids

nb = 300

ids = [i for i in range(nb)]

ages = [random.randint(20, 40) for i in range(nb)]

embeddings = [[random.random() for _ in range(dim)] for _ in range(nb)]



entities = [ids, ages, embeddings]

ins_res = collection.insert(entities)

print(f"insert entities primary keys: {ins_res.primary_keys}")
insert entities primary keys: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299]
  1. 在删除向量之前，先通过 search 和 query 来验证待删除的向量是存在的，并且做二次查问来验证这个后果是牢靠的。
# search

nq = 10

search_vec = [[random.random() for _ in range(dim)] for _ in range(nq)]

search_params = {"metric_type": "L2", "params": {"nprobe": 16}}

limit = 3

# search 2 times to verify the vector persists

for i in range(2):

    results = collection.search(search_vec, embedding_field.name, search_params, limit)

    ids = results[0].ids

    print(f"search result ids: {ids}")

    expr = f"cus_id in {ids}"

    # query to verify the ids exist

    query_res = collection.query(expr)

    print(f"query results: {query_res}")
search result ids: [76, 2, 246]

query results: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]

search result ids: [76, 2, 246]

query results: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]
  1. 删除查问后果中的第一个向量（id=76)
print(f"trying to delete one vector: id={ids[0]}")

collection.delete(expr=f"cus_id in {[ids[0]]}")



results = collection.search(search_vec, embedding_field.name, search_params, limit)

ids = results[0].ids

print(f"after deleted: search result ids: {ids}")

expr = f"cus_id in {ids}"

# query to verify the id exists

query_res = collection.query(expr)

print(f"after deleted: query res: {query_res}")

print("completed")
trying to delete one vector: id=76

after deleted: search result ids: [76, 2, 246]

after deleted: query res: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]

completed
  1. 竟然发现被删除向量（id=76）在删除后还能被 search 和 query 到，这是为什么呢？查看了下代码，发现删除操作是异步的，同时为了提高效率，并没有在数据层真正的做“删除”操作，而是做了删除标记。期待数秒之后再去 query 一下，发现 id=76 的向量曾经不可见了。胜利！
expr = f"cus_id in {[76, 2, 246]}"

# query to verify the id exists

query_res = collection.query(expr)

print(f"after deleted: query res: {query_res}")

print("completed")
after deleted: query res: [{'cus_id': 246}, {'cus_id': 2}]

completed

那么有没有方法在删除后立即查问不可见呢？当然——设置一致性等级。

一致性等级 (Consistency_level)

下面删除的试验中，咱们看到：某个向量被删除后，如果立即去查问该被删除向量还是可能会被查问到的，其实这是因为一致性等级（consistency_level）所决定的。

Milvus 用户能够依据本人的业务场景的不同，灵便配置不同的一致性等级。目前 2.0 反对四种不同的一致性等级：(目前一致性等级设置都是 Collection 级别的，而且只能在新建 Collection 的时候设置，之后不能批改，这显然还不够灵便，前期须要持续优化。)

  • 强一致性(CONSISTENCY_STRONG)：GuaranteeTs 设为零碎最新工夫戳，QueryNodes 须要期待 ServiceTime 推动到以后最新工夫戳能力执行该 Search 申请；
  • 最终一致性(CONSISTENCY_EVENTUALLY)：GuaranteeTs 设为一个特地小的值（比如说设为 1），跳过一致性查看，立即在以后已有数据上执行 Search 查问；
  • 有界一致性(CONSISTENCY_BOUNDED)：GuaranteeTs 是一个比零碎最新工夫稍旧的工夫，在可容忍范畴内能够立即执行查问；
  • 客户端一致性(CONSISTENCY_SESSION)：客户端应用上一次写入的工夫戳作为 GuaranteeTs，那么每个客户端至多能看到 本人插入的全副数据。

在 2.0 正式版之前，Milvus 默认为 ** 强一致性 **；从 2.0 正式版开始，Milvus 默认为** 有界一致性 **。这次要是思考到绝大多数场景下，相比于响应速度，用户对数据一致性的要求是比拟低的。因而应用** 有界一致性 ** 能够更大限度地均衡用户对响应速度和数据一致性的要求（具体设计点这里）。

那么：** 有界一致性 **的查问速度真的会更快么？老规矩，试验一下：

  1. 简略批改一下下面例子中 search 的代码，查问 5 次别离记录一下查问提早
for i in range(5):

    start = time.time()

    results = collection.search(search_vec, embedding_field.name, search_params, limit)

    end = time.time()

    print(f"search latency: {round(end-start, 4)}")

    ids = results[0].ids

    print(f"search result ids: {ids}")
  1. 雷同的数据规模和查问参数，设置为 CONSISTENCY_STRONG 的 Collection：
collection_name = "hello_milmil_consist_strong"

collection = Collection(name=collection_name, schema=schema,

                        consistency_level=CONSISTENCY_STRONG)
search latency: 0.3293

search latency: 0.1949

search latency: 0.1998

search latency: 0.2016

search latency: 0.198

completed
  1. 设置为 CONSISTENCY_BOUNDED 的 Collection（2.0 正式版后的默认值）：
collection_name = "hello_milmil_consist_bounded"

collection = Collection(name=collection_name, schema=schema,

                        consistency_level=CONSISTENCY_BOUNDED)
search latency: 0.0144

search latency: 0.0104

search latency: 0.0107

search latency: 0.0104

search latency: 0.0102

completed
  1. 非常明显，设置了 有界一致性 的查问响应速度都变快了 200ms 左右。

那么下面删除试验中，如果设置了 强一致性，是不是被删除的向量就立即会查问不可见呢？答案是必定的。无妨本人试验一下吧。

动静加载索引 (Handoff)

在 Streaming 场景下，很多用户会先对 collection 做 build index 和 load 操作，而后再插入数据，但在 Milvus 2.0 之前这并不能保障 QueryNode 加载的肯定是索引。因而须要在建完索引后，手动从新加载一下 collection，能力将内存中加载的原始向量替换成索引，麻烦而且耗时。2.0 推出 Handoff 性能：当一个 segment 从 growing 变为 sealed 的时候，如果该 segment 的 Collection 曾经建设了索引，Milvus 会期待这个 segment 建完索引后再加载带索引的 sealed segment 来替换原来的 growing segment，这样能大大提高查问性能。

  1. 再改变一下代码，在插入数据之前，先建设索引并启动加载向量：
# index

index_params = {"index_type": "IVF_SQ8", "metric_type": "L2", "params": {"nlist": 64}}

collection.create_index(field_name=embedding_field.name, index_params=index_params)

# load

collection.load()
  1. 每次插入 5 万条向量，循环插入 200 次（为了不便，我插入了雷同的向量，但不影响此试验后果）
import random

# insert data with customized ids

nb = 50000

ids = [i for i in range(nb)]

ages = [random.randint(20, 40) for i in range(nb)]

embeddings = [[random.random() for _ in range(dim)] for _ in range(nb)]

entities = [ids, ages, embeddings]

for i in range(200):

    ins_res = collection.insert(entities)

    print(f"insert entities primary keys: {ins_res.primary_keys}")
  1. 在插入过程中和完结后查问 QueryNode 加载向量的状况：
# I did this in another python console

>>> utility.get_query_segment_info("hello_milmil_handoff")

[segmentID: 430640405514551298

collectionID: 430640403705757697

partitionID: 430640403705757698

mem_size: 394463520

num_rows: 747090

index_name: "_default_idx"

indexID: 430640403745079297

nodeID: 7

state: Sealed

, segmentID: 430640405514551297

collectionID: 430640403705757697

partitionID: 430640403705757698

mem_size: 397536480

num_rows: 752910

index_name: "_default_idx"

indexID: 430640403745079297

nodeID: 7

state: Sealed

...
  1. 所有加载到 QueryNode 的 Sealed segments 都是带索引的（有 index_name 的）：）

结语

除了这 3 个性能外，Milvus 2.0 正式版还推出了如数据压缩 (Data Compaction)，动静负载平衡(Dynamic Load Balance) 等许多新性能，这些就留给大家本人去试验挖掘吧。

Milvus 我的项目地址：https://github.com/milvus-io/…

Milvus 主页及文档地址：https://milvus.io/

Milvus Slack Channel：milvusio.slack.com

正文完
数据库
发表至： 数据库
2022-02-17
 0
关于数据库:实践教程之使用-PolarDBX-进行-TP-负载测试
关于数据库:在-PisaProxy-中如何利用-Rust-实现-MySQL-代理
关于数据库:IP地理定位之数据驱动广告矩阵
关于数据库:关于IP定位查询接口的测评Ⅱ