目前，企業在著手推動大資料專案的過程中，經常會遇到這樣一個關鍵性的決策難題——到底該使用哪種資料庫方案?經過綜合考量，最終的選項往往只剩下SQL與NoSQL兩種。SQL具有驕人的業績以及龐大的安裝基礎，但NoSQL卻能夠帶來可觀的收益並同樣擁有不少支持者。在今天的辯論當中，我們將一同聽聽兩大陣營中各位專家的意見。
Network World網站主編John Dix專門組織了此次辯論並邀請到多位專家。其中兩位參與專家分別是VoltDB公司CTO Ryan Betts和Couchbase公司CEO Bob Wiederhold。Ryan Betts認為SQL已經在大型企業當中贏得了穩定的生存空間，而大資料只不過是SQL需要支撐的另一項工作內容。Bob Wiederhold則認為NoSQL是一套極具可行性的備選方案，事實上它也在多個領域中成為大資料的卓越配合手段——特別是在可擴充套件性方面。
結構化查詢語言(簡稱SQL)幾十年來已經用累累戰果以及赫赫聲名證明了自身實力，而且目前仍在繼續投身於多家大資料廠商及相關企業當中，其中包括谷歌、Facebook、Cloudera以及Apache。
雖然後起之秀NoSQL確實引起了一定反響，但SQL仍然在市場上保持著顯著的份額優勢並繼續在大資料領域不斷贏得投入與採納。
一旦某種技術像SQL這樣取得了主導地位，人們往往會忘記其最為核心的競爭優勢。SQL之所以能夠勝出，主要在於它擁有以下一系列獨特的優勢組合：
1. SQL能夠加強與資料之間的互動，允許使用者針對單一資料庫設計提出內容廣泛的問題。這正是SQL成功的關鍵所在——如果資料不具備互動性、則基本上將失去實用性。而持續增長的互動性又能為資料庫的未來發展帶來新的審視角度、相關問題以及實際意義。
2. SQL具備標準化特性，允許使用者自由運用源自各類系統的專業知識、同時支援第三方外掛及工具。
3. SQL具備擴充套件性、功能豐富且經過實際驗證，能夠解決各類難題——包括以寫入為主導的快速事務處理以及涉及頻繁掃描的深層分析。
4. SQL能夠與資料表現及儲存機制順暢對接。某些SQL系統還支援JSON以及其它結構化物件格式，從而帶來優於NoSQL方案的效能表現及更多功能特性。
“NoSQL”這一表述其實並不準確，但在本次討論中，我採用了Rick Cattell博士為NoSQL總結出的定義，即“指那些能夠提供鍵/值儲存或者簡單記錄與索引等操作的系統，旨在為這些簡單操作提供垂直可擴充套件性。”
很明顯，目前市面上的很多新型資料庫彼此之間存在較大差異——準確掌握它們各自特性與深層機制給使用者來的便利與侷限是獲得專案部署成功的關鍵所在。NoSQL的核心特性使其更適合於解決特定問題。舉例來說，圖形資料庫更適合處理那些將資料根據關係而非傳統行或者文件形式加以組織的例項，而特定文字搜尋系統則比較擅長處理以實時方式查詢使用者輸入內容的情況。
在這裡，我打算概括性闡述SQL系統與簡單鍵/值乃至僅僅在儲存格式及可擴充套件性方面有所創新的JSON物件儲存系統相比，到底存在哪些差異與主要優勢。
* SQL帶來互動特性。SQL是一種宣告性查詢語言。使用者說出自己想要的內容(例如顯示出過去五年來，每年三月份購買量最大的客戶分別來自哪些地區)，資料庫則在內部組建出相關演算法並根據要求提取對應結果。相比之下，NoSQL孕育出的編碼創新成果MapReduce則是一種規程化查詢技術。MapReduce要求使用者不僅瞭解自己想要的結果，同時也需要提供獲取結果的具體執行方式。
雖然聽起來只是一種頗為枯燥的技術性差異，但這種特性仍然極為關鍵，原因有以下兩點：首先，宣告性SQL查詢能夠更為輕鬆地通過圖形化工具以及對報告生成器的簡單點選來建立。這種相對較低的使用門檻能夠幫助分析師、運營者、管理者以及其他不瞭解軟體程式設計知識的使用者享受其核心功能及成效。第二，對資料庫引擎使用內部資訊並選擇高效演算法的方式進行抽象化處理。即使物理層或者資料庫索引出現變動，優化演算法仍然能夠確切完成任務。相比之下，在過去的程式化系統當中、程式設計師需要重新審視現有處理方式並進行二次程式設計。這樣既帶來高昂成本，又很有可能導致意外錯誤。
市場對於這種本質差異倒是非常瞭然。早在2010年，谷歌就宣佈引入一套SQL方案以強化MapReduce，從而滿足內部使用者的實際需求。最近，Facebook則釋出了自己的SQL方案Presto，意在對其PB級別HDFS叢集資料進行查詢。根據Facebook方面的說法：“由於我們的資料倉儲規模已經增長至PB級別、業務需求也逐步發展，我們顯然需要一套經過優化的互動式系統以實現更低的查詢延遲。”除此之外，Cloudera正在HDFS以上建立自己的SQL方案Impala。前面提到的這一系列發展都立足於Hive——一套面向Hadoop、長期存在且得到廣泛採用的SQL外殼。
* SQL具備標準化特性。雖然供應商有時候會對自己的SQL介面進行特殊調整與定製，但從本質上講SQL核心仍然是一套標準化程度很高的方案，以ODBC以及JDBC為代表的其它規範同樣提供廣泛可用的、面向SQL系統的穩定介面。由此衍生出的管理及操作工具生態系統能夠幫助大家以SQL系統為基礎，實現應用程式的設計、監控、檢查、探索以及開發。
SQL使用者及程式設計師也因此得以重新使用自己積累自多種後端系統的API以及使用者介面知識，從而縮減應用程式開發時間。標準化特性還允許擁有宣告許可的第三方打造提取、轉換以及載入(簡稱ETL)工具，旨在幫助企業以流程化方式處理不同資料庫及系統之間的資料流。
* SQL具備可擴充套件性。有些朋友可能誤以為SQL必須通過犧牲效能的方式來獲得可擴充套件性，這其實是完全錯誤的。如上所述，Facebook打造了一款SQL介面對PB級別的資料加以查詢。SQL在執行ACID事務處理任務時同樣具備極快的速度表現。SQL為資料儲存及檢索機制提供的抽象化手段允許使用者以統一化方式完成處理工作，而且無需考慮具體任務型別以及資料規模;這使得SQL能夠高效執行在各類叢集化副本資料儲存體系之間。將SQL作為介面的作法不涉及雲建立、具體規模或者HA系統，而且SQL當中也沒有任何固有因素會對容錯性、高可用性以及複製能力產生限制。事實上，目前所有現代化SQL系統都能夠很好地支援雲體系中的橫向可擴充套件性、複製能力以及容錯性。
* SQL支援JSON。幾年之前，很多SQL系統開始將XML文件支援能力納入自身設計思路。時至今日，隨著JSON逐步成為主流資料交換格式之一，各SQL廠商也在積極為JSON提供支援。鑑於當下敏捷化程式設計流程以及對網際網路接入基礎設施正常執行時間的要求，結構化資料型別的支援能力已經成為不可或缺的重要一環。Oracle 12c、PostgreSQL 9.2、VoltDB以及其它各類資料庫方案都開始支援JSON——其效能基準水平普遍優於“原生”JSON NoSQL方案。
SQL將繼續在市場份額的爭奪戰中佔據主動，也將繼續吸引到更多投資方與採納者的支援。NoSQL資料庫在提供專有查詢語言或者簡單鍵-值語義的同時，卻無法從深入的技術層面帶來差異性，這無疑嚴重影響了其挑戰市場統治者的能力。現代SQL系統能夠在保持甚至超越原有可擴充套件性的同時，支援豐富的查詢語義、建立並培養使用者基礎、擴充生態系統整合效果並在企業環境內深化採納程度。
觀點二：NoSQL更適合大資料應用程式——Couchbase公司CEO Bob Wiederhold
目前已經有越來越多的企業開始將NoSQL視為關係型資料庫的一種可行性替代方案;特別是在大資料應用程式領域，很多企業使用者意識到規模化操作的實際表現要優於標準化叢集與商用伺服器所帶來的效果。除此之外，採用無模式化資料模型往往更適合當下各類不同資料的捕捉與處理工作。
不過對於操作型資料庫中的大資料而言，其設計主旨並非圍繞分析性工作所展開;操作型資料庫通常需要為無數使用者提供龐大的資料集，幫助他們進行持續性資料訪問並進行實時事務處理。用於操作並管理大資料內容的此類資料庫都具備龐大的規模，這也解釋了NoSQL特性的重要意義及其在大資料應用程式中扮演核心角色的原因。
* NoSQL是實現可擴充套件性的關鍵所在
技術行業在每一次迎來硬體發展的根本性轉變時，都必然經歷過渡拐點。在資料庫領域，這種由向上擴充套件轉為向外擴充套件架構的轉變也成為推動NoSQL快速成長的主要因素。關係型資料庫，其中包括由甲骨文及IBM等巨頭所打造的具體方案，專注於解決向上擴充套件難題。也就是說，它們採取集中式、全域性共享技術，只能通過新增價格更為昂貴的硬體裝置滿足擴充套件需求。
與之相反，NoSQL資料庫從設計思路上就考慮到了分散式特性，屬於徹頭徹尾聲的向外擴充套件技術。它們利用一系列分散式節點(構成一套整體叢集)來提供具備卓越彈性的擴充套件能力，從而幫助使用者隨意新增更多節點以應對持續增加的工作負載。
分散式向外擴充套件方案往往還會帶來低於向上擴充套件機制的使用成本。後者屬於一整套龐大、複雜、具備容錯性機制的伺服器體系，因此無論是設計、建造還是後期支援都會帶來高昂的成本支出。商用關係型資料庫的許可成本同樣不容忽視，因為其計費策略以單一伺服器為基本單位。在另一方面，NoSQL資料庫則通常屬於開源專案，以伺服器叢集為整體計費單位、價格也相比較低。
* NoSQL是實現靈活性的關鍵所在
關係型與NoSQL資料模型可謂完全不同。關係型模型需要將資料拆分成包含行與列的多個關聯性表，這些表通過同樣儲存在列中的外來鍵實現相互引用。
當使用者需要對一組資料進行查詢時，所需資訊必須由多個表中收集獲得——通常涉及數百種當下常用的企業應用程式——並將其加以整合，而後才能交付終端應用。與之相似，在寫入資料時、寫入流程需要加以協調並在執行過程中面向多個表。當資料量相對較小、向資料庫內匯入的速度並不太快的情況下，關係型資料庫通常具備捕捉並儲存資訊的能力。不過目前的應用程式通常需要處理海量資料的讀取與寫入操作、且要求以近實時方式完成，這就超出了操作型資料庫的能力範圍。
NoSQL資料庫採取的模式則完全不同。從核心角度看，NoSQL資料庫真正實現了“NoREL”、也就是非關係型，也就是說此類方案在儲存並整理資訊的過程中並不依賴於表以及各個表之間的關係。舉例來說，一套面向文件的NoSQL資料庫會首先獲取到我們需要的資料，而後將其整合成採用JSON格式的文件。每個JSON文件都可以被視為能供應用程式使用的物件。JSON文件可以把原本需要25個關係型資料庫表才能存放的資料儲存在同一行當中，並將其整理為單一文件/物件。
資訊彙總工作可能導致資訊內容出現重複，不過由於目前儲存資源已經不再屬於主要成本來源，因此這類資料模型能夠帶來更出色的靈活性、便於高效分配由此產生的文件並改進讀取與寫入操作的效能表現、從而提升Web應用程式的替代性效果。
* NoSQL是支撐大資料應用的關鍵所在
時至今日，我們已經能夠愈發便捷地通過第三方環境、包括社交媒體網站對資料進行捕捉與訪問。個人使用者資訊、地理位置資料、使用者產生的內容、裝置登入資料以及感測器資料等只是這股風潮當中的少數典型代表，資料來源清單正在不斷擴充。同時，企業也越來越依賴大資料技術的力量、旨在驅動其關鍵性業務應用。總體而言，各企業已經開始向NoSQL伸出橄欖枝，因為這類方案是惟一能夠適應當前新興資料型別的處理手段。
開發人員需要一套更為靈活、能夠輕鬆適應最新資料型別的資料庫方案，從而避免破壞第三方資料供應商所提供的內容結構調整。大部分新型資料屬於非結構化或者半結構化型別，因此開發人員還需要自己的資料庫有能力高效對其加以儲存。遺憾的是，關係型資料庫所採取的嚴格定義、以模式為基礎的設計思路令我們無法快速接納全新資料型別，自然也難以適應非結構化及半結構化資料。NoSQL帶來的資料模型則能夠更好地與其實際需求加以對映。
總體來說，隨著Web與移動應用程式的不斷普及、新興趨勢的推波助瀾外加面向線上消費者行為與新型資料類別的轉變，業界中的各類流程方案都渴望著一種能夠為資料的管理及訪問帶來可擴充套件性與靈活性的資料庫技術。在這樣的背景下，NoSQL技術正是能夠有效滿足上述需求的惟一解決方案。
Network World網站主編John Dix專門組織了此次辯論並邀請到多位專家。其中兩位參與專家分別是VoltDB公司CTO Ryan Betts和Couchbase公司CEO Bob Wiederhold。Ryan Betts認為SQL已經在大型企業當中贏得了穩定的生存空間，而大資料只不過是SQL需要支撐的另一項工作內容。Bob Wiederhold則認為NoSQL是一套極具可行性的備選方案，事實上它也在多個領域中成為大資料的卓越配合手段——特別是在可擴充套件性方面。
結構化查詢語言(簡稱SQL)幾十年來已經用累累戰果以及赫赫聲名證明了自身實力，而且目前仍在繼續投身於多家大資料廠商及相關企業當中，其中包括谷歌、Facebook、Cloudera以及Apache。
雖然後起之秀NoSQL確實引起了一定反響，但SQL仍然在市場上保持著顯著的份額優勢並繼續在大資料領域不斷贏得投入與採納。
一旦某種技術像SQL這樣取得了主導地位，人們往往會忘記其最為核心的競爭優勢。SQL之所以能夠勝出，主要在於它擁有以下一系列獨特的優勢組合：
1. SQL能夠加強與資料之間的互動，允許使用者針對單一資料庫設計提出內容廣泛的問題。這正是SQL成功的關鍵所在——如果資料不具備互動性、則基本上將失去實用性。而持續增長的互動性又能為資料庫的未來發展帶來新的審視角度、相關問題以及實際意義。
2. SQL具備標準化特性，允許使用者自由運用源自各類系統的專業知識、同時支援第三方外掛及工具。
3. SQL具備擴充套件性、功能豐富且經過實際驗證，能夠解決各類難題——包括以寫入為主導的快速事務處理以及涉及頻繁掃描的深層分析。
4. SQL能夠與資料表現及儲存機制順暢對接。某些SQL系統還支援JSON以及其它結構化物件格式，從而帶來優於NoSQL方案的效能表現及更多功能特性。
“NoSQL”這一表述其實並不準確，但在本次討論中，我採用了Rick Cattell博士為NoSQL總結出的定義，即“指那些能夠提供鍵/值儲存或者簡單記錄與索引等操作的系統，旨在為這些簡單操作提供垂直可擴充套件性。”
很明顯，目前市面上的很多新型資料庫彼此之間存在較大差異——準確掌握它們各自特性與深層機制給使用者來的便利與侷限是獲得專案部署成功的關鍵所在。NoSQL的核心特性使其更適合於解決特定問題。舉例來說，圖形資料庫更適合處理那些將資料根據關係而非傳統行或者文件形式加以組織的例項，而特定文字搜尋系統則比較擅長處理以實時方式查詢使用者輸入內容的情況。
在這裡，我打算概括性闡述SQL系統與簡單鍵/值乃至僅僅在儲存格式及可擴充套件性方面有所創新的JSON物件儲存系統相比，到底存在哪些差異與主要優勢。
* SQL帶來互動特性。SQL是一種宣告性查詢語言。使用者說出自己想要的內容(例如顯示出過去五年來，每年三月份購買量最大的客戶分別來自哪些地區)，資料庫則在內部組建出相關演算法並根據要求提取對應結果。相比之下，NoSQL孕育出的編碼創新成果MapReduce則是一種規程化查詢技術。MapReduce要求使用者不僅瞭解自己想要的結果，同時也需要提供獲取結果的具體執行方式。
雖然聽起來只是一種頗為枯燥的技術性差異，但這種特性仍然極為關鍵，原因有以下兩點：首先，宣告性SQL查詢能夠更為輕鬆地通過圖形化工具以及對報告生成器的簡單點選來建立。這種相對較低的使用門檻能夠幫助分析師、運營者、管理者以及其他不瞭解軟體程式設計知識的使用者享受其核心功能及成效。第二，對資料庫引擎使用內部資訊並選擇高效演算法的方式進行抽象化處理。即使物理層或者資料庫索引出現變動，優化演算法仍然能夠確切完成任務。相比之下，在過去的程式化系統當中、程式設計師需要重新審視現有處理方式並進行二次程式設計。這樣既帶來高昂成本，又很有可能導致意外錯誤。
市場對於這種本質差異倒是非常瞭然。早在2010年，谷歌就宣佈引入一套SQL方案以強化MapReduce，從而滿足內部使用者的實際需求。最近，Facebook則釋出了自己的SQL方案Presto，意在對其PB級別HDFS叢集資料進行查詢。根據Facebook方面的說法：“由於我們的資料倉儲規模已經增長至PB級別、業務需求也逐步發展，我們顯然需要一套經過優化的互動式系統以實現更低的查詢延遲。”除此之外，Cloudera正在HDFS以上建立自己的SQL方案Impala。前面提到的這一系列發展都立足於Hive——一套面向Hadoop、長期存在且得到廣泛採用的SQL外殼。
* SQL具備標準化特性。雖然供應商有時候會對自己的SQL介面進行特殊調整與定製，但從本質上講SQL核心仍然是一套標準化程度很高的方案，以ODBC以及JDBC為代表的其它規範同樣提供廣泛可用的、面向SQL系統的穩定介面。由此衍生出的管理及操作工具生態系統能夠幫助大家以SQL系統為基礎，實現應用程式的設計、監控、檢查、探索以及開發。
SQL使用者及程式設計師也因此得以重新使用自己積累自多種後端系統的API以及使用者介面知識，從而縮減應用程式開發時間。標準化特性還允許擁有宣告許可的第三方打造提取、轉換以及載入(簡稱ETL)工具，旨在幫助企業以流程化方式處理不同資料庫及系統之間的資料流。
* SQL具備可擴充套件性。有些朋友可能誤以為SQL必須通過犧牲效能的方式來獲得可擴充套件性，這其實是完全錯誤的。如上所述，Facebook打造了一款SQL介面對PB級別的資料加以查詢。SQL在執行ACID事務處理任務時同樣具備極快的速度表現。SQL為資料儲存及檢索機制提供的抽象化手段允許使用者以統一化方式完成處理工作，而且無需考慮具體任務型別以及資料規模;這使得SQL能夠高效執行在各類叢集化副本資料儲存體系之間。將SQL作為介面的作法不涉及雲建立、具體規模或者HA系統，而且SQL當中也沒有任何固有因素會對容錯性、高可用性以及複製能力產生限制。事實上，目前所有現代化SQL系統都能夠很好地支援雲體系中的橫向可擴充套件性、複製能力以及容錯性。
* SQL支援JSON。幾年之前，很多SQL系統開始將XML文件支援能力納入自身設計思路。時至今日，隨著JSON逐步成為主流資料交換格式之一，各SQL廠商也在積極為JSON提供支援。鑑於當下敏捷化程式設計流程以及對網際網路接入基礎設施正常執行時間的要求，結構化資料型別的支援能力已經成為不可或缺的重要一環。Oracle 12c、PostgreSQL 9.2、VoltDB以及其它各類資料庫方案都開始支援JSON——其效能基準水平普遍優於“原生”JSON NoSQL方案。
SQL將繼續在市場份額的爭奪戰中佔據主動，也將繼續吸引到更多投資方與採納者的支援。NoSQL資料庫在提供專有查詢語言或者簡單鍵-值語義的同時，卻無法從深入的技術層面帶來差異性，這無疑嚴重影響了其挑戰市場統治者的能力。現代SQL系統能夠在保持甚至超越原有可擴充套件性的同時，支援豐富的查詢語義、建立並培養使用者基礎、擴充生態系統整合效果並在企業環境內深化採納程度。
觀點二：NoSQL更適合大資料應用程式——Couchbase公司CEO Bob Wiederhold
目前已經有越來越多的企業開始將NoSQL視為關係型資料庫的一種可行性替代方案;特別是在大資料應用程式領域，很多企業使用者意識到規模化操作的實際表現要優於標準化叢集與商用伺服器所帶來的效果。除此之外，採用無模式化資料模型往往更適合當下各類不同資料的捕捉與處理工作。
不過對於操作型資料庫中的大資料而言，其設計主旨並非圍繞分析性工作所展開;操作型資料庫通常需要為無數使用者提供龐大的資料集，幫助他們進行持續性資料訪問並進行實時事務處理。用於操作並管理大資料內容的此類資料庫都具備龐大的規模，這也解釋了NoSQL特性的重要意義及其在大資料應用程式中扮演核心角色的原因。
* NoSQL是實現可擴充套件性的關鍵所在
技術行業在每一次迎來硬體發展的根本性轉變時，都必然經歷過渡拐點。在資料庫領域，這種由向上擴充套件轉為向外擴充套件架構的轉變也成為推動NoSQL快速成長的主要因素。關係型資料庫，其中包括由甲骨文及IBM等巨頭所打造的具體方案，專注於解決向上擴充套件難題。也就是說，它們採取集中式、全域性共享技術，只能通過新增價格更為昂貴的硬體裝置滿足擴充套件需求。
與之相反，NoSQL資料庫從設計思路上就考慮到了分散式特性，屬於徹頭徹尾聲的向外擴充套件技術。它們利用一系列分散式節點(構成一套整體叢集)來提供具備卓越彈性的擴充套件能力，從而幫助使用者隨意新增更多節點以應對持續增加的工作負載。
分散式向外擴充套件方案往往還會帶來低於向上擴充套件機制的使用成本。後者屬於一整套龐大、複雜、具備容錯性機制的伺服器體系，因此無論是設計、建造還是後期支援都會帶來高昂的成本支出。商用關係型資料庫的許可成本同樣不容忽視，因為其計費策略以單一伺服器為基本單位。在另一方面，NoSQL資料庫則通常屬於開源專案，以伺服器叢集為整體計費單位、價格也相比較低。
* NoSQL是實現靈活性的關鍵所在
關係型與NoSQL資料模型可謂完全不同。關係型模型需要將資料拆分成包含行與列的多個關聯性表，這些表通過同樣儲存在列中的外來鍵實現相互引用。
當使用者需要對一組資料進行查詢時，所需資訊必須由多個表中收集獲得——通常涉及數百種當下常用的企業應用程式——並將其加以整合，而後才能交付終端應用。與之相似，在寫入資料時、寫入流程需要加以協調並在執行過程中面向多個表。當資料量相對較小、向資料庫內匯入的速度並不太快的情況下，關係型資料庫通常具備捕捉並儲存資訊的能力。不過目前的應用程式通常需要處理海量資料的讀取與寫入操作、且要求以近實時方式完成，這就超出了操作型資料庫的能力範圍。
NoSQL資料庫採取的模式則完全不同。從核心角度看，NoSQL資料庫真正實現了“NoREL”、也就是非關係型，也就是說此類方案在儲存並整理資訊的過程中並不依賴於表以及各個表之間的關係。舉例來說，一套面向文件的NoSQL資料庫會首先獲取到我們需要的資料，而後將其整合成採用JSON格式的文件。每個JSON文件都可以被視為能供應用程式使用的物件。JSON文件可以把原本需要25個關係型資料庫表才能存放的資料儲存在同一行當中，並將其整理為單一文件/物件。
資訊彙總工作可能導致資訊內容出現重複，不過由於目前儲存資源已經不再屬於主要成本來源，因此這類資料模型能夠帶來更出色的靈活性、便於高效分配由此產生的文件並改進讀取與寫入操作的效能表現、從而提升Web應用程式的替代性效果。
* NoSQL是支撐大資料應用的關鍵所在
時至今日，我們已經能夠愈發便捷地通過第三方環境、包括社交媒體網站對資料進行捕捉與訪問。個人使用者資訊、地理位置資料、使用者產生的內容、裝置登入資料以及感測器資料等只是這股風潮當中的少數典型代表，資料來源清單正在不斷擴充。同時，企業也越來越依賴大資料技術的力量、旨在驅動其關鍵性業務應用。總體而言，各企業已經開始向NoSQL伸出橄欖枝，因為這類方案是惟一能夠適應當前新興資料型別的處理手段。
開發人員需要一套更為靈活、能夠輕鬆適應最新資料型別的資料庫方案，從而避免破壞第三方資料供應商所提供的內容結構調整。大部分新型資料屬於非結構化或者半結構化型別，因此開發人員還需要自己的資料庫有能力高效對其加以儲存。遺憾的是，關係型資料庫所採取的嚴格定義、以模式為基礎的設計思路令我們無法快速接納全新資料型別，自然也難以適應非結構化及半結構化資料。NoSQL帶來的資料模型則能夠更好地與其實際需求加以對映。
總體來說，隨著Web與移動應用程式的不斷普及、新興趨勢的推波助瀾外加面向線上消費者行為與新型資料類別的轉變，業界中的各類流程方案都渴望著一種能夠為資料的管理及訪問帶來可擴充套件性與靈活性的資料庫技術。在這樣的背景下，NoSQL技術正是能夠有效滿足上述需求的惟一解決方案。