arangodb truncate 在大型集合上失败

Question

如果我尝试截断约 4000 万个文档的大型集合，我会在 arangosh 中超时，并且 arangodb 服务会无响应。留言:

arangosh [database_xxx]> db.[collection_yyy].truncate() ; JavaScript exception in file '/usr/share/arangodb/js/client/modules/org/arangodb/arangosh.js' at 104,13: [ArangoError 2001: Error reading from: 'tcp://127.0.0.1:8529' 'timeout during read'] !
  throw new ArangoError(requestResult); !  ^ stacktrace: Error
    at Object.exports.checkRequestResult (/usr/share/arangodb/js/client/modules/org/arangodb/arangosh.js:104:13)
    at ArangoCollection.truncate (/usr/share/arangodb/js/client/modules/org/arangodb/arango-collection.js:468:12)
    at <shell command>:1:11

ArangoDB 2.6.9，Debian Jessie，AWS ec2 m4.xlarge，16G RAM，SSD。该服务变得无响应。我怀疑它卡住了(不仅仅是忙)，因为直到我停止后它才工作，删除/var/lib/arangodb/databases/中的数据库，然后重新开始。

我知道我可能会因为尺寸而倾向于性能极限，但我猜想无论尺寸如何都不会失败。

然而，在非云 Windows 10、16GB RAM、SSD 上，同样的操作在一段时间后成功了。

这是一个错误吗？如果有帮助，我有一些 python 代码可以将虚拟数据加载到集合中。如果我要提供更多信息，请告诉我。摆弄 --server.request-timeout 会有帮助吗？

Answer 1

为 ArangoShell 增加 --server.request-timeout 只会增加 shell 在关闭空闲连接之前使用的超时时间。arangod 服务器还将关闭挥之不去的保持事件连接，这可能会更早发生。这是通过服务器的 --server.keep-alive-timeout 设置来控制的。

但是，同时增加两者并没有多大帮助。实际问题似乎是 truncate() 操作本身。是的，它可能非常昂贵。 truncate() 是一个事务性操作，因此它将为它删除的每个文档写入一个删除标记到服务器的预写日志中。它还会在内存中缓冲每个删除操作，以便在失败时回滚操作。

一个比 truncate() 侵入性小得多的操作是删除集合并重新创建它。这应该非常快。但是，如果集合的索引和特殊设置在删除之前存在，则需要手动重新创建/恢复它们。

对于文档集合，可以这样实现:

function dropAndRecreateCollection (collectionName) {
  // save state
  var c          = db._collection(collectionName);
  var properties = c.properties();
  var type       = c.type();
  var indexes    = c.getIndexes();

  // drop existing collection
  db._drop(collectionName);

  // restore collection
  var i;
  if (type == 2) {
      // document collection
      c = db._create(collectionName, properties);
      i = 1;
  }
  else {
      // edge collection
      c = db._createEdgeCollection(collectionName, properties);
      i = 2;
  }

  // restore indexes
  for (; i < indexes.length; ++i) {
      c.ensureIndex(indexes[i]);
  }
}