我们目前在tickerplant架构的历史数据库（HDB）组件中面临着查询响应时间的严重延迟。请允许我提供一些背景信息，以更好地理解我们的设置和我们遇到的挑战。
我们的架构围绕两个核心表：订单表，存储所有用户的订单历史记录；实时数据库 (RDB)，对 HDB 执行日终减记。作为交易所，我们始终查询 RDB 和 HDB 以检索特定用户的所有历史数据，可追溯到他们最初加入交易所。
问题在于与从 HDB 访问数据特别相关的查询性能。虽然查询 RDB 可以产生令人满意的响应时间，但事实证明查询 HDB 非常耗时。造成这种情况的潜在原因之一可能是 HDB 当前采用的分区策略。
目前，HDB 是按日期分区的，这意味着检索用户订单历史记录需要多次磁盘操作才能找到相关数据。我们典型的订单查询类似于 SELECT row FROM Orders WHERE order_uuid =
我们正在考虑的一种可能的解决方案是按用户而不是日期对 HDB 进行分区。这一调整将简化查询过程，因为 HDB 只需执行单个磁盘操作即可检索用户的整个订单历史记录，从而显着缩短查询响应时间。然而，这种方法有其缺点，特别是对于交易非常频繁的用户而言。随着时间的推移，此类用户的表可能会变得过大，可能导致性能下降和存储问题。
鉴于这种情况，我们正在寻求见解和替代方法来优化 HDB 的查询性能，同时平衡查询效率和存储管理等考虑因素。任何建议或建议将不胜感激。
预先感谢您的协助。
从根本上来说，在这种设置下，您无法减少搜索空间。
我会考虑两阶段查询。首先，存储每个订单 ID 的开始/结束日期，可能存储在展开表中。给定用户字段和 GUID，并在用户上应用 `p# 来快速缩小范围，这应该可以轻松扩展到几亿个订单或更好。
然后，这会告诉您查询获取订单详细信息所需的确切日期范围。同样，如果您在 sym 或 user 上有 `p#，它会有所帮助。