arangodb truncate 在大型集合上失败
arangodb truncate fails on large a collection
如果我尝试截断大约 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 内存、SSD。
该服务变得无响应。我怀疑它卡住了(不仅仅是忙),因为直到我停止后它才起作用,删除 /var/lib/arangodb/databases/ 中的数据库,然后重新开始。
我知道我可能会因为尺寸的原因而倾向于性能极限,但我猜想无论尺寸如何都不会失败。
但是在非云上 Windows 10、16GB RAM、SSD 同样的操作成功了 - 过了一会儿。
这是一个错误吗?如果有帮助,我有一些 python 代码可以将虚拟数据加载到集合中。如果我要提供更多信息,请告诉我。
使用 --server.request-timeout
对 fiddle 有帮助吗?
增加 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]);
}
}
如果我尝试截断大约 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 内存、SSD。
该服务变得无响应。我怀疑它卡住了(不仅仅是忙),因为直到我停止后它才起作用,删除 /var/lib/arangodb/databases/ 中的数据库,然后重新开始。
我知道我可能会因为尺寸的原因而倾向于性能极限,但我猜想无论尺寸如何都不会失败。
但是在非云上 Windows 10、16GB RAM、SSD 同样的操作成功了 - 过了一会儿。
这是一个错误吗?如果有帮助,我有一些 python 代码可以将虚拟数据加载到集合中。如果我要提供更多信息,请告诉我。
使用 --server.request-timeout
对 fiddle 有帮助吗?
增加 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]);
}
}