Я действительно не могу понять, где моя проблема. Im using Titan 0.5.0 (Это та же проблема с новыми версиями Titan ...)Titan BatchLoading berkeleydb не стойкий
Я хочу загрузить кучу вершин и ребер из файла csv с записями 100 тыс. (Каждая строка приводит к по меньшей мере 3 узлы и некоторые ребра) в мой граф. Это займет около 5 минут, чтобы, наконец, завершить импорт.
Так что я пробовал то же самое с конфигурацией storage.batch-loading = true.
Ну, это значительно быстрее всего за 2 минуты, чтобы завершить импорт.
Но проблема в том, что если im включит опцию storage.batch-loading = true
, узлы и ребра не сохраняются постоянными в базе данных. Поэтому, если я закрываю Gremlin и снова открываю свой график, он пуст.
Он работает как шарм с storage.batch-loading
установленным на false. Это занимает больше времени, но записи сохраняются постоянными.
Да, я беру на себя Batchgraph после импорта, а также сам график. Я что-то упустил?
В этом примере я хочу импортировать только около 30 тыс. Узлов для тестирования, но они также не сохраняются постоянными. Конфигурация:
storage.backend=berkeleyje
storage.directory=graph
storage.batch-loading = true
query.fast-property = true
Gremlin Сценарий:
g = TitanFactory.open("../graphs/batchImportTest2/batchImportTest2.properties")
//1 Prepare Graph for import
m = g.getManagementSystem();
username = m.makePropertyKey('username').dataType(String.class).make()
m.buildIndex('byUsername',Vertex.class).addKey(username).unique().buildCompositeIndex()
email = m.makePropertyKey('email').dataType(String.class).make()
m.buildIndex('byEmail',Vertex.class).addKey(email).unique().buildCompositeIndex()
m.commit()
g.commit()
//2 Import Nodes and Edges
bg = new BatchGraph(g, VertexIDType.STRING, 50000)
new File("userInfo_js.txt").eachLine({ final String line ->def (username,email) = line.split('\t')*.trim();def userVertex = bg.getVertex(username) ?: bg.addVertex(username); userVertex.setProperty("username", username);userVertex.setProperty("email", email)})
bg.commit()
g.commit()
Здравствуйте Daniel, спасибо за ваше время и ответ. Ну, если я делаю это точно так же, как вы (user.txt с 11 пользователями ...), это удивительно работает и для меня. единственные различия, которые я мог заметить, это то, что youre использует linux и im, используя окна. и что у вас был «g.shutdown()» в конце. НО. маленький файл пользователя с только адресом электронной почты и именем пользователя был предназначен только для тестирования batchimport. У меня есть большой файл с 100 тыс. Записей, а также множество узлов, атрибутов и ребер, создаваемых во время пакетной обработки. И там он все еще не работает, также не с «g.shutdown()» в конце. ... –
... Но я могу заметить, что с небольшим пользовательским файлом и «g.shutdown()» в конце, график закрывается «exit». Если я пытаюсь выполнить ту же процедуру с моим большим файлом, график не закрывается с «exit». Он остается в состоянии, где вы ничего не можете набрать, линия гремлина ушла в начале, но не закрывает окно. Это должно быть так? Или это связано с моей проблемой? Большое спасибо за вашу помощь! –
'g.shutdown()' было сделано автоматически в более старых версиях, затем оно было удалено, и я думаю, что оно вернулось в более новые версии (0.9+). Итак, да, то, что вы видите, ожидаемо, так как оболочка ждет некоторых фоновых потоков, которые никогда не заканчиваются без явного 'g.shutdown()', что, в свою очередь, приводит к некоторым странным эффектам, когда вы вынуждаете оболочку закрываться используя CTRL + C. –