本文作者Marko A.Rodriguez博士是一位圖形系統顧問，其研究重點主要是圖形/網絡領域的理論及實踐類問題。這篇文章以一次簡單的圖形周遊任務為基礎，為大家并行展示MySQL與Neo4j在這方面的處理能力。
本文所使用的資料集為一幅人工生成的統計圖，該圖形由一百萬個頂點與四百萬條邊線構成。其角度分布彙總結果如以下對數坐标圖所示。圖形的全部頂點分為一千個頂點子集，具體排布情況見上圖。
1、載入圖形
圖形資料集被分别加載到MySQL與Neo4j當中。在MySQL方面，使用如下模式的單獨清單加以處理。
CREATE TABLE graph (
outV INT NOT NULL,
inV INT NOT NULL
);
CREATE INDEX outV_index USING BTREE ON graph (outV);
CREATE INDEX inV_index USING BTREE ON graph (inV);
資料載入完成後，清單内容如下所示。第一行的内容意為：“頂點0與頂點1相連。”
mysql> SELECT * FROM graph LIMIT 10;
+------+-----+
| outV | inV |
| 0 | 1 |
| 0 | 2 |
| 0 | 6 |
| 0 | 7 |
| 0 | 8 |
| 0 | 9 |
| 0 | 10 |
| 0 | 12 |
| 0 | 19 |
| 0 | 25 |
10 rows in set (0.04 sec)
這一擁有一百萬個頂點的資料集同樣被載入Neo4j之中。在Gremlin中，圖形邊界按以下方式描述。第一行内容意為：“頂點0與頂點992915相連。”
gremlin> g.E[1..10]
==>e[183][0-related->992915]
==>e[182][0-related->952836]
==>e[181][0-related->910150]
==>e[180][0-related->897901]
==>e[179][0-related->871349]
==>e[178][0-related->857804]
==>e[177][0-related->798969]
==>e[176][0-related->773168]
==>e[175][0-related->725516]
==>e[174][0-related->700292]
2、為緩存熱身
在利用MySQL與Neo4j對圖形資料結構進行周遊之前，兩款資料庫都應該進行一下“熱身”運動。在MySQL方面，先運作“SELECT * FROM graph(選擇所有圖形内容)”指令，而且全部結果都經過了循環通路。而在Neo4j中，則對圖形中的每個頂點進行循環通路并對每個頂點的延展邊界加以檢索。最後，将整個實驗流程在MySQL與Neo4j中各運作兩遍，并根據第二次得出的結果進行評估。
以下紅色(代表MySQL)與藍色(代表Neo4j)色塊顯示出周遊長度為1、2、3、4時的總體處理時間。
列原始資料顯示的是每次周遊過程所傳回的總體頂點數量——當然，MySQL與Neo4j所傳回的結果是相同的，也就是圖形資料集中經過處理的部分。另外，考慮到周遊過程可以循環，是以有些頂點重複傳回了多次。最後，請大家注意，隻有Neo4j給出了長度為5的周遊過程的運作時間。MySQL用了兩個小時也沒搞定這項工作。相比之下，Neo4j在這一環節的耗時僅為14.37分鐘。
[mysql steps-1] time(ms):124 -- vertices_returned:11360
[mysql steps-2] time(ms):922 -- vertices_returned:162640
[mysql steps-3] time(ms):8851 -- vertices_returned:2206437
[mysql steps-4] time(ms):112930 -- vertices_returned:28125623
[mysql steps-5] N/A
[neo4j steps-1] time(ms):27 -- vertices_returned:11360
[neo4j steps-2] time(ms):474 -- vertices_returned:162640
[neo4j steps-3] time(ms):3366 -- vertices_returned:2206437
[neo4j steps-4] time(ms):49312 -- vertices_returned:28125623
[neo4j steps-5] time(ms):862399 -- vertices_returned:358765631
接下來，MySQL與Neo4j在個别資料點方面的處理能力如下圖所示。每個點代表在不同周遊長度下，其往返于n個頂點所花費的時間。
最後，以下資料顯示的是每次周遊過程每毫秒(平均)傳回的頂點數量。同樣，MySQL在2小時的時限内還是沒能完成長度為5的周遊工作。
總結
鑒于本次周遊測試的對象是一款人工制作的自然統計數字圖形，是以Neo4j本身的圖形型資料庫屬性在優化方面當然要勝過關系型資料庫MySQL。然而，在本次測試中沒有對Java虛拟機以及SQL查詢指令等項目進行優化。實驗在Neo4j與MySQL中分别進行，在“即開即用”的前提下利用二者的“固有文法”處理這兩類查詢。
本文轉自 wws5201985 51CTO部落格，原文連結：http://blog.51cto.com/wws5201985/739683，如需轉載請自行聯系原作者