創建數據庫的五個屬性

創建數據庫的五個屬性：比如學生表存學號，姓名、年齡、性別、班級等。

創新互聯建站是一家集網站建設,杜集企業網站建設,杜集品牌網站建設,網站定制,杜集網站建設報價,網絡營銷,網絡優化,杜集網站推廣為一體的創新建站企業，幫助傳統企業提升企業形象加強企業競爭力。可充分滿足這一群體相比中小企業更為豐富、高端、多元的互聯網需求。同時我們時刻保持專業、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們為更多的企業打造出實用型網站。

選擇開始菜單中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打開【SQL Server Management Studio】窗口，并使用Windows或 SQL Server身份驗證建立連接。

在【對象資源管理器】窗口中展開服務器，然后選擇【數據庫】節點，右鍵單擊【數據庫】節點，從彈出來的快捷菜單中選擇【新建數據庫】命令。

非關系型數據庫：

隨著近些年技術方向的不斷拓展，大量的NoSql數據庫如MongoDB、Redis、Memcache出于簡化數據庫結構、避免冗余、影響性能的表連接、摒棄復雜分布式的目的被設計。

指的是分布式的、非關系型的、不保證遵循ACID原則的數據存儲系統。NoSQL數據庫技術與CAP理論、一致性哈希算法有密切關系。所謂CAP理論，簡單來說就是一個分布式系統不可能滿足可用性、一致性與分區容錯性這三個要求。

以上內容參考：百度百科-數據庫

NoSQL如何實現數據的增刪改查？

package basic;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

public class JDBC {

public void findAll() {

try {

// 獲得數據庫驅動

//由于長時間不寫，驅動名和URL都忘記了，不知道對不對，你應該知道的，自己改一下的哈

String url = "jdbc:oracle:thin:@localhost:1521:XE";

String userName = "system";

String password = "system";

Class.forName("oracle.jdbc.driver.OracleDriver");

// 創建連接

Connection conn = DriverManager.getConnection(url, userName,

password);

// 新建發送sql語句的對象

Statement st = conn.createStatement();

// 執行sql

String sql = "select * from users";

ResultSet rs = st.executeQuery(sql);

// 處理結果

while(rs.next()){

//這個地方就是給你的封裝類屬性賦值

System.out.println("UserName："+rs.getString(0));

}

// 關閉連接

rs.close();

st.close();

conn.close();

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

public void delete(){

try {

//步驟還是那六個步驟，前邊的兩步是一樣的

String url = "jdbc:oracle:thin:@localhost:1521:XE";

String userName = "system";

String password = "system";

Class.forName("oracle.jdbc.driver.OracleDriver");

Connection conn = DriverManager.getConnection(url,userName,password);

//這里的發送sql語句的對象是PreparedStatement,成為預處理sql對象，因為按條件刪除是需要不定值的

String sql = "delete from users where id = ?";

PreparedStatement ps = conn.prepareStatement(sql);

ps.setInt(0, 1);

int row = ps.executeUpdate();

if(row!=0){

System.out.println("刪除成功！");

}

// 關閉連接

rs.close();

st.close();

conn.close();

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

}

newsql和nosql的區別和聯系

在大數據時代，“多種架構支持多類應用”成為數據庫行業應對大數據的基本思路，數據庫行業出現互為補充的三大陣營，適用于事務處理應用的OldSQL、適用于數據分析應用的NewSQL和適用于互聯網應用的NoSQL。但在一些復雜的應用場景中，單一數據庫架構都不能完全滿足應用場景對海量結構化和非結構化數據的存儲管理、復雜分析、關聯查詢、實時性處理和控制建設成本等多方面的需要，因此不同架構數據庫混合部署應用成為滿足復雜應用的必然選擇。不同架構數據庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構數據庫的混合應用部署進行介紹。

OldSQL+NewSQL 在數據中心類應用中混合部署

采用OldSQL+NewSQL模式構建數據中心，在充分發揮OldSQL數據庫的事務處理能力的同時，借助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優勢，以及面對海量數據時較強的擴展能力，滿足數據中心對當前“熱”數據事務型處理和海量歷史“冷”數據分析兩方面的需求。OldSQL+NewSQL模式在數據中心類應用中的互補作用體現在，OldSQL彌補了NewSQL不適合事務處理的不足，NewSQL彌補了OldSQL在海量數據存儲能力和處理性能方面的缺陷。

商業銀行數據中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數據庫滿足各業務系統數據的歸檔備份和事務型應用，NewSQL MPP數據庫集群對即席查詢、多維分析等應用提供高性能支持，并且通過MPP集群架構實現應對海量數據存儲的擴展能力。

商業銀行數據中心存儲架構

與傳統的OldSQL模式相比，商業銀行數據中心采用OldSQL+NewSQL混合搭建模式，數據加載性能提升3倍以上，即席查詢和統計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業務需求，可隨著數據量的增長采用集群方式構建存儲容量更大的數據中心。

OldSQL+NoSQL 在互聯網大數據應用中混合部署

在互聯網大數據應用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯網大數據應用對海量結構化和非結構化數據進行存儲和快速處理的需求。在諸如大型電子商務平臺、大型SNS平臺等互聯網大數據應用場景中，OldSQL在應用中負責高價值密度結構化數據的存儲和事務型處理，NoSQL在應用中負責存儲和處理海量非結構化的數據和低價值密度結構化數據。OldSQL+NoSQL模式在互聯網大數據應用中的互補作用體現在，OldSQL彌補了NoSQL在ACID特性和復雜關聯運算方面的不足，NoSQL彌補了OldSQL在海量數據存儲和非結構化數據處理方面的缺陷。

數據魔方是淘寶網的一款數據產品，主要提供行業數據分析、店鋪數據分析。淘寶數據產品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關系型數據庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關系表達能力，在應用中仍然占據著重要地位，目前存儲在MyFOX中的統計結果數據已經達到10TB，占據著數據魔方總數據量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL數據庫無法解決的全屬性選擇器等問題。

淘寶海量數據產品技術架構

基于OldSQL+NoSQL混合架構的特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，支持每天4000萬的查詢請求，平均響應時間在28毫秒，足以滿足未來一段時間內的業務增長需求。

NewSQL+NoSQL 在行業大數據應用中混合部署

行業大數據與互聯網大數據的區別在于行業大數據的價值密度更高，并且對結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等都比互聯網大數據有更高的要求。行業大數據應用場景主要是分析類應用，如：電信、金融、政務、能源等行業的決策輔助、預測預警、統計分析、經營分析等。

在行業大數據應用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結構化數據分析處理方面的優勢，以及NoSQL在非結構數據處理方面的優勢，實現NewSQL與NoSQL的功能互補，解決行業大數據應用對高價值結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等要求，以及對海量非結構化數據存儲和精確查詢的要求。在應用中，NewSQL承擔高價值密度結構化數據的存儲和分析處理工作，NoSQL承擔存儲和處理海量非結構化數據和不需要關聯分析、Ad-hoc查詢較少的低價值密度結構化數據的工作。

當前電信運營商在集中化BI系統建設過程中面臨著數據規模大、數據處理類型多等問題，并且需要應對大量的固定應用，以及占統計總數80%以上的突發性臨時統計(ad-hoc)需求。在集中化BI系統的建設中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優勢，及NoSQL在非結構化數據處理和海量數據存儲方面的優勢，實現高效低成本。

集中化BI系統數據存儲架構

集中化BI系統按照數據類型和處理方式的不同，將結構化數據和非結構化數據分別存儲在不同的系統中：非結構化數據在Hadoop平臺上存儲與處理;結構化、不需要關聯分析、Ad-hoc查詢較少的數據保存在NoSQL數據庫或Hadoop平臺;結構化、需要關聯分析或經常ad-hoc查詢的數據，保存在NewSQL MPP數據庫中，短期高價值數據放在高性能平臺，中長期放在低成本產品中。

結語

當前信息化應用的多樣性、復雜性，以及三種數據庫架構各自所具有的優勢和局限性，造成任何一種架構的數據庫都不能完全滿足應用需求，因此不同架構數據庫混合使用，從而彌補其他架構的不足成為必然選擇。根據應用場景采用不同架構數據庫進行組合搭配，充分發揮每種架構數據庫的特點和優勢，并且與其他架構數據庫形成互補，完全涵蓋應用需求，保證數據資源的最優化利用，將成為未來一段時期內信息化應用主要采用的解決方式。

目前在國內市場上，OldSQL主要為Oracle、IBM等國外數據庫廠商所壟斷，達夢、金倉等國產廠商仍處于追趕狀態;南大通用憑借國產新型數據庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。

什么是NoSQL數據庫？

2. 什么是NoSQL？

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。

（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 關系型數據庫與NoSQL的區別？

3.1 RDBMS

高度組織化結構化數據

結構化查詢語言（SQL）

數據和關系都存儲在單獨的表中。

數據操縱語言，數據定義語言

嚴格的一致性

基礎事務

ACID

關系型數據庫遵循ACID規則

事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：

A (Atomicity) 原子性

原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。

C (Consistency) 一致性

一致性也比較容易理解，也就是說數據庫要一直處于一致的狀態，事務的運行不會改變數據庫原本的一致性約束。

I (Isolation) 獨立性

所謂的獨立性是指并發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事務提交后，它所做的修改將會永久的保存在數據庫上，即使出現宕機也不會丟失。

3.2 NoSQL

代表著不僅僅是SQL

沒有聲明性查詢語言

沒有預定義的模式

鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫

最終一致性，而非ACID屬性

非結構化和不可預知的數據

CAP定理

高性能，高可用性和可伸縮性

分布式數據庫中的CAP原理(了解)

CAP定理：

Consistency(一致性), 數據一致更新，所有數據變動都是同步的

Availability(可用性), 好的響應性能

Partition tolerance(分區容錯性) 可靠性

P: 系統中任意信息的丟失或失敗不會影響系統的繼續運作。

定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。

CAP理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，

因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。

CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。

AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。

CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。

而由于當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。

所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

說明：C：強一致性 A：高可用性 P：分布式容忍性

舉例：

CA：傳統Oracle數據庫

AP：大多數網站架構的選擇

CP：Redis、Mongodb

注意：分布式架構的時候必須做出取舍。

一致性和可用性之間取一個平衡。多余大多數web應用，其實并不需要強一致性。

因此犧牲C換取P，這是目前分布式數據庫產品的方向。

4. 當下NoSQL的經典應用

當下的應用是 SQL 與 NoSQL 一起使用的。

代表項目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一臺；O 是指 Oracle 數據庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設備，也很貴的。

難點：

數據類型多樣性。

數據源多樣性和變化重構。

數據源改造而服務平臺不需要大面積重構。

NoSQL數據庫是否意味著缺乏安全性？

NoSQL薄弱的安全性會給企業帶來負面影響 。Imperva公司創始人兼CTO Amichai Shulman如是說。在新的一年中，無疑會有更多企業開始或籌劃部署NoSQL。方案落實后就會逐漸發現種種安全問題，因此早做準備才是正確的選擇。 作為傳統關系型數據庫的替代方案，NoSQL在查詢中并不使用SQL語言，而且允許用戶隨時變更數據屬性。此類數據庫以擴展性良好著稱，并能夠在需要大量應用程序與數據庫本身進行實時交互的交易處理任務中發揮性能優勢，Couchbase創始人兼產品部門高級副總裁James Phillips解釋稱：NoSQL以交易業務為核心。它更注重實時處理能力并且擅長直接對數據進行操作，大幅度促進了交互型軟件系統的發展。Phillips指出。其中最大的優勢之一是能夠隨時改變(在屬性方面)，由于結構性的弱化，修改過程非常便捷。 NoSQL最大優勢影響其安全性 NoSQL的關鍵性特色之一是其動態的數據模型，Shulman解釋道。我可以在其運作過程中加入新的屬性記錄。因此與這種結構相匹配的安全模型必須具備一定的前瞻性規劃。也就是說，它必須能夠了解數據庫引入的新屬性將引發哪些改變，以及新加入的屬性擁有哪些權限。然而這個層面上的安全概念目前尚不存在，根本沒有這樣的解決方案。 根據Phillips的說法，某些NoSQL開發商已經開始著手研發安全機制，至少在嘗試保護數據的完整性。在關系型數據庫領域，如果我們的數據組成不正確，那么它將無法與結構并行運作，換言之數據插入操作整體將宣告失敗。目前各種驗證規則與完整性檢查已經比較完善，而事實證明這些驗證機制都能在NoSQL中發揮作用。我們與其他人所推出的解決方案類似，都會在插入一條新記錄或是文檔型規則時觸發，并在執行過程中確保插入數據的正確性。 Shulman預計新用戶很快將在配置方面捅出大婁子，這并非因為IT工作人員的玩忽職守，實際上主要原因是NoSQL作為一項新技術導致大多數人對其缺乏足夠的知識基礎。Application Security研發部門TeamSHATTER的經理Alex Rothacker對上述觀點表示贊同。他指出，培訓的一大問題在于，大多數NoSQL的從業者往往屬于新生代IT人士，他們對于技術了解較多，但往往缺乏足夠的安全管理經驗。 如果他們從傳統關系型數據庫入手，那么由于強制性安全機制的完備，他們可以在使用中學習。但NoSQL，只有行家才能通過觀察得出正確結論，并在大量研究工作后找到一套完備的安全解決方案。因此可能有90%的從業者由于知識儲備、安全經驗或是工作時間的局限而無法做到這一點。 NoSQL需在安全性方面進行優化 盡管Phillips認同新技術與舊經驗之間存在差異，但企業在推廣NoSQL時加大對安全性的關注會起到很大程度的積極作用。他認為此類數據存儲機制與傳統關系類數據庫相比，其中包含著的敏感類信息更少，而且與企業網絡內部其它應用程序的接觸機會也小得多。 他們并不把這項新技術完全當成數據庫使用，正如我們在收集整理大量來自其它應用程序的業務類數據時，往往也會考慮將其作為企業數據存儲機制一樣，他補充道。當然，如果我打算研發一套具備某種特定功能的社交網絡、社交游戲或是某種特殊web應用程序，也很可能會將其部署于防火墻之下。這樣一來它不僅與應用程序緊密結合，也不會被企業中的其它部門所觸及。 但Rothacker同時表示，這種過度依賴周邊安全機制的數據庫系統也存在著極其危險的漏洞。一旦系統完全依附于周邊安全模型，那么驗證機制就必須相對薄弱，而且缺乏多用戶管理及數據訪問方面的安全保護。只要擁有高權限賬戶，我們幾乎能訪問存儲機制中的一切數據。舉例來說，Brian Sullivan就在去年的黑帽大會上演示了如何在完全不清楚數據具體內容的情況下，將其信息羅列出來甚至導出。 而根據nCircle公司CTO Tim ‘TK’ Keanini的觀點，即使是與有限的應用程序相關聯，NoSQL也很有可能被暴露在互聯網上。在缺少嚴密網絡劃分的情況下，它可能成為攻擊者窺探存儲數據的薄弱環節。因為NoSQL在設計上主要用于互聯網規模的部署，所以它很可能被直接連接到互聯網中，進而面臨大量攻擊行為。 其中發生機率最高的攻擊行為就是注入式攻擊，這也是一直以來肆虐于關系類數據庫領域的頭號公敵。盡管NoSQL沒有將SQL作為查詢語言，也并不代表它能夠免受注入式攻擊的威脅。雖然不少人宣稱SQL注入在NoSQL這邊不起作用，但其中的原理是完全一致的。攻擊者需要做的只是改變自己注入內容的語法形式，Rothacker解釋稱。也就是說雖然SQL注入不會出現，但JavaScript注入或者JSON注入同樣能威脅安全。 此外，攻擊者在籌劃對這類數據庫展開侵襲時，也很可能進一步優化自己的工具。不成熟的安全技術往往帶來這樣的窘境：需要花費大量時間學習如何保障其安全，但幾乎每個IT人士都能迅速掌握攻擊活動的組織方法。因此我認為攻擊者將會始終走在安全部署的前面，Shulman說道。遺憾的是搞破壞總比防范工作更容易，而我們已經看到不少NoSQL技術方面的公開漏洞，尤其是目前引起熱議的、以JSON注入為載體的攻擊方式。 NoSQL安全性并非其阻礙 然而，這一切都不應該成為企業使用NoSQL的阻礙，他總結道。我認為歸根結底，這應該算是企業的一種商業決策。只要這種選擇能夠帶來吸引力巨大的商業機遇，就要承擔一定風險，Shulman解釋道。但應該采取一定措施以盡量弱化這種風險。 舉例來說，鑒于數據庫對外部安全機制的依賴性，Rothacker建議企業積極考慮引入加密方案。他警告稱，企業必須對與NoSQL相對接的應用程序代碼仔細檢查。換言之，企業必須嚴格挑選負責此類項目部署的人選，確保將最好的人才用于這方面事務，Shulman表示。當大家以NoSQL為基礎編寫應用程序時，必須啟用有經驗的編程人員，因為客戶端軟件是抵擋安全問題的第一道屏障。切實為額外緩沖區的部署留出時間與預算，這能夠讓員工有閑暇反思自己的工作內容并盡量多顧及安全考量多想一點就是進步。綜上所述，這可能與部署傳統的關系類數據庫也沒什么不同。 具有諷刺意味的是，近年來數據庫應用程序在安全性方面的提升基本都跟數據庫本身沒什么關系，nCircle公司安全研究及開發部門總監Oliver Lavery如是說。

高性能 NoSQL

關系數據庫經過幾十年的發展，已經非常成熟，但同時也存在不足：

表結構是強約束的，業務變更時擴充很麻煩。

如果對大數據量的表進行統計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數據讀入內存。

全文搜索只能使用 Like 進行整表掃描，性能非常低。

針對這些不足，產生了不同的 NoSQL 解決方案，在某些場景下比關系數據庫更有優勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 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，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。

特點：

以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數據庫中會有很大的麻煩，而使用文檔數據庫則非常方便。

文檔數據庫的主要缺點：

關系數據庫是按行來存儲的，列式數據庫是按照列來存儲數據。

按行存儲的優勢：

在某些場景下，這些優勢就成為劣勢了，例如，計算超重人員的數據，只需要讀取體重這一列進行統計即可，但行式存儲會將整行數據讀取到內存中，很浪費。

而列式存儲中，只需要讀取體重這列的數據即可，I/O 將大大減少。

除了節省I/O，列式存儲還有更高的壓縮比，可以節省存儲空間。普通行式數據庫的壓縮比在 3:1 到 5:1 左右，列式數據庫在 8:1 到 30:1，因為單個列的數據相似度更高。

列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續空間中，而列式存儲將不同列存儲在不連續的空間。

一般將列式存儲應用在離線大數據分析統計場景，因為這時主要針對部分列進行操作，而且數據寫入后無須更新。

關系數據庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：

假設有一個交友網站，信息表如下：

需要匹配性別、地點、語言列。

需要匹配性別、地點、愛好列。

實際搜索中，各種排列組合非常多，關系數據庫很難支持。

全文搜索引擎是使用 倒排索引 技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：

所以特別適合根據關鍵詞來查詢文檔內容。

上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據實際需求進行選擇。

文章名稱：nosql的屬性,NoSQL數據庫具備這些特征
本文網址：http://vcdvsql.cn/article48/dsigpep.html

成都網站建設公司_創新互聯，為您提供響應式網站、網站策劃、網站排名、動態網站、關鍵詞優化、網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯