gpt4 book ai didi

kdb - 我在分区表中的符号列文件大小异常大——为什么会这样?

转载 作者:行者123 更新时间:2023-12-05 01:04:35 27 4
gpt4 key购买 nike

我刚刚构建了我的第一个正确的 q/kdb+ 数据库,其中包含展开和分区表。一切都很好,但我只是注意到我的符号 s 列文件大小异常大。这是我从操作系统和 q 内部可以看到的:

# ls -latr 2017.10.30/ngbarx
total 532
-rw-r--r-- 1 root root 24992 Apr 17 20:53 vunadj
-rw-r--r-- 1 root root 24992 Apr 17 20:53 v
-rw-r--r-- 1 root root 300664 Apr 17 20:53 s
...

q)meta ngbarx
c | t f a
------| -----
date | d
s | s p
v | e
vunadj| e
...

q)get `:2017.10.30/ngbarx/s
`p#`sym$`A`AA`AACG`AADI`AADR`AAIC`AAIC-B`AAL`AAM-A`AAMC`AAME`AAOI`AAON`AAP`AA..

q)-22!get `:2017.10.30/ngbarx/v
24990
q)-22!get `:2017.10.30/ngbarx/s
28678
q)all (get `:2017.10.30/ngbarx/s) in sym
1b
q)count sym
62136

所以比较实类型 v 列和符号类型 s 列,我从 ls 看到符号列的大小超过 10 倍,即使以字节为单位的内部大小相似,并且所有内容似乎都在 sym 文件中正确编码。

这是预期的行为吗?还是我做错了什么可以修复?

UPDATE:我没用压缩,用神奇的函数.Q.dcfgnt写文件,可以查看here .好吧,一个稍微修改的版本,我注意到这个函数在目录中也保存了一个 date 文件,即使列应该是虚拟的,所以我在 k (我不是很擅长)并将内部函数 .Q.dpfgnt 更新为此 ...

k){[d;p;f;g;n;t]if[~&/qm'r:+en[d]t;'`unmappable];
{[d;g;t;i;x]@[d;x;g;t[x]i]}[d:par[d;p;n];g;r;<r f]'{x@&~x=`date}(!r);
@[;f;`p#]@[d;`.d;:;f,r@&~f=r:{x@&~x=`date}(!r)];n}

最佳答案

应用 parted 属性不是免费的,需要存储。它通常不会那么昂贵,但是查看 s 的示例输出,它看起来不适合分开,因为它不包含重复值:

q)get `:2017.10.30/ngbarx/s
`p#`sym$`A`AA`AACG`AADI`AADR`AAIC`AAIC-B`AAL`AAM-A`AAMC`AAME`AAOI`AAON`AAP`AA..

请参阅下面为说明问题而创建的表格:

/ no part - 16 distinct syms
t1:([]s:100000?`1;v:100000?2e)

/ part - 16 distinct syms
t2:update `p#s from `s xasc ([]s:100000?`1;v:100000?2e)

/ no part - 99999 distinct syms
t3:([]s:100000?`8;v:100000?2e)

/ part - 99999 distinct syms
t4:update `p#s from `s xasc ([]s:100000?`8;v:100000?2e)

t1 和 t2 之间的大小差异与 parted 属性(804096 -> 804664)无关。但是,当不同的 syms/parts 的数量变得非常大时,存储成本就非常大。 (804096 -> 4749872)

ls | xargs ls -latr
t1:
total 1180
-rw-r--r-- 1 matmoore matmoore 12 Apr 19 10:28 .d
-rw-r--r-- 1 matmoore matmoore 804096 Apr 19 10:28 s
-rw-r--r-- 1 matmoore matmoore 400016 Apr 19 10:28 v
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 .
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 ..

t2:
total 1180
-rw-r--r-- 1 matmoore matmoore 12 Apr 19 10:28 .d
-rw-r--r-- 1 matmoore matmoore 804664 Apr 19 10:28 s
-rw-r--r-- 1 matmoore matmoore 400016 Apr 19 10:28 v
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 .
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 ..

t3:
total 1180
-rw-r--r-- 1 matmoore matmoore 12 Apr 19 10:28 .d
-rw-r--r-- 1 matmoore matmoore 804096 Apr 19 10:28 s
-rw-r--r-- 1 matmoore matmoore 400016 Apr 19 10:28 v
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 .
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 ..

t4:
total 5032
-rw-r--r-- 1 matmoore matmoore 12 Apr 19 10:28 .d
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 ..
-rw-r--r-- 1 matmoore matmoore 4749872 Apr 19 10:28 s
-rw-r--r-- 1 matmoore matmoore 400016 Apr 19 10:28 v
drwxr-xr-x 1 matmoore matmoore 4096 Apr 19 10:28 .

我还想问这个专栏是否应该是一个符号。如果 62k 是仅创建一个日期的 sym 文件的大小,那么您应该小心您最终会创建一个臃肿的 sym 文件。如果您有 2017.10.30 的完整历史记录并且 sym 文件仍然是 62k,那没关系,但如果您每天添加那么多新符号,sym 文件将很快失控。

关于kdb - 我在分区表中的符号列文件大小异常大——为什么会这样?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/71905663/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com