關系數據庫經過幾十年的發(fā)展，已經非常成熟，但同時也存在不足：
成都創(chuàng)新互聯公司專注于網站建設|成都網站維護|優(yōu)化|托管以及網絡推廣，積累了大量的網站設計與制作經驗，為許多企業(yè)提供了網站定制設計服務，案例作品覆蓋邊坡防護網等行業(yè)。能根據企業(yè)所處的行業(yè)與銷售的產品，結合品牌形象的塑造，量身制作品質網站。
表結構是強約束的，業(yè)務變更時擴充很麻煩。
如果對大數據量的表進行統計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數據讀入內存。
全文搜索只能使用 Like 進行整表掃描，性能非常低。
針對這些不足，產生了不同的 NoSQL 解決方案，在某些場景下比關系數據庫更有優(yōu)勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 SQL 的有利補充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類：
Redis 是典型，其 value 是具體的數據結構，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數據結構服務器。
以 list 為例：
LPOP key 是移除并返回隊列左邊的第一個元素。
如果用關系數據庫就比較麻煩了，需要操作：
Redis 的缺點主要體現在不支持完成的ACID事務，只能保證隔離性和一致性，無法保證原子性和持久性。
最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。
特點：
以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數據庫中會有很大的麻煩，而使用文檔數據庫則非常方便。
文檔數據庫的主要缺點：
關系數據庫是按行來存儲的，列式數據庫是按照列來存儲數據。
按行存儲的優(yōu)勢：
在某些場景下，這些優(yōu)勢就成為劣勢了，例如，計算超重人員的數據，只需要讀取體重這一列進行統計即可，但行式存儲會將整行數據讀取到內存中，很浪費。
而列式存儲中，只需要讀取體重這列的數據即可，I/O 將大大減少。
除了節(jié)省I/O，列式存儲還有更高的壓縮比，可以節(jié)省存儲空間。普通行式數據庫的壓縮比在 3:1 到 5:1 左右，列式數據庫在 8:1 到 30:1，因為單個列的數據相似度更高。
列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續(xù)空間中，而列式存儲將不同列存儲在不連續(xù)的空間。
一般將列式存儲應用在離線大數據分析統計場景，因為這時主要針對部分列進行操作，而且數據寫入后無須更新。
關系數據庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：
假設有一個交友網站，信息表如下：
需要匹配性別、地點、語言列。
需要匹配性別、地點、愛好列。
實際搜索中，各種排列組合非常多，關系數據庫很難支持。
全文搜索引擎是使用 倒排索引 技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：
所以特別適合根據關鍵詞來查詢文檔內容。
上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據實際需求進行選擇。
NewSQL是對一類現代關系型數據庫的統稱，這類數據庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統既擁有NoSQL數據庫的擴展性，又保持傳統數據庫的事務特性。NewSQL重新將“應用程序邏輯與數據操作邏輯應該分離”的理念帶回到現代數據庫的世界，這也驗證了歷史的發(fā)展總是呈現出螺旋上升的形式。
在21世紀00年代中，出現了許多數據倉庫系統 (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統并不在本文定義的NewSQL范圍內。OLAP 數據庫更關注針對海量數據的大型、復雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。
NoSQL的擁躉普遍認為阻礙傳統數據庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數據模型?(如 key/value，graphs 和Documents)。
兩個最著名的NoSQL數據庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。
在21世紀00年代末，市面上已經有許多供用戶選擇的分布式數據庫產品。使用NoSQL的優(yōu)勢在于應用開發(fā)者可以更關注應用邏輯本身，而非數據庫的擴展性問題；但與此同時許多應用，如金融系統、訂單處理系統，由于無法放棄事務的一致性要求被拒之門外。
一些組織，如Google，已經發(fā)現他們的許多工程師將過多的精力放在處理數據一致性上，這既暴露了數據庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。
NewSQL數據庫設計針對的讀寫事務有以下特點：
1、耗時短。
2、使用索引查詢，涉及少量數據。
3、重復度高，通常使用相同的查詢語句和不同的查詢參考。
也有一些學者認為NewSQL系統是特指實現上使用Lock-free并發(fā)控制技術和share-nothing架構的數據庫。所有我們認為是NewSQL的數據庫系統確實都有這樣的特點。
Web1.0的時代，數據訪問量很有限，用一夫當關的高性能的單點服務器可以解決大部分問題。
隨著Web2.0的時代的到來，用戶訪問量大幅度提升，同時產生了大量的用戶數據。加上后來的智能移動設備的普及，所有的互聯網平臺都面臨了巨大的性能挑戰(zhàn)。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關系型的數據庫。
NoSQL 不依賴業(yè)務邏輯方式存儲，而以簡單的key-value模式存儲。因此大大的增加了數據庫的擴展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數據庫 列式數據庫 Hbase Hbase
HBase是Hadoop項目中的數據庫。它用于需要對大量的數據進行隨機、實時的讀寫操作的場景中。
HBase的目標就是處理數據量非常龐大的表，可以用普通的計算機處理超過10億行數據，還可處理有數百萬列元素的數據表。
Cassandra Cassandra
Apache Cassandra是一款免費的開源NoSQL數據庫，其設計目的在于管理由大量商用服務器構建起來的龐大集群上的海量數據集(數據量通常達到PB級別)。在眾多顯著特性當中，Cassandra最為卓越的長處是對寫入及讀取操作進行規(guī)模調整，而且其不強調主集群的設計思路能夠以相對直觀的方式簡化各集群的創(chuàng)建與擴展流程。
主要應用：社會關系，公共交通網絡，地圖及網絡拓譜(n*(n-1)/2)
NoSQL太火，冒出太多產品了，保守估計也成百上千了。
互聯網公司常用的基本集中在以下幾種，每種只舉一個比較常見或者應用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同時提供了更加豐富的數據結構和運算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機恢復，同時支持replication提供讀可擴展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單，數據量不受限于內存大小，數據落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序寫盤的方式對于新硬件ssd再適合不過了，不足是僅提供了一個庫，需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql，具備了區(qū)別mysql的最大亮點：可擴展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對于數據量遠超內存限制的場景來說，還需要慎重。
4. Column Table Store: HBase
這個富二代似乎不用贅述了，最大的優(yōu)勢是開源，對于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴展性方面是最強的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產品不少，來解決諸如join、聚集運算等復雜查詢。
NoSQL描述的是大量結構化數據存儲方法的集合，根據結構化方法以及應用場合的不同，主要可以將NoSQL分為以下幾類。
(1)Column-Oriented
面向檢索的列式存儲，其存儲結構為列式結構，同于關系型數據庫的行式結構，這種結構會讓很多統計聚合操作更簡單方便，使系統具有較高的可擴展性。這類數據庫還可以適應海量數據的增加以及數據結構的變化，這個特點與云計算所需的相關需求是相符合的，比如GoogleAppengine的BigTable以及相同設計理念的Hadoop子系統HaBase就是這類的典型代表。需要特別指出的是，Big Table特別適用于MapReduce處理，這對于云計算的發(fā)展有很高的適應性。
(2)Key-Value。
面向高性能并發(fā)讀/寫的緩存存儲，其結構類似于數據結構中的Hash表，每個Key分別對應一個Value,能夠提供非?？斓牟樵兯俣?、大數據存放量和高并發(fā)操作，非常適合通過主鍵對數據進行查詢和修改等操作。Key-Value數據庫的主要特點是具有極高的并發(fā)讀/寫性能，非常適合作為緩存系統使用。MemcacheDB、BerkeleyDB、Redis、Flare就是Key-Value數據庫的代表。
(3)Document-Oriented。
面向海量數據訪問的文檔存儲，這類存儲的結構與Key-Value非常相似，也是每個Key分別對應一個Value,但是這個Value主要以JSON(JavaScriptObjectNotations)或者XML等格式的文檔來進行存儲。這種存儲方式可以很方便地被面向對象的語言所使用。這類數據庫可在海量的數據中快速查詢數據，典型代表為MongoDB、CouchDB等。
NoSQL具有擴展簡單、高并發(fā)、高穩(wěn)定性、成本低廉等優(yōu)勢，也存在一些問題。例如，NoSQL暫不提供SQL的支持，會造成開發(fā)人員的額外學習成本;NoSQL大多為開源軟件其成熟度與商用的關系型數據庫系統相比有差距;NoSQL的架構特性決定了其很難保證數據的完整性，適合在一些特殊的應用場景使用。
NoSQL，泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數據庫的產生就是為了解決大規(guī)模數據集合多重數據種類帶來的挑戰(zhàn)，尤其是大數據應用難題。
雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現在已經開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現在的系統已經更加的成熟、穩(wěn)定。不過現在也面臨著一個嚴酷的事實：技術越來越成熟——以至于原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數據建立快速、可擴展的存儲庫。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數據庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲，相對于鋪天蓋地的關系型數據庫運用，這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：
不需要預定義模式：不需要事先定義數據模式，預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時，并不需要預先定義它們的模式。
無共享架構：相對于將所有數據存儲的存儲區(qū)域網絡中的全共享架構。NoSQL往往將數據劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數據的性能往往好于通過網絡傳輸讀取數據的性能，從而提高了系統的性能。
彈性可擴展：可以在系統運行的時候，動態(tài)增加或者刪除結點。不需要停機維護，數據可以自動遷移。
分區(qū)：相對于將數據存放于同一個節(jié)點，NoSQL數據庫需要將數據進行分區(qū)，將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復制。這樣既提高了并行性能，又能保證沒有單點失效的問題。
異步復制：和RAID存儲系統不同的是，NoSQL中的復制，往往是基于日志的異步復制。這樣，數據就可以盡快地寫入一個節(jié)點，而不會被網絡傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現故障的時候，可能會丟失少量的數據。
BASE：相對于事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。
NoSQL數據庫并沒有一個統一的架構，兩種NoSQL數據庫之間的不同，甚至遠遠超過兩種關系型數據庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應用，在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL。
重慶分公司
重慶分公司
