其次，我们输出了在 OnlineFS 服务中处理特征向量所需的时间。 这个时间不包括一条记录在 Kafka 中等待处理的时间，原因是等待时间在很大程度上取决于写入 Kafka 的 Spark 执行程序的数量。 相反您应该依靠吞吐量数字将它们与您的要求进行比较。
处理时间是按行报告的，但 OnlineFS 中的部分管道是并行化的，例如，行以 1000 的批次提交给 RonDB。通过这种设置，我们实现了 11 个特征的 p99 约为 250 毫秒，行大小为 948 字节。
我们对与越来越多的并行执行请求的客户端相关的不同特征向量大小的吞吐量和延迟进行了基准测试。 请注意，客户端被分成两个工作节点（每个 8vCPU）。
每个请求的单个向量
在这个基准测试中，每个请求都包含一个主键值查找（一个特征向量）。 吞吐量和延迟可线性扩展至 16 个客户端，同时保持低延迟。 对于超过 16 个客户端，我们观察到运行客户端的主机达到其最大 CPU 和网络利用率。 此外，我们没有看到 RonDB 数据节点或 MySQL 服务器的过度使用，这意味着我们可以通过从更大的工作实例运行客户端或添加更多工作主机来运行客户端来进一步线性扩展。
批处理，每个请求 100 个向量
为了证明 RonDB 每秒可扩展到更多的关键查找，我们运行了另一个基准测试，其中每个客户端以 100 个批次请求特征向量。正如我们所看到的查找数量仍然线性扩展，查找吞吐量增加了 15 倍，而 每个请求的延迟仅适度增加。
Hopsworks 附带托管 RonDB，为 Hopsworks 和在线特征提供统一的元数据存储。 在这篇博客中，我们展示了一个高度可用的双节点 RonDB 集群（r5.2xlarge VM）线性扩展到 >250k ops/sec，特征向量查找的 11 个特征的大小约为 1KB，p99 延迟为 7.5 毫秒。 因此Hopsworks 提供了当今市场上性能最高的在线特征库。