您好,對于你的遇到的問題,我很高興能為你提供幫助,我之前也遇到過喲,以下是我的個人看法,希望能幫助到你,若有錯誤,還望見諒!。鍵值對存儲是數(shù)據(jù)庫最簡單的組織形式。基本上全部的編程語言都帶有應用在內存中的鍵值對存儲。C++STL的映射容器(map container)和Java的HashMap以及Python的字典類型都是鍵值對存儲。鍵值對存儲通常都有例如以下接口:

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比南寧網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式南寧網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們,業(yè)務覆蓋南寧地區(qū)。費用合理售后完善,10余年實體公司更值得信賴。
Get( key ): 獲取之前存儲于某標示符“key”之下的一些數(shù)據(jù),或者“key”下沒有數(shù)據(jù)時報錯。
Set( key, value ): 將“value”存儲到存儲空間中某標示符“key”下。使得我們能夠通過調用同樣的“key”來訪問它。
假設“key”下已經(jīng)有了一些數(shù)據(jù),舊的數(shù)據(jù)將被替換。
Delete( key ): 刪除存儲在“key”下的數(shù)據(jù)。
大部分低層實現(xiàn)都是使用哈希表或者某種自平衡樹(比如B-樹或者紅黑樹)。有時候數(shù)據(jù)太大而不裝不進內存,或者必須維持數(shù)據(jù)謹防系統(tǒng)由于未知原因而崩潰。在這些情況下。就必須使用到文件系統(tǒng)。
鍵值對存儲是NoSQL運動的一部分。NoSQL將全部不使用基于關系型數(shù)據(jù)庫概念的數(shù)據(jù)庫系統(tǒng)組合在一起。
維基百科上的NoSQL詞條非常好的總結了這些數(shù)據(jù)庫的特征。
不使用SQL查詢語言
可不全面支持ACID(原子性、一致性、隔離性、持久性)。
可提供分布式、容錯強的結構非常感謝您的耐心觀看,如有幫助請采納,祝生活愉快!謝謝!
NoSQL,泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應用難題。
鍵值(Key-Value)存儲數(shù)據(jù)庫
這一類數(shù)據(jù)庫主要會使用到一個哈希表,這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。[3] 舉例如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存儲數(shù)據(jù)庫。
這部分數(shù)據(jù)庫通常是用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在,但是它們的特點是指向了多個列。這些列是由列家族來安排的。如:Cassandra, HBase, Riak.
文檔型數(shù)據(jù)庫
文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的,而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔,半結構化的文檔以特定的格式存儲,比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級版,允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如:CouchDB, MongoDb. 國內也有文檔型數(shù)據(jù)庫SequoiaDB,已經(jīng)開源。
圖形(Graph)數(shù)據(jù)庫
圖形結構的數(shù)據(jù)庫同其他行列以及剛性結構的SQL數(shù)據(jù)庫不同,它是使用靈活的圖形模型,并且能夠擴展到多個服務器上。NoSQL數(shù)據(jù)庫沒有標準的查詢語言(SQL),因此進行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。[2] 如:Neo4J, InfoGrid, Infinite Graph.
因此,我們總結NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用:1、數(shù)據(jù)模型比較簡單;2、需要靈活性更強的IT系統(tǒng);3、對數(shù)據(jù)庫性能要求較高;4、不需要高度的數(shù)據(jù)一致性;5、對于給定key,比較容易映射復雜值的環(huán)境。
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 {
// 獲得數(shù)據(jù)庫驅動
//由于長時間不寫,驅動名和URL都忘記了,不知道對不對,你應該知道的,自己改一下的哈
String url = "jdbc:oracle:thin:@localhost:1521:XE";
String userName = "system";
String password = "system";
Class.forName("oracle.jdbc.driver.OracleDriver");
// 創(chuàng)建連接
Connection conn = DriverManager.getConnection(url, userName,
password);
// 新建發(fā)送sql語句的對象
Statement st = conn.createStatement();
// 執(zhí)行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);
//這里的發(fā)送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();
}
}
}
一般將NoSQL數(shù)據(jù)庫分為四大類:鍵值(Key-Value)存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形(Graph)數(shù)據(jù)庫。它們的數(shù)據(jù)模型、優(yōu)缺點、典型應用場景。
鍵值(Key-Value)存儲數(shù)據(jù)庫Key指向Value的鍵值對,通常用hash表來實現(xiàn)查找速度快數(shù)據(jù)無結構化(通常只被當作字符串或者二進制數(shù)據(jù))內容緩存,主要用于處理大量數(shù)據(jù)的高訪問負載,也用于一些日志系統(tǒng)等。
列存儲數(shù)據(jù)庫,以列簇式存儲,將同一列數(shù)據(jù)存在一起查找速度快,可擴展性強,更容易進行分布式擴展功能相對局限分布式的文件系統(tǒng)。
文檔型數(shù)據(jù)庫,Key-Value對應的鍵值對,Value為結構化數(shù)據(jù),數(shù)據(jù)結構要求不嚴格,表結構可變(不需要像關系型數(shù)據(jù)庫一樣需預先定義表結構),查詢性能不高,而且缺乏統(tǒng)一的查詢語法,Web應用。
圖形(Graph)數(shù)據(jù)庫,圖結構,利用圖結構相關算法(如最短路徑尋址,N度關系查找等),很多時候需要對整個圖做計算才能得出需要的信息,而且這種結構不太好做分布式的集群方案,社交網(wǎng)絡,推薦系統(tǒng)等。
NoSQL數(shù)據(jù)庫有很多種,實現(xiàn)方式差別很大。有接近SQL查詢方式的,也有純粹的鍵值對查詢。
對于K-V型數(shù)據(jù)庫,比較典型的是Redis,系統(tǒng)提供了get、set之類的命令用于增刪改查。關鍵是鍵值對的鍵和值怎么設計。
什么是NoSQL
大家有沒有聽說過“NoSQL”呢?近年,這個詞極受關注。看到“NoSQL”這個詞,大家可能會誤以為是“No!SQL”的縮寫,并深感憤怒:“SQL怎么會沒有必要了呢?”但實際上,它是“Not Only SQL”的縮寫。它的意義是:適用關系型數(shù)據(jù)庫的時候就使用關系型數(shù)據(jù)庫,不適用的時候也沒有必要非使用關系型數(shù)據(jù)庫不可,可以考慮使用更加合適的數(shù)據(jù)存儲。
為彌補關系型數(shù)據(jù)庫的不足,各種各樣的NoSQL數(shù)據(jù)庫應運而生。
為了更好地了解本書所介紹的NoSQL數(shù)據(jù)庫,對關系型數(shù)據(jù)庫的理解是必不可少的。那么,就讓我們先來看一看關系型數(shù)據(jù)庫的歷史、分類和特征吧。
關系型數(shù)據(jù)庫簡史
1969年,埃德加?6?1弗蘭克?6?1科德(Edgar Frank Codd)發(fā)表了劃時代的論文,首次提出了關系數(shù)據(jù)模型的概念。但可惜的是,刊登論文的《IBM Research Report》只是IBM公司的內部刊物,因此論文反響平平。1970年,他再次在刊物《Communication of the ACM》上發(fā)表了題為“A Relational Model of Data for Large Shared Data banks”(大型共享數(shù)據(jù)庫的關系模型)的論文,終于引起了大家的關注。
科德所提出的關系數(shù)據(jù)模型的概念成為了現(xiàn)今關系型數(shù)據(jù)庫的基礎。當時的關系型數(shù)據(jù)庫由于硬件性能低劣、處理速度過慢而遲遲沒有得到實際應用。但之后隨著硬件性能的提升,加之使用簡單、性能優(yōu)越等優(yōu)點,關系型數(shù)據(jù)庫得到了廣泛的應用。
通用性及高性能
雖然本書是講解NoSQL數(shù)據(jù)庫的,但有一個重要的大前提,請大家一定不要誤解。這個大前提就是“關系型數(shù)據(jù)庫的性能絕對不低,它具有非常好的通用性和非常高的性能”。毫無疑問,對于絕大多數(shù)的應用來說它都是最有效的解決方案。
突出的優(yōu)勢
關系型數(shù)據(jù)庫作為應用廣泛的通用型數(shù)據(jù)庫,它的突出優(yōu)勢主要有以下幾點:
保持數(shù)據(jù)的一致性(事務處理)
由于以標準化為前提,數(shù)據(jù)更新的開銷很小(相同的字段基本上都只有一處)
可以進行JOIN等復雜查詢
存在很多實際成果和專業(yè)技術信息(成熟的技術)
這其中,能夠保持數(shù)據(jù)的一致性是關系型數(shù)據(jù)庫的最大優(yōu)勢。在需要嚴格保證數(shù)據(jù)一致性和處理完整性的情況下,用關系型數(shù)據(jù)庫是肯定沒有錯的。但是有些情況不需要JOIN,對上述關系型數(shù)據(jù)庫的優(yōu)點也沒有什么特別需要,這時似乎也就沒有必要拘泥于關系型數(shù)據(jù)庫了。
關系型數(shù)據(jù)庫的不足
不擅長的處理
就像之前提到的那樣,關系型數(shù)據(jù)庫的性能非常高。但是它畢竟是一個通用型的數(shù)據(jù)庫,并不能完全適應所有的用途。具體來說它并不擅長以下處理:
大量數(shù)據(jù)的寫入處理
為有數(shù)據(jù)更新的表做索引或表結構(schema)變更
字段不固定時應用
對簡單查詢需要快速返回結果的處理
。。。。。。
NoSQL數(shù)據(jù)庫
為了彌補關系型數(shù)據(jù)庫的不足(特別是最近幾年),NoSQL數(shù)據(jù)庫出現(xiàn)了。關系型數(shù)據(jù)庫應用廣泛,能進行事務處理和JOIN等復雜處理。相對地,NoSQL數(shù)據(jù)庫只應用在特定領域,基本上不進行復雜的處理,但它恰恰彌補了之前所列舉的關系型數(shù)據(jù)庫的不足之處。
易于數(shù)據(jù)的分散
如前所述,關系型數(shù)據(jù)庫并不擅長大量數(shù)據(jù)的寫入處理。原本關系型數(shù)據(jù)庫就是以JOIN為前提的,就是說,各個數(shù)據(jù)之間存在關聯(lián)是關系型數(shù)據(jù)庫得名的主要原因。為了進行JOIN處理,關系型數(shù)據(jù)庫不得不把數(shù)據(jù)存儲在同一個服務器內,這不利于數(shù)據(jù)的分散。相反,NoSQL數(shù)據(jù)庫原本就不支持JOIN處理,各個數(shù)據(jù)都是獨立設計的,很容易把數(shù)據(jù)分散到多個服務器上。由于數(shù)據(jù)被分散到了多個服務器上,減少了每個服務器上的數(shù)據(jù)量,即使要進行大量數(shù)據(jù)的寫入操作,處理起來也更加容易。同理,數(shù)據(jù)的讀入操作當然也同樣容易。
提升性能和增大規(guī)模
下面說一點題外話,如果想要使服務器能夠輕松地處理更大量的數(shù)據(jù),那么只有兩個選擇:一是提升性能,二是增大規(guī)模。下面我們來整理一下這兩者的不同。
首先,提升性能指的就是通過提升現(xiàn)行服務器自身的性能來提高處理能力。這是非常簡單的方法,程序方面也不需要進行變更,但需要一些費用。若要購買性能翻倍的服務器,需要花費的資金往往不只是原來的2倍,可能需要多達5到10倍。這種方法雖然簡單,但是成本較高。
另一方面,增大規(guī)模指的是使用多臺廉價的服務器來提高處理能力。它需要對程序進行變更,但由于使用廉價的服務器,可以控制成本。另外,以后只要依葫蘆畫瓢增加廉價服務器的數(shù)量就可以了。
不對大量數(shù)據(jù)進行處理的話就沒有使用的必要嗎?
NoSQL數(shù)據(jù)庫基本上來說為了“使大量數(shù)據(jù)的寫入處理更加容易(讓增加服務器數(shù)量更容易)”而設計的。但如果不是對大量數(shù)據(jù)進行操作的話,NoSQL數(shù)據(jù)庫的應用就沒有意義嗎?
答案是否定的。的確,它在處理大量數(shù)據(jù)方面很有優(yōu)勢。但實際上NoSQL數(shù)據(jù)庫還有各種各樣的特點,如果能夠恰當?shù)乩眠@些特點將會是非常有幫助。具體的例子將會在第2章和第3章進行介紹,這些用途將會讓你感受到利用NoSQL的好處。
希望順暢地對數(shù)據(jù)進行緩存(Cache)處理
希望對數(shù)組類型的數(shù)據(jù)進行高速處理
希望進行全部保存
多樣的NoSQL數(shù)據(jù)庫
NoSQL數(shù)據(jù)庫存在著“key-value存儲”、“文檔型數(shù)據(jù)庫”、“列存儲數(shù)據(jù)庫”等各種各樣的種類,每種數(shù)據(jù)庫又包含各自的特點。下一節(jié)讓我們一起來了解一下NoSQL數(shù)據(jù)庫的種類和特點。
NoSQL數(shù)據(jù)庫是什么
NoSQL說起來簡單,但實際上到底有多少種呢?我在提筆的時候,到NoSQL的官方網(wǎng)站上確認了一下,竟然已經(jīng)有122種了。另外官方網(wǎng)站上也介紹了本書沒有涉及到的圖形數(shù)據(jù)庫和對象數(shù)據(jù)庫等各個類別。不知不覺間,原來已經(jīng)出現(xiàn)了這么多的NoSQL數(shù)據(jù)庫啊。
本節(jié)將為大家介紹具有代表性的NoSQL數(shù)據(jù)庫。
key-value存儲
這是最常見的NoSQL數(shù)據(jù)庫,它的數(shù)據(jù)是以key-value的形式存儲的。雖然它的處理速度非常快,但是基本上只能通過key的完全一致查詢獲取數(shù)據(jù)。根據(jù)數(shù)據(jù)的保存方式可以分為臨時性、永久性和兩者兼具三種。
臨時性
memcached屬于這種類型。所謂臨時性就是 “數(shù)據(jù)有可能丟失”的意思。memcached把所有數(shù)據(jù)都保存在內存中,這樣保存和讀取的速度非常快,但是當memcached停止的時候,數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內存中,所以無法操作超出內存容量的數(shù)據(jù)(舊數(shù)據(jù)會丟失)。
在內存中保存數(shù)據(jù)
可以進行非常快速的保存和讀取處理
數(shù)據(jù)有可能丟失
永久性
Tokyo Tyrant、Flare、ROMA等屬于這種類型。和臨時性相反,所謂永久性就是“數(shù)據(jù)不會丟失”的意思。這里的key-value存儲不像memcached那樣在內存中保存數(shù)據(jù),而是把數(shù)據(jù)保存在硬盤上。與memcached在內存中處理數(shù)據(jù)比起來,由于必然要發(fā)生對硬盤的IO操作,所以性能上還是有差距的。但數(shù)據(jù)不會丟失是它最大的優(yōu)勢。
在硬盤上保存數(shù)據(jù)
可以進行非常快速的保存和讀取處理(但無法與memcached相比)
數(shù)據(jù)不會丟失
兩者兼具
Redis屬于這種類型。Redis有些特殊,臨時性和永久性兼具,且集合了臨時性key-value存儲和永久性key-value存儲的優(yōu)點。Redis首先把數(shù)據(jù)保存到內存中,在滿足特定條件(默認是15分鐘一次以上,5分鐘內10個以上,1分鐘內10000個以上的key發(fā)生變更)的時候將數(shù)據(jù)寫入到硬盤中。這樣既確保了內存中數(shù)據(jù)的處理速度,又可以通過寫入硬盤來保證數(shù)據(jù)的永久性。這種類型的數(shù)據(jù)庫特別適合于處理數(shù)組類型的數(shù)據(jù)。
同時在內存和硬盤上保存數(shù)據(jù)
可以進行非常快速的保存和讀取處理
保存在硬盤上的數(shù)據(jù)不會消失(可以恢復)
適合于處理數(shù)組類型的數(shù)據(jù)
面向文檔的數(shù)據(jù)庫
MongoDB、CouchDB屬于這種類型。它們屬于NoSQL數(shù)據(jù)庫,但與key-value存儲相異。
不定義表結構
面向文檔的數(shù)據(jù)庫具有以下特征:即使不定義表結構,也可以像定義了表結構一樣使用。關系型數(shù)據(jù)庫在變更表結構時比較費事,而且為了保持一致性還需修改程序。然而NoSQL數(shù)據(jù)庫則可省去這些麻煩(通常程序都是正確的),確實是方便快捷。
可以使用復雜的查詢條件
跟key-value存儲不同的是,面向文檔的數(shù)據(jù)庫可以通過復雜的查詢條件來獲取數(shù)據(jù)。雖然不具備事務處理和JOIN這些關系型數(shù)據(jù)庫所具有的處理能力,但除此以外的其他處理基本上都能實現(xiàn)。這是非常容易使用的NoSQL數(shù)據(jù)庫。
不需要定義表結構
可以利用復雜的查詢條件
面向列的數(shù)據(jù)庫
Cassandra、Hbase、HyperTable屬于這種類型。由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長,這種類型的NoSQL數(shù)據(jù)庫尤其引人注目。
面向行的數(shù)據(jù)庫和面向列的數(shù)據(jù)庫
普通的關系型數(shù)據(jù)庫都是以行為單位來存儲數(shù)據(jù)的,擅長進行以行為單位的讀入處理,比如特定條件數(shù)據(jù)的獲取。因此,關系型數(shù)據(jù)庫也被稱為面向行的數(shù)據(jù)庫。相反,面向列的數(shù)據(jù)庫是以列為單位來存儲數(shù)據(jù)的,擅長以列為單位讀入數(shù)據(jù)。
高擴展性
面向列的數(shù)據(jù)庫具有高擴展性,即使數(shù)據(jù)增加也不會降低相應的處理速度(特別是寫入速度),所以它主要應用于需要處理大量數(shù)據(jù)的情況。另外,利用面向列的數(shù)據(jù)庫的優(yōu)勢,把它作為批處理程序的存儲器來對大量數(shù)據(jù)進行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫跟現(xiàn)行數(shù)據(jù)庫存儲的思維方式有很大不同,應用起來十分困難。
高擴展性(特別是寫入處理)
應用十分困難
最近,像Twitter和Facebook這樣需要對大量數(shù)據(jù)進行更新和查詢的網(wǎng)絡服務不斷增加,面向列的數(shù)據(jù)庫的優(yōu)勢對其中一些服務是非常有用的,但是由于這與本書所要介紹的內容關系不大,就不進行詳細介紹了。
總結:
NoSQL并不是No-SQL,而是指Not Only SQL。
NoSQL的出現(xiàn)是為了彌補SQL數(shù)據(jù)庫因為事務等機制帶來的對海量數(shù)據(jù)、高并發(fā)請求的處理的性能上的欠缺。
NoSQL不是為了替代SQL而出現(xiàn)的,它是一種替補方案,而不是解決方案的首選。
絕大多數(shù)的NoSQL產品都是基于大內存和高性能隨機讀寫的(比如具有更高性能的固態(tài)硬盤陣列),一般的小型企業(yè)在選擇NoSQL時一定要慎重!不要為了NoSQL而NoSQL,可能會導致花了冤枉錢又耽擱了項目進程。
NoSQL不是萬能的,但在大型項目中,你往往需要它!
網(wǎng)頁名稱:nosql獲得key的值,采用keyvalue模型的nosql數(shù)據(jù)庫
網(wǎng)站地址:http://chinadenli.net/article37/dsicipj.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供App開發(fā)、網(wǎng)站導航、品牌網(wǎng)站制作、網(wǎng)站營銷、軟件開發(fā)、商城網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)