【发布时间】：2015-04-03 08:05:35
【问题描述】：
我在当前的 32 位 kdb+/tick 设置中有一些内存限制，其中我的 rdb 消耗最多。
我知道我可以通过在 q 进程初始化时使用带有 -s 标签的多个线程来绕过 4 GB 32 位可寻址性限制，但我不确定如何将其应用于 rdb，其中唯一的函数生成数据为upd:insert。
是否可以手动从其他线程分配内存？
【问题讨论】：
【发布时间】：2015-04-03 08:05:35
【问题描述】：
据我所知，您不能只使用线程作为额外的内存来源来存储 RDB 数据。 （他们确实有自己的堆，但工作都在掩护下，没有暴露到足以让你劫持他们）。线程设计用于并行处理只读数据的函数/查询。
一些想法：
1) 您可以创建一个体系结构，其中您有多个 RDB，每个 RDB 都订阅表的子集：
RDB1 - 订阅 table1
RDB2 - 订阅table2、table3
RDB3 - 订阅 table4
然后您创建一个连接到每个 RDB 的网关进程。网关应该确定您尝试查询哪个表并将查询路由到相关的 RDB。
2) 如果单个表（例如报价表）仍然太大而无法存储在单个 4gb 进程中，那么您可能需要考虑按股票代码拆分该表（即 RDB1a 为股票代码 AM 订阅报价表，而 RDB1b订阅股票代码新西兰的报价表）。然后，您的网关必须足够聪明，才能知道正在请求哪些代码并相应地路由查询。
3) 如果实际上不需要始终在 RDB 中保存一整天的数据（即您只是在一天结束时真正使用 RDB 将数据保存到磁盘），那么您应该考虑使用alt-RDB 定期保存到磁盘并在任何给定时间在内存中保留少量数据 (http://code.kx.com/q/cookbook/w-q/)
4) 如果您认真考虑始终将所有数据存储在内存中，并且您正在收集完整的交易/报价数据，那么实现这一目标的唯一干净方法是使用生产许可证。
【讨论】：
-
非常好的想法，我也是这么想的。感谢您的想法
-
我也应该在上面提到 - 对于上面的建议 2)，您必须小心日终保存，因为 RDB1a 和 RDB1b 可能都试图保存到同一个表同时进行相同的分区（假设日期分区）。您必须以某种方式确保他们不会同时进行储蓄。更安全的方法是禁用这些 rdb 的日终保存，这样它们就不会相互绊倒并运行 alt-RDB（订阅整个表）来一点一点地进行保存