“让技术被看见 | OceanBase 布道师计划”是由 OceanBase 主办，墨天轮、ITPUB、CSDN 三大技术媒体协办，面向广大开发者的年度征文活动。全年 4 轮，以季度为周期进行优秀文章评比，每年 1 届，以年为单位进行最佳布道师评选。目前，2025 年度 Q1、Q2  技术征文获奖文章已评选出炉。

本篇内容为「OceanBase 布道师计划」优秀文章之一，作者 Leckun 

作为国内规模最大的车联网综合运营服务提供商之一，慧视通科技一直以 SQLServer 和 MySQL 为主要数据底座提供智慧交通、车联网、北斗定位等方向的技术服务。

受制于系统效率低、高可用差等技术痛点，慧视通科技将业务陆续迁移至 OceanBase 数据库，目前已完成 50% 左右的迁移工作，并取得了不错的收益。例如，用一套系统解决 80% 的问题，再例如，在不增加研发成本的情况下用几十行代码简单实现人脸检索功能，此外还在多个业务中实现了降本增效。

本文分享慧视通科技使用 OceanBase 的选型历程与业务应用实践，希望能给同行带来一些参考价值。

慧视通科技是国内规模最大的集研发、生产、销售、服务于一体的大型车联网专业领域综合运营服务提供商之一。公司专注于智能交通领域，以车联网、云计算、AI 大数据处理、无线通信和北斗全球定位技术为核心，针对巡游/网约出租车、物流/两客一危、前装新能源、驾驶培训、汽车租赁、试乘试驾等行业提供符合客户需求的产品和解决方案。

公司在全国建立了三大数据中心，并在 50 多个城市建立了一级、二级平台，目前已有超过数十万台运营车辆在慧视通车联网运营系统平台上线管理，为运营车辆安全运营保驾护航；同时，在全国建立了七大监控服务中心，为客户提供本地化售后维护服务和 7×24 小时优质高效的平台监控服务。

公司以往的核心业务和边缘业务所采用的数据库，主要是以 SQLServer 和 MySQL 为主，采用自研的数据库中间件进行多数据中心分区、同一数据中心分库分表的策略，并且实现了读写分离，主备切换等功能。

虽然经过多年的优化尚能支撑公司业务，但存在冷热数据不均、读写聚合效率较低的问题，在高可用性方面，故障恢复时数据一致性无法有效保障，通常需要人工介入，且无法应对机房级灾难。同时，自研的中间件开发维护成本都非常高，特别是在整体系统架构上，组件间交互错综复杂，而且开发时有一定的代码侵入性。

为应对行业新政策和新业务的发展，决定对主要业务线进行重构，而重构的其中一项就是将复杂的数据库中间件架构替换为成熟的开源分布式数据库方案，以简化业务应用的开发，同时提高系统的可用性。

因此，公司从 2021 年开始着手调研各种分布式数据库，2022 年 OceanBase  4.0 社区版发布时，综合各项功能和性能考虑，最终确认 OceanBase 为数据库最佳选型。其单机分布式一体化、TP/AP 一体化的设计，以及数据的高压缩比等能力，正符合我们对于精简系统组件，减少数据存储空间，降低开发和运维成本的选型初衷。

截至目前，公司至少一半的核心业务已改造并迁移到 OceanBase，其余部分还在继续进行重构改造和适配中，改造后的业务已稳定运行数月，取得了良好的预期效果。

在公司业务的重构过程中，OceanBase 的新能力恰恰给我们优化业务逻辑、精细化业务场景提供绝佳的支撑与契机。目前 OceanBase 社区版已发布到 4.3.5 版本，除了持续打磨完善内核及生态工具能力外，还把适应用户核心业务场景的功能应用到了 OceanBase 社区版中，例如新推出列式存储、向量化引擎 2.0 版本等新技术，志在融合 TP、AP、多模态、AI 等能力，践行“用一套系统解决 80% 的问题”。

场景一：利用 OceanBase 向量稠密匹配改进人脸登签业务流程

我司目前服务和运营的巡游出租车都安装有出租车智能终端设备，驾驶员在营运前，需先进行人脸识别，实现人、证识别一致后才能运营，根据交通部标准和部分地方标准，驾驶员进行人脸识别的实现都是通过智能终端设备进行边缘识别后与平台进行协议交互实现登签业务。

通常出租车在初始落地时已经事先确定好对应的主、副班驾驶员，并且通过后台对驾驶员证件照片和车辆进行绑定后，再下发到对应的智能终端设备供人脸识别。

但是有一种特殊的业务场景，部分出租车企业存在机动司机，即该司机是临时调度、机动分配到不同的出租车上驾驶，但待驾驶的车辆智能终端设备上并没有该司机的人脸信息，目前的解决方式是由出租车公司通知后台监控中心客服人员将司机的姓名、驾驶证号在后台进行绑定后再下发到智能终端设备，流程非常繁琐。

后续改进业务场景，大致有两种方案：

第一种方案，通过智能终端设备让机动司机自行输入驾驶证号，后台再自动进行绑定，但由于各种原因，如一些司机不懂操作、漏输证号数字等导致效果依然不理想。

第二种方案，启用人脸检索自动匹配司机照片，但这种方案需要引入额外的向量数据库如 Milvus 等去实现，运维和开发成本陡增。

而 OceanBase 向量检索能力的补齐，正好解了燃眉之急。

OceanBase 在向量检索方面的优势包括以下几点：

1. OceanBase 在通过向量数据类型（vector）实现向量存储，通过多种类型的向量索引支持了高效的向量检索。在向量查询时，不仅支持按 TOPN 排序的相似度计算，还能够按照标量进行点查。

2. 在应用开发方面，为用户提供了 Python API 和类似于 Milvus SDK 的开发工具包，而且还可以直接复用 MySQL 生态的客户端，对开发十分友好。落实到业务上，我们通过 OceanBase 做到了用几十行代码就能简单地实现人脸检索功能，增加的研发成本基本为0。

3. 在运维方面，不需要引入新的工具和组件, 完全复用现有的运维平台和工具，如 OBD、OCP、obdiag 等。不用学习新的工具，直接复用已有的运维经验即可。

4. 在数据库的其他能力方面，相比于专用的向量数据库 Pinecone / Milvus，以及正在逐步补齐向量检索能力的老牌数据库厂商 Elasticsearch / Redis 等，OceanBase 是一个支持金融级高可用的分布式向量数据库，除了基础的向量检索能力，还支持金融级高可用和容灾、弹性扩缩容、分布式事务，并有着极低的存储成本和优秀的查询分析性能。

5. 在性能上，ANN Benchmarks GIST 960 排名第一。下图的 Vsag 即为 OceanBase 向量化引擎插件，和目前最好的 glass 相比，在 96.7% 召回率的情况下 QPS 能够提升 90% 左右，做到了 SOTA (State of the Art）。并且还会持续依靠蚂蚁集团大量的向量化场景和专业的算法团队，不断进行性能优化。

在我们看来，OceanBase 可以简单理解成是一个复用了金融级分布式数据库内核能力的超级向量数据库。同时，还拥有简单易用的 API 接口和丰富的生态工具体系，大大降低了适配和运维的难度。

OceanBase 向量检索能力-整体架构

以下示例是基于 OceanBase 和 InsightFace 的人脸检索功能，快速上手体验 OceanBase 的人脸向量检索能力：

import osimport cv2import numpy as npfrom pyobvector import *from insightface.app import FaceAnalysis
app = FaceAnalysis("buffalo_sc")   # 使用的检测模型名为buffalo_sc
app.prepare(ctx_id=-1, det_size=(640, 640))  # ctx_id小于0表示用cpu预测，det_size表示resize后的图片分辨率  # 使用Milvus兼容模式连接OceanBaseclient = MilvusLikeClient(uri="数据库连接", user="数据库用户名",password="数据库密码", db_name="数据库名称")
def load_photo(filename):    # 获取当前文件夹路径    current_folder = os.path.join(os.getcwd())    filepath = np.fromfile(os.path.normpath(os.path.join(current_folder, filename)),dtype=np.uint8)    img = cv2.imdecode(filepath, cv2.IMREAD_COLOR)  # 读取图片    faces = app.get(img)   # 得到人脸信息    # 获取embeddings    feature = np.array(faces[0].normed_embedding, dtype=np.float32),    # 使用向量的每个元素除以L2范数进行归一化    feature = feature / np.linalg.norm(feature, axis=1, keepdims=True)    return feature[0]
def search(table_name, target_data):    res = client.search(    collection_name=table_name,    data=target_data,    anns_field="embedding",    limit=1,    with_dist = "true", # 输出距离    output_fields=["name"],    search_params = {"metric_type": "L2"} # 使用L2距离    )    return res[0]
def main():    feature = load_photo("test.png")    res = search("t1", feature)    if(res["l2_distance_1"] < 1): # 通常L2距离<1为匹配成功        print("Match! Name:", res["name"])    else:        print("No Match!")
if __name__ == "__main__":    main()

场景二：Roaring Bitmap 助力报表毫秒级精细化展示

慧视通平台服务的众多类型的车辆，每天都会上传产生超过3亿条数据，而数据中可能会产生各种状态标志、异常事件预警和报警，不同种类的状态和报警类型超过 2000 种，有来自车载传感器的，有来自终端设备的，有来自行为监测等等，每月的数据量在百亿级别。

面对如此海量的数据查询，而客户的查询需求又要多样化，既需要报警的日报、月报、季报，又需要实时看板，在展示状态和报警报表的时候通常需要多个维度，例如以车辆维度、状态或报警类型维度、时间维度等，同时还要多种不同状态或报警条件组合圈选。

目前为了减少数据查询量，我们除了按不同客户拆分 Region 外，还按类型、按天、按月进行数据分区，并且通过实时 ETL 将报警事件时间压缩，由时间点变为时间段，这样处理后每天的报警数据量能降至千万数量级，但每月仍超过十亿级。

在一些跨月时间查询的报表中，通常只能通过 ETL 进行 T+1 预生成，这样虽然能解决大部分查询需求，但是却缺少灵活性难以完全满足客户多样化、精细化的需求，特别在多报警条件组合圈选、大跨度不定时间段的实时查询功能上仍然存在 >5s 甚至 10s+ 的查询延迟。

最近版本的 OceanBase 加入了 Roaring Bitmap（高效压缩位图）数据类型和相关的运算函数，对于上述多维度数据挖掘和分析的需求，Roaring Bitmap 就是把利剑。下面以车辆报警组合分析的例子来演示这一功能。

只需要一句 SQL 即可将原始数据聚合导入为 Roaring Bitmap

insert ignore into t_alarm_veh_bit select alarm_id, rb_build_agg(veh_id), date(gps_time) gps_date from t_veh_alarm group by alarm_id order by alarm_id;

也可以实时更新加入

update t_alarm_veh_bit set veh_bit = rb_or(veh_bit, rb_from_string('1002')) where alarm_id = 1;

通过这样转换后，就可以实时组合圈选查询，例如要查询 12 月 21 日至 12 月 22 日超速报警、急减速报警、车道偏离报警的所有车辆和数量统计。

select alarm_id, b.alarm alarm_name, rb_to_string(veh_bit) veh_id_bits ,rb_cardinality(veh_bit) total, gps_date from t_alarm_veh_bit aleft join t_alarm_type b on a.alarm_id = b.id where alarm_id in (1,3,4) and gps_date between '2024-12-21'and'2024-12-22';

查询结果变为横向的 车辆 id 列表

通过 OceanBase 的向量检索能力对业务场景改造后，我司客户无需再提前通知客服进行机动司机绑定，机动司机不再临时驾驶时，也不需要删除相关绑定，同时也不再需要在对象存储提取司机信息，也不需要通过平台下发照片，大大减低了整体业务延迟，实际使用效果非常给力。

在无需引入额外的数据库情况下，就能使整个业务逻辑完美流畅闭环，无需任何人工介入，大大节约了沟通、人力和运维成本。

而在原来的报警报表中，经过实时预计算整合后的报警数据，依然要从每月超过 10 亿的整合数据表中进行ETL，且需要 T+1 才能生成最终结果，在预计算和 ETL 过程中，都需要占用大量 CPU、内存和存储空间，且报表的查询结果并不及时。

而随着 OceanBase 中 Roaring Bitmap 的加入，使我们的报警报表的处理逻辑进一步优化，变为以每天的报警 id 为主键，内容为车辆 id 的 bits 列表的结构，数据量骤降为每天只有 2000 多条，一个月只有 6 万条的小表，实现报警报表的实时查询，同时还兼顾任意时间和任意报警组合圈选查询，查询以毫秒级返回，无论从查询效果还是存储空间，相比原来都提升了多个数量级。

上述使用 OceanBase 新能力对业务精细化的改造，我们都只用到了 OceanBase 一套数据库，在节约运维人力成本、提高查询效率、减少存储空间、降低技术栈复杂度方面均表现优秀，完美体现了“用一套系统解决 80% 的问题”的理念。

OceanBase 在日常版本迭代中，不断优化性能、提升易用性外，还进一步强化多模一体化能力，除了上述向量、Roaring Bitmap 外，还包括对 KV 、GIS、列存等支持。

对于一些轻量的业务应用，一个 OceanBase 数据库就代替多套数据库的组合，简化了整个系统的架构和应用技术栈，整体降低了开发和运维成本，真正“为用户提供一个面向未来的数据发动机”。

想了解更多干货，可通过下方扫码关注

可扫码添加上智启元官方客服微信👇