做了一年的大一年度項(xiàng)目了，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)結(jié)構(gòu)還是有些了解了，有的時(shí)候還是覺得這種二維表不是很順手。在看過一篇文章之后，對(duì)NoSQL有了初步的了解，（https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data）。這篇文章寫的很好，確實(shí)寫出來了在實(shí)際情況下NoSQL的“用武之地”，而且用了MineCraft作分析，但是也許不夠全面。比如文章中只是提到了，entity數(shù)據(jù)用關(guān)系型怎么存，event數(shù)據(jù)用NoSQL怎么存，我想借我這篇文章，來分析一下event類型的數(shù)據(jù)原始的關(guān)系型數(shù)據(jù)庫(kù)是怎樣存數(shù)據(jù)的，然后再對(duì)這兩種儲(chǔ)存方式做一種對(duì)比，算是對(duì)原文都一種補(bǔ)充吧。

對(duì)于這種死亡事件，有這樣的兩條數(shù)據(jù)，一個(gè)是關(guān)于creeper的爆炸，一種是掉進(jìn)巖漿。如果必須用關(guān)系型二維表數(shù)據(jù)庫(kù)，我會(huì)這樣存儲(chǔ)。（如果您還不知道是什么樣的數(shù)據(jù)，可以先看之后的NoSQL儲(chǔ)存方法，那樣看起來更清楚。）

這種情況的數(shù)據(jù)可以說是數(shù)據(jù)庫(kù)設(shè)計(jì)中比較復(fù)雜的一種情況了，因?yàn)樗瑑煞N情況（當(dāng)然不止這兩種情況，那么就會(huì)產(chǎn)生更多的結(jié)構(gòu)），不同情況的數(shù)據(jù)表結(jié)構(gòu)是不同的，這非常麻煩。我們一般的解決方案是設(shè)計(jì)四個(gè)表格，利用關(guān)系型數(shù)據(jù)庫(kù)的關(guān)系性。設(shè)計(jì)如下四張表格。（在這里我就簡(jiǎn)寫了）

第一張表

id #首先用于關(guān)聯(lián)，主表需要有個(gè)id，這個(gè)倒不是什么區(qū)別，因?yàn)镹oSQL一般也會(huì)有個(gè)_id的預(yù)設(shè)
  timestamp #所有共同部分就可以存在一張表中。
  cause
  player_UID
  player_experience
  player_age    #對(duì)于player_inveneory_id 因?yàn)檫@是一個(gè)可以任意長(zhǎng)度的數(shù)組，又只能保存在另一個(gè)表中了

第二張表（用于保存creeper死亡方式的死亡事件的）

id #這是這張表的id以后可以跟別的表格關(guān)聯(lián)
  mid #用于關(guān)聯(lián)主表
  enemy_type
  enemy_power
  enemy_distance
  enemy_age

第三張表（用于保存lava死亡方式的死亡事件的）

  id #這是這張表的id以后可以跟別的表格關(guān)聯(lián)
  mid #用于關(guān)聯(lián)主表
  place_x
  place_y
  place_z 

第四張表（用于保存player_inveneory）

  id #這是這張表的id以后可以跟別的表格關(guān)聯(lián)
  mid #用于關(guān)聯(lián)主表
  inveneory

至此關(guān)系性數(shù)據(jù)庫(kù)就將這種有不同結(jié)構(gòu)的事件存放方式規(guī)定好了，接下來存放如下（我就不畫表格了）

1.
  id  timestamp          cause    player_UID    player_experience  player_age
  1   "2013-05-23T1:50:00-0600"  "creeper"  "99234890823"   8873729        228    
  2   "2013-05-24T23:25:00-0600"  "lava"   "99234890823"   88737         22

2.
  id  mid   enemy_type  enemy_power  enemy_distance  enemy_age
  1   1    "creeper"   .887      3.34       .6677

3.
  id  mid  place_x  place_y  place_z
  1   2   45.366   -13.333  -39.288

4.
  id  mid  inveneory
  1   1   "diamend sword"
  2   1   "torches"
  3   2   "stone" 

至此，我們就用關(guān)系性數(shù)據(jù)庫(kù)將這兩個(gè)事件數(shù)據(jù)存下了。（好麻煩是吧！）

我們?cè)倏碞oSQL的儲(chǔ)存方法，因?yàn)槊織l數(shù)據(jù)并不受字段（列名）限制，完全可以直接保存，不用分表。（比如JSON格式）

#第一條數(shù)據(jù)
{
  "timestamp": "2013-05-23T1:50:00-0600",
  "cause":"creeper",
  "enemy":{
    "type":"creeper"
    "power": .887
    "distance_from_player":3.34
    "age":.6677
  },
  "player": {
    "UID":"99234890823",
    "experience": 8873729,
    "age": 228,
    "inveneory":["diamend sword","torches"]
  }
}
#第二條數(shù)據(jù)
{
  "timestamp": "2013-05-24T23:25:00-0600",
  "cause":"lava",
  "place":{
    x:45.366
    y:-13.333
    z:-39.288
  }
  "player": {
    "UID":"99234890823",
    "experience": 88737,
    "age": 22,
    "inveneory":["stone"]
  }
}

下面我們分析NoSQL對(duì)這種數(shù)據(jù)存放方式的好處

1.首先是把分散的表結(jié)構(gòu)整合了，讓應(yīng)該在一起的數(shù)據(jù)在一起了。
這就像C語言中開多個(gè)數(shù)組儲(chǔ)存還是用一個(gè)結(jié)構(gòu)體數(shù)組的區(qū)別，將一些有關(guān)系的數(shù)據(jù)放在一起是人類一種自然的想法，當(dāng)然會(huì)讓人更加舒服，而且可以提高關(guān)聯(lián)性和升級(jí)擴(kuò)展的簡(jiǎn)易程度。

2.存放變得方便
讓我們來考慮有數(shù)據(jù)來了我們?cè)趺磧?chǔ)存。
對(duì)于二維表數(shù)據(jù)庫(kù)：
    1.分析數(shù)據(jù)是那種類型的
    2.存放主表數(shù)據(jù)，并獲得返回id
    3.分支，加上主表id在不同情況下向lava或creeper表中存放數(shù)據(jù)
    4.開循環(huán)，向inveneory表中插入多條記錄
    這還只是一個(gè)簡(jiǎn)述，還要考慮到對(duì)多個(gè)表格操作時(shí)的數(shù)據(jù)回滾問題，實(shí)際寫起來30行左右，那么出錯(cuò)的可能就大大提高了。
對(duì)于NoSQL類型
    一句話：

 insert(data);#偽碼

其實(shí)想想便知道，取數(shù)據(jù)時(shí)原來的關(guān)系性數(shù)據(jù)庫(kù)也會(huì)同樣麻煩。

3.NoSQL更利于動(dòng)態(tài)生成存放方式，靈活性高了很多，至少我們可以在存放數(shù)據(jù)的時(shí)候再設(shè)計(jì)數(shù)據(jù)庫(kù)了（雖然可能預(yù)先設(shè)計(jì)會(huì)好一些）

當(dāng)然，如果存儲(chǔ)的不是事件性或者類似此類數(shù)據(jù)那么就另當(dāng)別論了，二維表還是有很多它本身的優(yōu)勢(shì)的。以上是我的一些個(gè)人的分析，當(dāng)然還有很多普遍認(rèn)同的觀點(diǎn)，以下是一些普遍認(rèn)同的關(guān)于兩種數(shù)據(jù)庫(kù)模式的優(yōu)缺點(diǎn)分析，我也基本同意。

關(guān)系性優(yōu)勢(shì)：
    1.事務(wù)處理---保持?jǐn)?shù)據(jù)的一致性；
    2.由于以標(biāo)準(zhǔn)化為前提，數(shù)據(jù)更新的開銷很小（相同的字段基本上只有一處）；
    3.可以進(jìn)行Join等復(fù)雜查詢。

關(guān)系型缺點(diǎn)：
    1. 擴(kuò)展困難：由于存在類似Join這樣多表查詢機(jī)制，使得數(shù)據(jù)庫(kù)在擴(kuò)展方面很艱難;
    2. 讀寫慢：這種情況主要發(fā)生在數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)由于關(guān)系型數(shù)據(jù)庫(kù)的系統(tǒng)邏輯非常復(fù)雜，使得其非常容易發(fā)生死鎖等的并發(fā)問題，所以導(dǎo)致其讀寫速度下滑非常嚴(yán)重;
    3. 成本高：企業(yè)級(jí)數(shù)據(jù)庫(kù)的License價(jià)格很驚人，并且隨著系統(tǒng)的規(guī)模，而不斷上升;
    4. 有限的支撐容量：現(xiàn)有關(guān)系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲(chǔ);

NoSQL優(yōu)勢(shì)，主要體現(xiàn)在下面幾點(diǎn)：
    1. 簡(jiǎn)單的擴(kuò)展：典型例子是Cassandra，由于其架構(gòu)是類似于經(jīng)典的P2P，所以能通過輕松地添加新的節(jié)點(diǎn)來擴(kuò)展這個(gè)集群;
    2. 快速的讀寫：主要例子有Redis，由于其邏輯簡(jiǎn)單，而且純內(nèi)存操作，使得其性能非常出色，單節(jié)點(diǎn)每秒可以處理超過10萬次讀寫操作;
    3. 低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫(kù)共有的特點(diǎn)，因?yàn)橹饕际情_源軟件，沒有昂貴的License成本;

NoSQL數(shù)據(jù)庫(kù)還存在著很多的不足，常見主要有下面這幾個(gè)：
    1. 不提供對(duì)SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會(huì)對(duì)用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本;
    2. 支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限，大多數(shù)NoSQL數(shù)據(jù)庫(kù)都不支持事務(wù)，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報(bào)表等;
    3. 現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關(guān)系型數(shù)據(jù)庫(kù)幾十年的完善不可同日而語;