最近在抓取一些社交網(wǎng)站的數(shù)據(jù)，抓下來(lái)的數(shù)據(jù)用MySql存儲(chǔ)。問(wèn)我為什么用MySql，那自然是入門(mén)簡(jiǎn)單，并且我當(dāng)時(shí)只熟悉MySql。可是，隨著數(shù)據(jù)量越來(lái)越大，有一個(gè)問(wèn)題始終困擾著我，那就是社交關(guān)系的存儲(chǔ)。
就以新浪微博舉例，一個(gè)大V少則十幾萬(wàn)，多則幾千萬(wàn)的粉絲，這些關(guān)注關(guān)系要怎么存呢？在MySql中，一條關(guān)注關(guān)系（大V id，大V的一個(gè)粉絲 id）存為一條數(shù)據(jù)，那么當(dāng)用戶數(shù)量上來(lái)的時(shí)候，關(guān)注關(guān)系輕松破億，破十億，甚至上百億，并且為了保證每條數(shù)據(jù)的唯一性，還需要設(shè)置聯(lián)合索引，MySql就有些力不從心了。那么有人要說(shuō)了：分表呀。嗯，沒(méi)錯(cuò)，分表的確可以在插入端和讀取端提升一些速度。比如我們可以根據(jù)id哈希到100張表中。查詢一個(gè)用戶有哪些粉絲是快了，但是查詢一個(gè)用戶關(guān)注了哪些人時(shí)仍然需要遍歷全表。好，這時(shí)候我們還可以以（id，其關(guān)注的一個(gè)用戶的id）再構(gòu)造100張表，于是兩種查詢都快了。然而，后面那100張表是冗余數(shù)據(jù)，看著就不爽...并且生成一張子圖也不方便（需要多次寫(xiě)SQL查表）。
于是，在搜索更好的方案時(shí)無(wú)意間發(fā)現(xiàn)了圖形數(shù)據(jù)庫(kù)，查閱一番資料后感覺(jué)確實(shí)是個(gè)不錯(cuò)的選擇，畢竟業(yè)界的一些大佬，如twitter，Adobe等也在用。
那么，什么是圖形數(shù)據(jù)庫(kù)呢？在這里我貼上較為官方的定義：a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data – independent of the way the data is stored internally. It’s really the model and the implemented algorithms that matter.注意，這里只是說(shuō)數(shù)據(jù)模型是圖結(jié)構(gòu)的，沒(méi)有說(shuō)數(shù)據(jù)的存儲(chǔ)也一定要是圖結(jié)構(gòu)的。其數(shù)據(jù)模型如下圖
