OrientDBでクエリを実行すると、GCオーバーヘッドの上限を超えました

Question

データベースには200,000のドキュメントがあり、600万のドキュメントを持つプロパティにリンクしています。クエリを実行すると、クエリによっては、GCオーバーヘッドの上限を超えたエラーが表示されます。

私のコンピュータには16GBのRAMがあり、私はOrientDB（-Dstorage.diskCache.bufferSize = 8192）に8GBを与え、-Xms1024 -Xmx2048を付けます。そして私は他のオプション、-Xms128 -Xmx4096、およびその他のオプションを試しました。

誰かがそれを修正する方法を手伝ってもらえますか？または、この量のデータを処理するのに十分なOrientDBはありませんか？

私のデータは、このようなものである：、各部分が4つのプロパティを持つクラスlineorderの複数lineorderを持って

{"@type":"d","@class":"part","p_partkey": 2, "lineorder": [{"@type":"d","@class":"lineorder","customer": [{"@type":"d","@class":"customer","c_city": "INDONESIA1"}], "lo_supplycost": 54120, "orderdate": [{"@type":"d","@class":"orderdate","d_weeknuminyear": 19}], "supplier": [{"@type":"d","@class":"supplier","s_phone": "16-789-973-6601|"}], "commitdate": [{"@type":"d","@class":"commitdate","d_year": 1993}], "lo_tax": 7}, {"@type":"d","@class":"lineorder","customer": [{"@t... 

は1つのプロパティlineorderタイプLINKLISTを持つクラスの一部の20万一部ありますが、顧客、サプライヤーcommitdate、すべてのリンクされたリスト。

クエリの例：ヒープと、ディスクキャッシュ：

select sum(eval("line.lo_extendedprice * line.lo_discount/100")) as revenue 
from (select lineorder as line from part where lineorder.orderdate contains (d_year=1993) unwind line) 
where line.lo_discount between 1 and 3 and line.lo_quantity<25 and line.orderdate contains (d_year=1993) 

Answer 1

オリエントはメモリの2種類があります。 ヒープが低すぎると、必要以上のメモリがないためメモリのオーバーフローが発生する可能性があります。ヒープメモリが必要です。 ディスクキャッシュはパフォーマンスに使用され、ディスクキャッシュが十分でない場合はパフォーマンスが高くなり、パフォーマンスは高くなります。 ディスクキャッシュは、データベースと同じ大きさでなければなりません。 ヒープメモリを増やし、ディスクキャッシュメモリを減らす必要があります。

希望します。それは、文書の多くを返すとき、私は答えを得ることができる唯一の方法は、サブクエリの応答に巻き戻し操作を避けた多くのことをしようとした後

よろしく

Answer 2

。これを行うには、lineorder（第2レベルのネストされたドキュメント）とその部分との関係を作成する必要があります。この場合、クラスは共通部分を持っていなければなりません。私の場合はline_orderクラスのlo_partkeyとクラス部分のp_partkey

create link ordered type linkset from lineorder.lo_partkey to part.p_partkey 

は、だから私は避けることができ、この方法は、文書の多くをほどくと、取得したり、私が子供（私の場合はlineorder）から必要な親atributesを照会：関係をこのように作成することができます。