TL;博士
至少在我的台式机(Windows 10、Intel 6700K 4x4.0GHz、32GB RAM、Evo 850 SSD)上,对记录进行重复数据删除并将它们写入另一个集合(少于 60 秒)不需要那么长时间。
但是,某些查询需要适当的索引,否则它们将永远存在。索引需要一些内存,但与查询执行期间对记录进行分组所需的内存相比,它可以忽略不计。如果内存不足,性能会受到影响,因为操作系统需要在内存和大容量存储之间交换数据。这对于旋转磁盘来说尤其是一个问题,而对于快速闪存设备来说则不然。
准备
我生成了 220 万条记录,其中包含 5-20 个随机属性和每个属性 160 个乱码字符。此外,每条记录都有一个属性myid
。187k 条记录有唯一 id,60kmyid
存在两次,70k 存在 3 次。集合大小报告为 4.83GB:
// 1..2000000: 300s
// 1..130000: 20s
// 1..70000: 10s
FOR i IN 1..2000000
LET randomAttributes = MERGE(
FOR j IN 1..FLOOR(RAND() * 15) + 5
RETURN { [CONCAT("attr", j)]: RANDOM_TOKEN(160) }
)
INSERT MERGE(randomAttributes, {myid: i}) INTO test1
启动 ArangoDB 前的内存消耗为 3.4GB,启动后为 4.0GB,加载test1
源集合后约为 8.8GB。
基线
在我的系统上读取test1
和插入所有文档(2.2m)test2
需要 20 秒,内存峰值约为 17.6GB:
FOR doc IN test1
INSERT doc INTO test2
不写分组myid
大约花了。9s 对我来说,在查询期间有 9GB RAM 峰值:
LET result = (
FOR doc IN test1
COLLECT myid = doc.myid
RETURN 1
)
RETURN LENGTH(result)
分组失败
COLLECT docId = doc.myId, doc2 = doc
我在只有 3 条记录和 1 条重复的数据集上尝试了您的方法myid
。它表明查询实际上并没有分组/删除重复项。因此,我试图找到替代查询。
与 INTO 分组
可以使用将重复myid
的 s 组合在一起但保留访问完整文档的可能性COLLECT ... INTO
。我只是选择了每个组的第一个文档来删除多余myid
的 s。该查询花了大约 40 秒时间将 2m 条具有唯一myid
属性的记录写入test2
. 我没有准确测量内存消耗,但我看到了跨越 14GB 到 21GB 的不同内存峰值。也许截断测试集合并重新运行查询会增加所需的内存,因为一些过时的条目会以某种方式阻碍(压缩/密钥生成)?
FOR doc IN test1
COLLECT myid = doc.myid INTO groups
INSERT groups[0].doc INTO test2
用子查询分组
以下查询显示更稳定的内存消耗,峰值为 13.4GB:
FOR doc IN test1
COLLECT myid = doc.myid
LET doc2 = (
FOR doc3 IN test1
FILTER doc3.myid == myid
LIMIT 1
RETURN doc3
)
INSERT doc2[0] INTO test2
但是请注意,它需要一个哈希索引来实现约 38 秒的查询执行时间myid
。test1
否则,子查询将导致数百万次集合扫描并需要很长时间。
用 INTO 和 KEEP 分组
_id
我们可以只将 分配给一个变量,而不是存储属于一个组的整个文档,KEEP
这样我们就可以使用以下命令查找文档正文DOCUMENT()
:
FOR doc IN test1
LET d = doc._id
COLLECT myid = doc.myid INTO groups KEEP d
INSERT DOCUMENT(groups[0].d) INTO test2
内存使用:加载源集合后 8.1GB,查询期间峰值为 13.5GB。2m条记录只用了30秒!
使用 INTO 和投影进行分组
出于好奇,我还尝试了一个投影,而不是 KEEP:
FOR doc IN test1
COLLECT myid = doc.myid INTO groups = doc._id
INSERT DOCUMENT(groups[0]) INTO test2
加载后 RAM 为 8.3GB test1
,峰值为 17.8GB(在查询执行期间实际上有两个严重的峰值,均超过 17GB)。完成 200 万条记录需要 35 秒。
上插
我用 UPSERT 尝试了一些东西,但看到了一些奇怪的结果。事实证明,这是 ArangoDB 的 upsert 实施中的一个疏忽。v3.0.2包含一个修复程序,我现在得到正确的结果:
FOR doc IN test1
UPSERT {myid: doc.myid}
INSERT doc
UPDATE {} IN test2
myid
在in上处理(唯一)哈希索引需要 40test2
秒,RAM 峰值约为 13.2GB。
就地删除重复项
我首先将所有文档从test1
到test2
(2.2m 记录)复制,然后我尝试REMOVE
只复制以下内容test2
:
FOR doc IN test2
COLLECT myid = doc.myid INTO keys = doc._key
LET allButFirst = SLICE(keys, 1) // or SHIFT(keys)
FOR k IN allButFirst
REMOVE k IN test2
内存为 8.2GB(仅test2
加载),在查询期间达到 13.5GB。删除重复项(200k)大约需要16 秒。
确认
以下查询组合myid
在一起并汇总每个 id 出现的频率。对目标集合运行test2
,结果应该是{"1": 2000000}
,否则仍有重复。我仔细检查了上面的查询结果并检查了所有内容。
FOR doc IN test2
COLLECT myid = doc.myid WITH COUNT INTO count
COLLECT c = count WITH COUNT INTO cc
RETURN {[c]: cc}
结论
ArangoDB v3.0 的性能似乎是合理的,但如果没有足够的 RAM 可用,它可能会降低。不同的查询大致在同一时间内完成,但显示出不同的 RAM 使用特性。对于某些查询,索引是必要的以避免高计算复杂性(这里:完整的集合扫描;在最坏的情况下读取 2,200,000,000,000 次?)。
您能否在您的数据上尝试我提出的解决方案并检查您机器上的性能?