package basic;

從事綿陽電信機(jī)房機(jī)柜租用,服務(wù)器租用,云主機(jī),網(wǎng)站空間,域名與空間,CDN,網(wǎng)絡(luò)代維等服務(wù)。
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ù)庫驅(qū)動(dòng)
//由于長時(shí)間不寫,驅(qū)動(dòng)名和URL都忘記了,不知道對(duì)不對(duì),你應(yīng)該知道的,自己改一下的哈
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語句的對(duì)象
Statement st = conn.createStatement();
// 執(zhí)行sql
String sql = "select * from users";
ResultSet rs = st.executeQuery(sql);
// 處理結(jié)果
while(rs.next()){
//這個(gè)地方就是給你的封裝類屬性賦值
System.out.println("UserName:"+rs.getString(0));
}
// 關(guān)閉連接
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 {
//步驟還是那六個(gè)步驟,前邊的兩步是一樣的
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語句的對(duì)象是PreparedStatement,成為預(yù)處理sql對(duì)象,因?yàn)榘礂l件刪除是需要不定值的
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("刪除成功!");
}
// 關(guān)閉連接
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太火,冒出太多產(chǎn)品了,保守估計(jì)也成百上千了。
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種,每種只舉一個(gè)比較常見或者應(yīng)用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同時(shí)提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運(yùn)算的能力,成功用法是替代memcached,通過checkpoint和commit log提供了快速的宕機(jī)恢復(fù),同時(shí)支持replication提供讀可擴(kuò)展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單,數(shù)據(jù)量不受限于內(nèi)存大小,數(shù)據(jù)落盤高可靠,Google的幾位大神出品的精品,LSM模型天然寫優(yōu)化,順序?qū)懕P的方式對(duì)于新硬件ssd再適合不過了,不足是僅提供了一個(gè)庫,需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql,具備了區(qū)別mysql的最大亮點(diǎn):可擴(kuò)展性。mongodb 最新引人的莫過于提供了sql接口,是目前nosql里最像mysql的,只是沒有ACID的特性,發(fā)展很快,支持了索引等特性,上手容易,對(duì)于數(shù)據(jù)量遠(yuǎn)超內(nèi)存限制的場景來說,還需要慎重。
4. Column Table Store: HBase
這個(gè)富二代似乎不用贅述了,最大的優(yōu)勢(shì)是開源,對(duì)于普通的scan和基于行的get等基本查詢,性能完全不是問題,只是只提供裸的api,易用性上是短板,可擴(kuò)展性方面是最強(qiáng)的,其次坐上了Hadoop的快車,社區(qū)發(fā)展很快,各種基于其上的開源產(chǎn)品不少,來解決諸如join、聚集運(yùn)算等復(fù)雜查詢。
1、性能
都比較高,性能對(duì)我們來說應(yīng)該都不是瓶頸。
總體來講,TPS 方面 redis 和 memcache 差不多,要大于 mongodb。
2、操作的便利性
memcache 數(shù)據(jù)結(jié)構(gòu)單一。(key-value)
redis 豐富一些,數(shù)據(jù)操作方面,redis 更好一些,較少的網(wǎng)絡(luò) IO 次數(shù),同時(shí)還提供 list,set,
hash 等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
mongodb 支持豐富的數(shù)據(jù)表達(dá),索引,最類似關(guān)系型數(shù)據(jù)庫,支持的查詢語言非常豐富。
3、內(nèi)存空間的大小和數(shù)據(jù)量的大小
redis 在 2.0 版本后增加了自己的 VM 特性,突破物理內(nèi)存的限制;可以對(duì) key value 設(shè)置過
期時(shí)間(類似 memcache)
memcache 可以修改最大可用內(nèi)存,采用 LRU 算法。Memcached 代理軟件 magent,比如建立
10 臺(tái) 4G 的 Memcache 集群,就相當(dāng)于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 適合大數(shù)據(jù)量的存儲(chǔ),依賴操作系統(tǒng) VM 做內(nèi)存管理,吃內(nèi)存也比較厲害,服務(wù)
不要和別的服務(wù)在一起。
4、可用性(單點(diǎn)問題)
對(duì)于單點(diǎn)問題,
redis,依賴客戶端來實(shí)現(xiàn)分布式讀寫;主從復(fù)制時(shí),每次從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)都要依賴整
個(gè)快照,無增量復(fù)制,因性能和效率問題,
所以單點(diǎn)問題比較復(fù)雜;不支持自動(dòng) sharding,需要依賴程序設(shè)定一致 hash 機(jī)制。
一種替代方案是,不用 redis 本身的復(fù)制機(jī)制,采用自己做主動(dòng)復(fù)制(多份存儲(chǔ)),或者改成
增量復(fù)制的方式(需要自己實(shí)現(xiàn)),一致性問題和性能的權(quán)衡
Memcache 本身沒有數(shù)據(jù)冗余機(jī)制,也沒必要;對(duì)于故障預(yù)防,采用依賴成熟的 hash 或者環(huán)
狀的算法,解決單點(diǎn)故障引起的抖動(dòng)問題。
mongoDB 支持 master-slave,replicaset(內(nèi)部采用 paxos 選舉算法,自動(dòng)故障恢復(fù)),auto sharding 機(jī)制,對(duì)客戶端屏蔽了故障轉(zhuǎn)移和切分機(jī)制。
5、可靠性(持久化)
對(duì)于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù),
redis 支持(快照、AOF):依賴快照進(jìn)行持久化,aof 增強(qiáng)了可靠性的同時(shí),對(duì)性能有所影
響
memcache 不支持,通常用在做緩存,提升性能;
MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性
6、數(shù)據(jù)一致性(事務(wù)支持)
Memcache 在并發(fā)場景下,用 cas 保證一致性redis 事務(wù)支持比較弱,只能保證事務(wù)中的每個(gè)操作連續(xù)執(zhí)行
mongoDB 不支持事務(wù)
7、數(shù)據(jù)分析
mongoDB 內(nèi)置了數(shù)據(jù)分析的功能(mapreduce),其他不支持
8、應(yīng)用場景
redis:數(shù)據(jù)量較小的更性能操作和運(yùn)算上
memcache:用于在動(dòng)態(tài)系統(tǒng)中減少數(shù)據(jù)庫負(fù)載,提升性能;做緩存,提高性能(適合讀多寫
少,對(duì)于數(shù)據(jù)量比較大,可以采用 sharding)
MongoDB:主要解決海量數(shù)據(jù)的訪問效率問題。
表格比較:
memcache redis 類型 內(nèi)存數(shù)據(jù)庫 內(nèi)存數(shù)據(jù)庫
數(shù)據(jù)類型 在定義 value 時(shí)就要固定數(shù)據(jù)類型 不需要
有字符串,鏈表,集 合和有序集合
虛擬內(nèi)存 不支持 支持
過期策略 支持 支持
分布式 magent master-slave,一主一從或一主多從
存儲(chǔ)數(shù)據(jù)安全 不支持 使用 save 存儲(chǔ)到 dump.rdb 中
災(zāi)難恢復(fù) 不支持 append only file(aof)用于數(shù)據(jù)恢復(fù)
性能
1、類型——memcache 和 redis 都是將數(shù)據(jù)存放在內(nèi)存,所以是內(nèi)存數(shù)據(jù)庫。當(dāng)然,memcache 也可用于緩存其他東西,例如圖片等等。
2、 數(shù)據(jù)類型——Memcache 在添加數(shù)據(jù)時(shí)就要指定數(shù)據(jù)的字節(jié)長度,而 redis 不需要。
3、 虛擬內(nèi)存——當(dāng)物理內(nèi)存用完時(shí),可以將一些很久沒用到的 value 交換到磁盤。
4、 過期策略——memcache 在 set 時(shí)就指定,例如 set key1 0 0 8,即永不過期。Redis 可以通
過例如 expire 設(shè)定,例如 expire name 10。
5、 分布式——設(shè)定 memcache 集群,利用 magent 做一主多從;redis 可以做一主多從。都可
以一主一從。
6、 存儲(chǔ)數(shù)據(jù)安全——memcache 斷電就斷了,數(shù)據(jù)沒了;redis 可以定期 save 到磁盤。
7、 災(zāi)難恢復(fù)——memcache 同上,redis 丟了后可以通過 aof 恢復(fù)。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 啟動(dòng)一個(gè)守護(hù)進(jìn)程
-p 端口
-m 分配的內(nèi)存是 M
-c 最大運(yùn)行并發(fā)數(shù)-P memcache 的 pid
//0 壓縮(是否 MEMCACHE_COMPRESSED) 30 秒失效時(shí)間
//delete 5 是 timeout
文檔數(shù)據(jù)庫
源起:受Lotus Notes啟發(fā)。
數(shù)據(jù)模型:包含了key-value的文檔集合
例子:CouchDB, MongoDB
優(yōu)點(diǎn):數(shù)據(jù)模型自然,編程友好,快速開發(fā),web友好,CRUD。
圖數(shù)據(jù)庫
源起: 歐拉和圖理論。
數(shù)據(jù)模型:節(jié)點(diǎn)和關(guān)系,也可處理鍵值對(duì)。
例子:AllegroGraph, InfoGrid, Neo4j
優(yōu)點(diǎn):解決復(fù)雜的圖問題。
關(guān)系數(shù)據(jù)庫
源起: E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
數(shù)據(jù)模型:各種關(guān)系
例子:VoltDB, Clustrix, MySQL
優(yōu)點(diǎn):高性能、可擴(kuò)展的OLTP,支持SQL,物化視圖,支持事務(wù),編程友好。
對(duì)象數(shù)據(jù)庫
源起:圖數(shù)據(jù)庫研究
數(shù)據(jù)模型:對(duì)象
例子:Objectivity, Gemstone
優(yōu)點(diǎn):復(fù)雜對(duì)象模型,快速鍵值訪問,鍵功能訪問,以及圖數(shù)據(jù)庫的優(yōu)點(diǎn)。
Key-Value數(shù)據(jù)庫
源起:Amazon的論文 Dynamo 和 Distributed HashTables。
數(shù)據(jù)模型:鍵值對(duì)
例子:Membase, Riak
優(yōu)點(diǎn):處理大量數(shù)據(jù),快速處理大量讀寫請(qǐng)求。編程友好。
BigTable類型數(shù)據(jù)庫
源起:Google的論文 BigTable。
數(shù)據(jù)模型:列簇,每一行在理論上都是不同的
例子:HBase, Hypertable, Cassandra
優(yōu)點(diǎn):處理大量數(shù)據(jù),應(yīng)對(duì)極高寫負(fù)載,高可用,支持跨數(shù)據(jù)中心, MapReduce。
數(shù)據(jù)結(jié)構(gòu)服務(wù)
源起: ?
數(shù)據(jù)模型:字典操作,lists, sets和字符串值
例子:Redis
優(yōu)點(diǎn):不同于以前的任何數(shù)據(jù)庫
網(wǎng)格數(shù)據(jù)庫
源起:數(shù)據(jù)網(wǎng)格和元組空間研究。
數(shù)據(jù)模型:基于空間的架構(gòu)
例子:GigaSpaces, Coherence
優(yōu)點(diǎn):適于事務(wù)處理的高性能和高擴(kuò)展性
而傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,例如:
1、High performance - 對(duì)數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來實(shí)時(shí)生成動(dòng)態(tài)頁面和提供動(dòng)態(tài)信息,所以基本上無法使用動(dòng)態(tài)頁面靜態(tài)化技術(shù),因此數(shù)據(jù)庫并發(fā)負(fù)載非常高,往往要達(dá)到每秒上萬次讀寫請(qǐng)求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強(qiáng)頂?shù)米。菓?yīng)付上萬次SQL寫數(shù)據(jù)請(qǐng)求,硬盤IO就已經(jīng)無法承受了。其實(shí)對(duì)于普通的BBS網(wǎng)站,往往也存在對(duì)高并發(fā)寫請(qǐng)求的需求。
2、Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問的需求
對(duì)于大型的SNS網(wǎng)站,每天用戶產(chǎn)生海量的用戶動(dòng)態(tài),以國外的Friendfeed為例,一個(gè)月就達(dá)到了2.5億條用戶動(dòng)態(tài),對(duì)于關(guān)系數(shù)據(jù)庫來說,在一張2.5億條記錄的表里面進(jìn)行SQL查詢,效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng),例如騰訊,盛大,動(dòng)輒數(shù)以億計(jì)的帳號(hào),關(guān)系數(shù)據(jù)庫也很難應(yīng)付。
3、High Scalability High Availability- 對(duì)數(shù)據(jù)庫的高可擴(kuò)展性和高可用性的需求
在基于web的架構(gòu)當(dāng)中,數(shù)據(jù)庫是最難進(jìn)行橫向擴(kuò)展的,當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時(shí)候,你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來說,對(duì)數(shù)據(jù)庫系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情,往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移,為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢?
在上面提到的“三高”需求面前,關(guān)系數(shù)據(jù)庫遇到了難以克服的障礙,而對(duì)于web2.0網(wǎng)站來說,關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地,例如:
1、數(shù)據(jù)庫事務(wù)一致性需求
很多web實(shí)時(shí)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù),對(duì)讀一致性的要求很低,有些場合對(duì)寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理成了數(shù)據(jù)庫高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。
2、數(shù)據(jù)庫的寫實(shí)時(shí)性和讀實(shí)時(shí)性需求
對(duì)關(guān)系數(shù)據(jù)庫來說,插入一條數(shù)據(jù)之后立刻查詢,是肯定可以讀出來這條數(shù)據(jù)的,但是對(duì)于很多web應(yīng)用來說,并不要求這么高的實(shí)時(shí)性。
3、對(duì)復(fù)雜的SQL查詢,特別是多表關(guān)聯(lián)查詢的需求
任何大數(shù)據(jù)量的web系統(tǒng),都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢,以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報(bào)表查詢,特別是SNS類型的網(wǎng)站,從需求以及產(chǎn)品設(shè)計(jì)角度,就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。
因此,關(guān)系數(shù)據(jù)庫在這些越來越多的應(yīng)用場景下顯得不那么合適了,為了解決這類問題的非關(guān)系數(shù)據(jù)庫應(yīng)運(yùn)而生。
NoSQL 是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu),通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢(shì)。該術(shù)語在 2009 年初得到了廣泛認(rèn)同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲(chǔ)在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲(chǔ)就是為了實(shí)現(xiàn)這個(gè)需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實(shí)現(xiàn)。一些開源的 NoSQL 體系,如Facebook 的Cassandra, Apache 的HBase,也得到了廣泛認(rèn)同。
NoSQL,泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題。
雖然NoSQL流行語火起來才短短一年的時(shí)間,但是不可否認(rèn),現(xiàn)在已經(jīng)開始了第二代運(yùn)動(dòng)。盡管早期的堆棧代碼只能算是一種實(shí)驗(yàn),然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個(gè)嚴(yán)酷的事實(shí):技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲(chǔ)不得不進(jìn)行重寫,也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的工具,可以為大數(shù)據(jù)建立快速、可擴(kuò)展的存儲(chǔ)庫。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項(xiàng)全新的數(shù)據(jù)庫革命性運(yùn)動(dòng),早期就有人提出,發(fā)展至2009年趨勢(shì)越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲(chǔ),相對(duì)于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運(yùn)用,這一概念無疑是一種全新的思維的注入。
對(duì)于NoSQL并沒有一個(gè)明確的范圍和定義,但是他們都普遍存在下面一些共同特征:
不需要預(yù)定義模式:不需要事先定義數(shù)據(jù)模式,預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時(shí),并不需要預(yù)先定義它們的模式。
無共享架構(gòu):相對(duì)于將所有數(shù)據(jù)存儲(chǔ)的存儲(chǔ)區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲(chǔ)在各個(gè)本地服務(wù)器上。因?yàn)閺谋镜卮疟P讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能,從而提高了系統(tǒng)的性能。
彈性可擴(kuò)展:可以在系統(tǒng)運(yùn)行的時(shí)候,動(dòng)態(tài)增加或者刪除結(jié)點(diǎn)。不需要停機(jī)維護(hù),數(shù)據(jù)可以自動(dòng)遷移。
分區(qū):相對(duì)于將數(shù)據(jù)存放于同一個(gè)節(jié)點(diǎn),NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進(jìn)行分區(qū),將記錄分散在多個(gè)節(jié)點(diǎn)上面。并且通常分區(qū)的同時(shí)還要做復(fù)制。這樣既提高了并行性能,又能保證沒有單點(diǎn)失效的問題。
異步復(fù)制:和RAID存儲(chǔ)系統(tǒng)不同的是,NoSQL中的復(fù)制,往往是基于日志的異步復(fù)制。這樣,數(shù)據(jù)就可以盡快地寫入一個(gè)節(jié)點(diǎn),而不會(huì)被網(wǎng)絡(luò)傳輸引起遲延。缺點(diǎn)是并不總是能保證一致性,這樣的方式在出現(xiàn)故障的時(shí)候,可能會(huì)丟失少量的數(shù)據(jù)。
BASE:相對(duì)于事務(wù)嚴(yán)格的ACID特性,NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。
NoSQL數(shù)據(jù)庫并沒有一個(gè)統(tǒng)一的架構(gòu),兩種NoSQL數(shù)據(jù)庫之間的不同,甚至遠(yuǎn)遠(yuǎn)超過兩種關(guān)系型數(shù)據(jù)庫的不同。可以說,NoSQL各有所長,成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用,在這些場合中會(huì)遠(yuǎn)遠(yuǎn)勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。
當(dāng)前標(biāo)題:兩種nosql的常用操作,NoSQL的三大基石?
瀏覽路徑:http://chinadenli.net/article24/dsgdcje.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站導(dǎo)航、品牌網(wǎng)站設(shè)計(jì)、外貿(mào)建站、網(wǎng)站內(nèi)鏈、全網(wǎng)營銷推廣、用戶體驗(yàn)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)