具有排序属性的 KDB table 上的插入操作复杂度
Insertion operation complexity on KDB table with sorted attribute
假设有一个 KDB table，其中包含 A、B 和 C 列，并且它按 A 列排序。
我想了解向 table 插入记录的复杂性（假设它必须保持 table 在 A 上排序）。
- 如果保证对这个 table 的插入按 A 的排序顺序进行（就复杂性而言）是否有帮助。这意味着在任何时间 t2>t1，A(t2)>A (t1) ?
- 有没有一种方法可以利用上述事实 (t2>t1 => A(t2)>A(t1)) 并优化查询，甚至无需对 A 应用排序属性？
- 我知道有一种方法可以对列执行二分搜索，但我主要想知道是否有一种方法可以告诉查询规划器“假设”列已排序（实际上没有sorted 属性，因为我想避免与之相关的插入复杂性）并相应地执行查询？
我的想法（其中一些只是意见，因为我们无法确切地看到 kdb 在幕后做了什么）：
一个。澄清一下——kdb 本身并不“保持 table 排序”。不管怎样，Kdb 都会插入数据，由用户来确保 table 保持排序。
乙。我不认为你应该担心 kdb 插入中的 overhead/complexity - 我估计 insert 是所有 kdb
中最优化的操作之一
C.无论该列是否具有属性，kdb 都会以任何一种方式进行插入，并且可能仅在插入后检查该属性是否被保留。这将是一个高度优化的检查。 s# 将在未排序的插入上丢失。 u# 将在非唯一插入中丢失。 p# 将在任何插入中丢失，因为它通常用于 static/on-disk 数据。
D.插入不可忽略的 cost/complexity 的唯一情况是在维护分组属性的情况下，因为 g# 始终保留在插入时并且存在更新隐藏哈希的开销 table。但即便如此，这种开销也不会影响在给定的一天有数十亿次插入的大容量 RDB。
None 其中是实际的硬数字或大 O/complexity 信息，但根据我的经验，大 O/complexity 与 lookup[=47= 更相关] 的属性数据，而不是 attribute/data 的 insert/maintenance。根据我的经验，插入从来都不是问题。
回答您的实际问题：
正如我在 (A) 中所避免的那样，如果您想拥有一个已排序的属性并且想要保留它，那么您必须确保数据按排序顺序插入
如果没有属性，则 kdb 将 column/vector 视为任何其他向量 - 它每次都会扫描整个向量，因为没有 flag/attribute 告诉它使用一个优化。唯一的例外是 as-of 连接（或 window 连接）aj/wj，其中 aj on say `sym`time 假定时间在 sym 中排序，而没有时间上的显式 s# 属性。
除了上面的 aj/wj 例外，如果你想利用数据的排序特性来加速查询，那么你需要有一个 s#它的属性。当然，除非您使用不同的属性，例如 p#，正如我之前提到的，它有自己的警告
假设有一个 KDB table，其中包含 A、B 和 C 列，并且它按 A 列排序。 我想了解向 table 插入记录的复杂性（假设它必须保持 table 在 A 上排序）。
- 如果保证对这个 table 的插入按 A 的排序顺序进行（就复杂性而言）是否有帮助。这意味着在任何时间 t2>t1，A(t2)>A (t1) ?
- 有没有一种方法可以利用上述事实 (t2>t1 => A(t2)>A(t1)) 并优化查询，甚至无需对 A 应用排序属性？
- 我知道有一种方法可以对列执行二分搜索，但我主要想知道是否有一种方法可以告诉查询规划器“假设”列已排序（实际上没有sorted 属性，因为我想避免与之相关的插入复杂性）并相应地执行查询？
我的想法（其中一些只是意见，因为我们无法确切地看到 kdb 在幕后做了什么）：
一个。澄清一下——kdb 本身并不“保持 table 排序”。不管怎样，Kdb 都会插入数据，由用户来确保 table 保持排序。
乙。我不认为你应该担心 kdb 插入中的 overhead/complexity - 我估计 insert 是所有 kdb
C.无论该列是否具有属性，kdb 都会以任何一种方式进行插入，并且可能仅在插入后检查该属性是否被保留。这将是一个高度优化的检查。 s# 将在未排序的插入上丢失。 u# 将在非唯一插入中丢失。 p# 将在任何插入中丢失，因为它通常用于 static/on-disk 数据。
D.插入不可忽略的 cost/complexity 的唯一情况是在维护分组属性的情况下，因为 g# 始终保留在插入时并且存在更新隐藏哈希的开销 table。但即便如此，这种开销也不会影响在给定的一天有数十亿次插入的大容量 RDB。
None 其中是实际的硬数字或大 O/complexity 信息，但根据我的经验，大 O/complexity 与 lookup[=47= 更相关] 的属性数据，而不是 attribute/data 的 insert/maintenance。根据我的经验，插入从来都不是问题。
回答您的实际问题：
正如我在 (A) 中所避免的那样，如果您想拥有一个已排序的属性并且想要保留它，那么您必须确保数据按排序顺序插入
如果没有属性，则 kdb 将 column/vector 视为任何其他向量 - 它每次都会扫描整个向量，因为没有 flag/attribute 告诉它使用一个优化。唯一的例外是 as-of 连接（或 window 连接）
aj/wj，其中ajon say`sym`time假定时间在 sym 中排序，而没有时间上的显式s#属性。除了上面的
aj/wj例外，如果你想利用数据的排序特性来加速查询，那么你需要有一个s#它的属性。当然，除非您使用不同的属性，例如p#，正如我之前提到的，它有自己的警告