特不正經之大數據（二）
SQL作為資料庫的代名詞，已經幾十年了...
時代不一樣了，大數據讓NoSQL火了，哦，NoSQL，不用SQL了嘛？
是Not Only SQL！
為什麼會出現NoSQL呢？
特不正經決定刨根問底，一定有個說法！
隨著網路改變了人們的生活，網路原居民誕生了
吃喝玩樂，衣食住行，再也離不開網路了
資本主義的經濟原理告訴我們，有金礦的地方一定有人類...
網站發現，數據對於理解用戶，獲取用戶太重要了
於是，對數據的理解完全不一樣了，以前丟棄的數據，現在都作為資產保持下來
比如，你在網站上的每次點擊，你用的手機操作系統，瀏覽器版本信息
你在網頁上停留多少時間，你的瀏覽器cookie信息，你關注過的人...
許多互聯網巨頭不僅記錄訪問信息，而且偷用戶的隱私數據...
數據爆炸時代的到來，傳統關係型資料庫再也無法處理了
達到一個查詢需要分鐘或者小時的程度...
這時，網路巨頭再也受不了了，
錢多，人又不傻，自己做個資料庫出來，於是NoSQL就出現了...
NoSQL建立在分散式系統上，也就是說它不是單個資料庫，而是幾十個甚至上百個
這使得它易於擴展和分片，存儲容量幾乎無限，訪問速度極快。
問題迎刃而解...
吹牛吧？
世界上沒有無緣無故的愛！
代價是什麼？
假設現在的銀行交易系統採用NoSQL資料庫...
你去銀行存了1萬塊錢，存好錢，你立馬到隔壁ATM查一下存款
神馬，沒有！
過一會再查，有了！
過一會再查一下，又沒有了！
當然，這只是假設，除非你兩次查詢時間間隔特別短
但說明使用NoSQL資料庫，各個分散式庫中的狀態不是完全一致的！
用專業名詞就叫：ACID原則
原子性（Atomicity），一致性（Consistency）
隔離性（Isolation），持久性（Durability）
這可是SQL資料庫的命啊！
NoSQL採取最終一致性原則，而不是所有四個參數在每個事務中保持一致。
這就是NoSQL系統通常被描述為只提供基本保證的原因
（基本可用，軟狀態，最終一致性），而不是完整的ACID支持。
雖然NoSQL極大地增加了可用時間和伸縮性, 但由於它無法支撐ACID，
問題的嚴重程度取決於業務特性和應用代碼質量，在有些情況下,這個問題十分嚴重。
另一個NoSQL出現的問題是現在有很多類型的NoSQL系統,
但它們之間卻幾乎沒有一致性.
諸如靈活性,性能,複雜性,伸縮性等等特性在不同系統間差別巨大,
這使得很難選擇那種NoSQL資料庫適合你的項目，
使得NoSQL可以在不顯著丟失穩定性的情況下，提供一個
遠比SQL系統更高效的解決方案.
NoSQL有很多種，市面上上基本的有4種, 她們適合不同的應用場景：
在某些場景下，適當選用NoSQL資料庫，能極大解決問題...
比如，大家熟知的12306，購買火車票
一開始，選用了某巨牛的國際巨頭的軟硬體解決方案，號稱地球最強
買火車票的時間 = 做火車的時間
但結果大家可想而知...
簡直是侮辱了中國創新...
後來，採用了Gemfire，這是一個類似於Redis的商業版NoSQL資料庫
性能一下子改善了，因此用對NoSQL對於高並發系統相當的關鍵...
時代總是不斷發展的，這是一個造詞時代，
見了新名稱你不要奇怪...
續NoSQL後，NewSQL登場了...
NewSQL是一種較新的形式，它的目標是將SQL的ACID保證
與NoSQL的可擴展性和高性能相結合。
顯然，因為結合了過去僅單獨存在的優點，NewSQL看起來很有前途;
或許，在未來的某個時候，它將成為大多數人使用的標準。
真的那麼厲害嗎？
不幸的是，目前大多數NewSQL資料庫都是專有軟體或僅適用於特定場景，
這顯然限制了新技術的普及和應用。
除此之外，NewSQL在每個方面比較均勻，每個解決方案都有自己的缺點和優勢。
例如，SAP的 HANA只能處理低到中等的事務性工作負載
MemSQL對於集群分析很有用，但在ACID事務上表現出較差的一致性，等等。
因此，在這些解決方案變得真正普及之前，可能還需要一段時間。
NewSQL也分為多種：
最後，介紹一下最近發布的Apache Kudu資料庫，它由Cloudera主導並開源
用戶往往存在兩類數據：一類是低延遲的隨機訪問特定數據，而另一類就是高吞吐的分析大量數據。，為了數據不同的用途，需要存儲兩份數據，一份在HBASE中，一份在HDFS中，處理相當麻煩：
Kudu 致力於解決上面的問題，它提供了簡單的來處理數據的插入，更新和刪除，同時提供了 table scan 來處理數據分析。通常如果一個系統要融合兩個特性，很有可能就會陷入兩邊都做，兩邊都沒做好的窘境，但 Kudu 很好的在融合上面取得了平衡。
講了那麼多，進入提問回答的環節：
1）SQL已過時，應該儘可能替換為NoSQL或New SQL，對還是錯？
2）三種方案中沒有明確的領導者，每一種都有更適合的項目，而在其他情況下不太適合（或完全不適合），對還是錯？
3）如果你追求高速緩存SQL，用VoltDB還是Cassandra，哪個更合適？
最後總結一下：
沒有最好的，也沒有完美的，只有最合適的。
************************************
「特不正經」是我個人的公眾號，歡迎關注！
本公眾號主要內容為IT發展趨勢研究和IT人的生活，包括數字化轉型，信息安全，大數據，應用整合，DevOps和雲，IT程序猿，銷售狼，諮詢獅, 老闆狗的生活，天文，地理，哲學，人文等無所不包的不正經內容。
特不正經是一個醬油馬拉松跑者，非著名詩人，主修哲學，從事修路，挖湖，抓鬼打怪的軟體狗（派拉軟體專屬）...
TAG:全球大搜羅 |