3

Orient 版本：官方分发 OrientDB Graph Edition 1.0.1

我正在尝试使用 OrientDB SQL 插入构建蓝图兼容图（比 g.addVertex 快并且没有 OutOfMemory 错误）。

创建 150 万条记录时，通过控制台（批处理）插入的时间比预期的要长（四核 i7 上为 13 分钟），并且通过“名称”字段搜索非常慢（2 分钟）。

出于测试目的，我们有一个非常简单的导入 sql 文件，它尝试创建与两个设置参数 name:account_id 和 type:account_type 以及空输入/输出数组兼容的蓝图顶点。

进口.ornt：

connect local:/graph1/databases/dbdemo admin admin;
drop database;
create database local:/graph1/databases/dbdemo admin admin local graph;
insert into V (name,type,in,out) values ("1111111","player",[],[]);
...
disconnect;

注意：最好能够将记录标识符设置为我们预先存在的 account_id。但我不确定如何尝试这个。

上面的 sql 最终约为 100MB，我通过控制台运行它（console.sh 包括优化-Dmvrbtree.optimizeThreshold=-1）：

:$ ./console.sh import.ornt 
OrientDB console v.1.0.1 (build @BUILD@) www.orientechnologies.com
Type 'help' to display all the commands supported.

Installing extensions for GREMLIN language v.2.0.0-SNAPSHOT
Connecting to database [local:/graph1/databases/dbdemo] with user 'admin'...OK

Database 'dbdemo' deleted successfully
Creating database [local:/graph1/databases/dbdemo] using the storage type [local]...
Database created successfully.

Current database is: local:/graph1/databases/dbdemo

Inserted record 'V#6:0{name:11111111,type:player,in:[0],out:[0]} v0' in 0.002000 sec(s).
...
Disconnecting from the database [dbdemo]...OK

在这一点上，我们有了基本的 OrientDB 图形，其中 OGraphVertex 类大约有 150 万个顶点。

orientdb> classes 

CLASSES:
----------------------------------------------+---------------------+-----------+
 NAME                                         | CLUSTERS            | RECORDS   |
----------------------------------------------+---------------------+-----------+
 ORIDs                                        | 5                   |         0 |
 OGraphEdge                                   | 7                   |         0 |
 OUser                                        | 4                   |         3 |
 ORole                                        | 3                   |         3 |
 OGraphVertex                                 | 6                   |   1524528 |
----------------------------------------------+---------------------+-----------+
 TOTAL                                                                  1524534 |
--------------------------------------------------------------------------------+

使用控制台，通过 Orient SQL 或 Gremlin/Pipes 进行选择需要很长时间：

orientdb> gremlin g.V.has('name','1149400');                      

v[#6:617363]

Script executed in 129.809006 sec(s).
> select from OGraphVertex where name like '1149400';

---+---------+--------------------+--------------------+--------------------+--------------------
  #| RID     |name                |type                |in                  |out                 
---+---------+--------------------+--------------------+--------------------+--------------------
  0|#6:617363|1149400             |player              |[0]                 |[0]                 
---+---------+--------------------+--------------------+--------------------+--------------------

1 item(s) found. Query executed in 112.531 sec(s).

orientdb>

使用 OrientDB SQL 或 Gremlin 大约需要 2 分钟！

作为一种潜在的解决方法，最好将记录标识符设置为来自 MySQL 数据库源的原始帐户 ID。是否可以有自定义记录 ID？

例如，由于我们会在开始遍历时知道 account_id（例如 1149400），所以理想的情况是：

orientdb> gremlin g.v('#6:1149400').map

{name=1149400, type=player}

Script executed in 0.054000 sec(s).

0.054000 比 112.531 快很多！！

4

1 回答 1

3

OrientDB RecordId 无法更改，但您可以针对 V.name 属性创建索引。例子：

创建索引 OGraphVertex.name 非唯一

甚至：

CREATE INDEX V_name ON OGraphVertex (name) notunique;

有关更多信息，请查看：OrientDB 索引

于 2012-06-06T22:12:02.067 回答