建站
咨詢
售后
建站咨詢
新聞中心
NoSQL會(huì)取代SQL數(shù)據(jù)庫(kù)嗎
對(duì)此，前Google工程師，Milo（本地商店搜索引擎）創(chuàng)始人Ted Dziuba最近發(fā)表標(biāo)題驚人的博客“I Can't Wait for NoSQL to Die”，對(duì)NoSQL的適用范圍進(jìn)行了分析。他認(rèn)為，
創(chuàng)新互聯(lián)是一家專注于網(wǎng)站建設(shè)、成都做網(wǎng)站與策劃設(shè)計(jì),順義網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)10多年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:順義等地區(qū)。順義做網(wǎng)站價(jià)格咨詢:028-86922220
NoSQL也會(huì)帶來(lái)一連串的新問(wèn)題，并不會(huì)成為主流，無(wú)法取代關(guān)系型數(shù)據(jù)庫(kù)。
他的理由是：Cassandra等NoSQL數(shù)據(jù)庫(kù)在使用上并不方便，比如，修改column family定義時(shí)就需要重啟。而且NoSQL更適合Google那樣的規(guī)模，而一般的互聯(lián)網(wǎng)公司都不是Google，早早地去考慮Google那樣的規(guī)模的可擴(kuò)展性，純粹是浪費(fèi)時(shí)間，存在巨大的商業(yè)風(fēng)險(xiǎn)。
他還透露，即使在Google，AdWords這樣的關(guān)鍵產(chǎn)品也是基于MySQL實(shí)現(xiàn)的。
他在文中最后表示，NoSQL當(dāng)然死不了，但是
它最終會(huì)被邊緣化，就像Rails被NoSQL邊緣化一樣
Dziuba的文章因?yàn)檠赞o激烈，在社區(qū)里引起了強(qiáng)烈反應(yīng)。
SQL數(shù)據(jù)庫(kù)陣營(yíng)贊同者大有人在。craigslist工程師、著名的MySQL專家Jeremy Zawodny表示，在讀此文的時(shí)候，不時(shí)會(huì)心一笑。他說(shuō)，
NoSQL運(yùn)動(dòng)只是軟件不斷進(jìn)化進(jìn)程中的正?，F(xiàn)象
。關(guān)系型數(shù)據(jù)庫(kù)也會(huì)繼續(xù)發(fā)展，MySQL社區(qū)不斷推出的XtraDB或InnoDB插件, PBXT, Drizzle都是證據(jù)。各種技術(shù)競(jìng)爭(zhēng)的結(jié)果是，我們獲得了更多解決問(wèn)題的選擇。
drizzle項(xiàng)目開(kāi)發(fā)者Eric Day也表示，NoSQL有很多值得學(xué)習(xí)的，但是目前大部分實(shí)際項(xiàng)目的最佳選擇還是關(guān)系型數(shù)據(jù)庫(kù)。
NoSQL陣營(yíng)當(dāng)然不會(huì)坐視不理，Cassandra項(xiàng)目組的Eric Evans表示，Dziuba提到Cassandra修改column family定義的問(wèn)題其實(shí)很容易解決。而且，NoSQL并不是要取代MySQL，事實(shí)上Twitter仍然在用MySQL。如果關(guān)系型數(shù)據(jù)庫(kù)能夠承擔(dān)負(fù)荷，那就用好了；如果不行，請(qǐng)考慮NoSQL。
而德國(guó)知名博客Code Monkeyism則嘲笑Dziuba看起來(lái)并沒(méi)有用MySQL做過(guò)真實(shí)項(xiàng)目，因?yàn)镸ySQL如果沒(méi)有memcache，基本上無(wú)法應(yīng)付網(wǎng)站項(xiàng)目。他認(rèn)為，NoSQL將使SQL數(shù)據(jù)庫(kù)邊緣化，而且一個(gè)重要理由恰恰是可以節(jié)省DBA的開(kāi)銷。
digg的前任首席架構(gòu)師現(xiàn)在也在創(chuàng)業(yè)的Joe Stump說(shuō)，自己現(xiàn)在的創(chuàng)業(yè)項(xiàng)目就是用NoSQL，而且列舉了一系列問(wèn)題挑戰(zhàn)SQL陣營(yíng)。
衡量數(shù)據(jù)庫(kù)性能的重要指標(biāo)
具體來(lái)說(shuō)，本文包括以下內(nèi)容:
事務(wù)
查詢性能
用戶和查詢沖突
容量
配置
NoSQL 數(shù)據(jù)庫(kù)
事務(wù)
事務(wù)可以觀察真實(shí)用戶的行為：能夠在應(yīng)用交互時(shí)捕獲實(shí)時(shí)性能。眾所周知，測(cè)量事務(wù)的性能包括獲取整個(gè)事務(wù)的響應(yīng)時(shí)間和組成事務(wù)的各個(gè)部分的響應(yīng)時(shí)間。通常我們可以用這些響應(yīng)時(shí)間與滿足事務(wù)需求的基線對(duì)比，來(lái)確定當(dāng)前事務(wù)是否處于正常狀態(tài)。
如果你只想衡量應(yīng)用的某個(gè)方面，那么可以評(píng)估事務(wù)的行為。所以，盡管容器指標(biāo)能夠提供更豐富的信息，并且?guī)椭銢Q定何時(shí)對(duì)當(dāng)前環(huán)境進(jìn)行自動(dòng)測(cè)量，但你的事務(wù)就足以確定應(yīng)用性能。無(wú)需向應(yīng)用程序服務(wù)器獲取 CPU 的使用情況，你更應(yīng)該關(guān)心用戶是否完成了事務(wù)，以及該事務(wù)是否得到了優(yōu)化。
補(bǔ)充一個(gè)小知識(shí)點(diǎn)，事務(wù)是由入口點(diǎn)決定的，通過(guò)該入口點(diǎn)可以啟動(dòng)事務(wù)與應(yīng)用進(jìn)行交互。
一旦定義了事務(wù)，會(huì)在整個(gè)應(yīng)用生態(tài)系統(tǒng)中對(duì)其性能進(jìn)行測(cè)量，并將每個(gè)事務(wù)與基線進(jìn)行比對(duì)。例如，我們可能會(huì)決定當(dāng)事務(wù)的響應(yīng)時(shí)間與基線相比，一旦慢于平均響應(yīng)時(shí)間的兩個(gè)標(biāo)準(zhǔn)差是否就應(yīng)該判定為異常，如圖1所示。
圖1-基于基線評(píng)估當(dāng)前事務(wù)響應(yīng)時(shí)間
用于評(píng)估事務(wù)的基線與正在進(jìn)行的事務(wù)活動(dòng)在時(shí)間上是一致的，但事務(wù)會(huì)由每個(gè)事務(wù)執(zhí)行來(lái)完善。例如，當(dāng)你選定一個(gè)基線，在當(dāng)前事務(wù)結(jié)束之后，將事務(wù)與平均響應(yīng)時(shí)間按每天的小時(shí)數(shù)和每周的天數(shù)進(jìn)行對(duì)比，所有在那段時(shí)間內(nèi)執(zhí)行的事務(wù)都將會(huì)被納入下周的基線中。通過(guò)這種機(jī)制，應(yīng)用程序可以隨時(shí)間而變化，而無(wú)需每次都重建原始基線；你可以將其看作是一個(gè)隨時(shí)間移動(dòng)的窗口。
總之，事務(wù)最能反映用戶體驗(yàn)的測(cè)量方法，所以也是衡量性能狀況最重要的指標(biāo)。
查詢性能?
最容易檢測(cè)到查詢性能是否正常的指標(biāo)就是查詢本身。由查詢引起的問(wèn)題可能會(huì)導(dǎo)致時(shí)間太長(zhǎng)而無(wú)法識(shí)別所需數(shù)據(jù)或返回?cái)?shù)據(jù)。所以不妨在查詢中排查以下問(wèn)題。
1. 選擇過(guò)多冗余數(shù)據(jù)
編寫(xiě)查詢語(yǔ)句來(lái)返回適當(dāng)?shù)臄?shù)據(jù)是遠(yuǎn)遠(yuǎn)不夠的，很可能你的查詢語(yǔ)句會(huì)返回太多列，從而導(dǎo)致選擇行和檢索數(shù)據(jù)變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當(dāng)需要在特定字段中查詢時(shí)，該計(jì)劃可能會(huì)確定一個(gè)覆蓋索引從而加快結(jié)果返回。覆蓋索引通常會(huì)包含查詢中使用的所有字段。這意味著數(shù)據(jù)庫(kù)可以僅從索引中產(chǎn)生結(jié)果，而不需要通過(guò)底層表來(lái)構(gòu)建。
另外，列出結(jié)果中所需的列不僅可以減少傳輸?shù)臄?shù)據(jù)，還能進(jìn)一步提高性能。
2. 表之間的低效聯(lián)接
聯(lián)接會(huì)導(dǎo)致數(shù)據(jù)庫(kù)將多組數(shù)據(jù)帶到內(nèi)存中進(jìn)行比較，這會(huì)產(chǎn)生多個(gè)數(shù)據(jù)庫(kù)讀取和大量 CPU。根據(jù)表的索引，聯(lián)接還可能需要掃描兩個(gè)表的所有行。如果寫(xiě)不好兩個(gè)大型表之間的聯(lián)接，就需要對(duì)每個(gè)表進(jìn)行完整掃描，這樣的計(jì)算量將會(huì)非常大。其他會(huì)拖慢聯(lián)接的因素包括聯(lián)接列之間存在不同的數(shù)據(jù)類型、需要轉(zhuǎn)換或加入包含 LIKE 的條件，這樣就會(huì)阻止使用索引。另外，還需注意避免使用全外聯(lián)接；在恰當(dāng)?shù)臅r(shí)候使用內(nèi)部聯(lián)接只返回所需數(shù)據(jù)。
3. 索引過(guò)多或過(guò)少
如果查詢優(yōu)化沒(méi)有可用的索引時(shí)，數(shù)據(jù)庫(kù)會(huì)重新掃描表來(lái)產(chǎn)生查詢結(jié)果，這個(gè)過(guò)程會(huì)生成大量的磁盤(pán)輸入/輸出（I/O）。適當(dāng)?shù)乃饕梢詼p少排序結(jié)果的需要。雖然非唯一值的索引在生成結(jié)果時(shí)，不能像唯一索引那樣方便。如果鍵越大，索引也會(huì)變大，并通過(guò)它們創(chuàng)建更多的磁盤(pán) I/O。大多數(shù)索引是為了提高數(shù)據(jù)檢索的性能，但也需要明白索引本身也會(huì)影響數(shù)據(jù)的插入和更新，因?yàn)樗邢嚓P(guān)聯(lián)的指標(biāo)都必須更新。
4. 太多的SQL導(dǎo)致?tīng)?zhēng)用解析資源
任何 SQL 查詢?cè)趫?zhí)行之前都必須被解析，在生成執(zhí)行計(jì)劃之前需要對(duì)語(yǔ)法和權(quán)限進(jìn)行檢查。由于解析非常耗時(shí)，數(shù)據(jù)庫(kù)會(huì)保存已解析的 SQL 來(lái)重復(fù)利用，從而減少解析的耗時(shí)。因?yàn)?WHERE 語(yǔ)句不同，所以使用文本值的查詢語(yǔ)句不能被共享。這將導(dǎo)致每個(gè)查詢都會(huì)被解析并添加到共享池中，由于池的空間有限，一些已保存的查詢會(huì)被舍棄。當(dāng)這些查詢?cè)俅纬霈F(xiàn)時(shí)，則需要重新解析。
用戶和查詢沖突?
數(shù)據(jù)庫(kù)支持多用戶，但多用戶活動(dòng)也可能造成沖突。
1. 由慢查詢導(dǎo)致的頁(yè)/行鎖定
為了確保查詢產(chǎn)生精確的結(jié)果，數(shù)據(jù)庫(kù)必須鎖定表以防止在運(yùn)行讀取查詢時(shí)再發(fā)生其他的插入和更新行為。如果報(bào)告或查詢相當(dāng)緩慢，需要修改值的用戶可能需要等待至更新完成。鎖提示能幫助數(shù)據(jù)庫(kù)使用最小破壞性的鎖。從事務(wù)數(shù)據(jù)庫(kù)中分離報(bào)表也是一種可靠的解決方法。
2. 事務(wù)鎖和死鎖
當(dāng)兩個(gè)事務(wù)被阻塞時(shí)會(huì)出現(xiàn)死鎖，因?yàn)槊恳粋€(gè)都需要使用被另一個(gè)占用的資源。當(dāng)出現(xiàn)一個(gè)普通鎖時(shí)，事務(wù)會(huì)被阻塞直到資源被釋放。但卻沒(méi)有解決死鎖的方案。數(shù)據(jù)庫(kù)會(huì)監(jiān)控死鎖并選擇終止其中一個(gè)事務(wù)，釋放資源并允許該事務(wù)繼續(xù)進(jìn)行，而另一個(gè)事務(wù)則回滾。
3. 批處理操作造成資源爭(zhēng)奪
批處理過(guò)程通常會(huì)執(zhí)行批量操作，如大量的數(shù)據(jù)加載或生成復(fù)雜的分析報(bào)告。這些操作是資源密集型的，但可能影響在線用戶的訪問(wèn)應(yīng)用的性能。針對(duì)此問(wèn)題最好的解決辦法是確保批處理在系統(tǒng)使用率較低時(shí)運(yùn)行，比如晚上，或用單獨(dú)的數(shù)據(jù)庫(kù)進(jìn)行事務(wù)處理和分析報(bào)告。
容量?
并不是所有的數(shù)據(jù)庫(kù)性能問(wèn)題都是數(shù)據(jù)庫(kù)問(wèn)題。有些問(wèn)題也是硬件不合適造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分擔(dān)服務(wù)器負(fù)載，進(jìn)一步提高性能。數(shù)據(jù)庫(kù)的性能不僅是數(shù)據(jù)庫(kù)的原因，還受到服務(wù)器上運(yùn)行其他進(jìn)程的影響。因此，對(duì)數(shù)據(jù)庫(kù)負(fù)載及使用進(jìn)行審查也是必不可少的。由于 CPU 的利用率時(shí)時(shí)在變，在低使用率、平均使用率和峰值使用率的時(shí)間段分別檢查該指標(biāo)可以更好地評(píng)估增加額外的 CPU 資源是否有益。
2. IOPS 不足的慢磁盤(pán)
磁盤(pán)性能通常以每秒輸入/輸出操作（IOPS）來(lái)計(jì)。結(jié)合 I/O 大小，該指標(biāo)可以衡量每秒的磁盤(pán)吞吐量是多少兆。同時(shí)，吞吐量也受磁盤(pán)的延遲影響，比如需要多久才能完成請(qǐng)求，這些指標(biāo)主要是針對(duì)磁盤(pán)存儲(chǔ)技術(shù)而言。傳統(tǒng)的硬盤(pán)驅(qū)動(dòng)器（HDD）有一個(gè)旋轉(zhuǎn)磁盤(pán)，通常比固態(tài)硬盤(pán)（SSD）或閃存更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經(jīng)降了下來(lái)，所以在市場(chǎng)上也更具競(jìng)爭(zhēng)力。
3. 全部或錯(cuò)誤配置的磁盤(pán)
眾所周知，數(shù)據(jù)庫(kù)會(huì)被大量磁盤(pán)訪問(wèn)，所以不正確配置的磁盤(pán)可能帶來(lái)嚴(yán)重的性能缺陷。磁盤(pán)應(yīng)該適當(dāng)分區(qū)，將系統(tǒng)數(shù)據(jù)目錄和用戶數(shù)據(jù)日志分開(kāi)。高度活躍的表應(yīng)該區(qū)分以避免爭(zhēng)用，通過(guò)在不同磁盤(pán)上存放數(shù)據(jù)庫(kù)和索引增加并行放置，但不要將操作系統(tǒng)和數(shù)據(jù)庫(kù)交換空間放置在同一磁盤(pán)上。
4. 內(nèi)存不足
有限或不恰當(dāng)?shù)奈锢韮?nèi)存分配會(huì)影響數(shù)據(jù)庫(kù)性能。通常我們認(rèn)為可用的內(nèi)存更多，性能就越好。監(jiān)控分頁(yè)和交換,在多個(gè)非繁忙磁盤(pán)中建立多頁(yè)面空間，進(jìn)一步確保分頁(yè)空間分配足夠滿足數(shù)據(jù)庫(kù)要求；每個(gè)數(shù)據(jù)庫(kù)供應(yīng)商也可以在這個(gè)問(wèn)題上提供指導(dǎo)。
5. 網(wǎng)速慢
網(wǎng)絡(luò)速度會(huì)影響到如何快速檢索數(shù)據(jù)并返回給終端用戶或調(diào)用過(guò)程。使用寬帶連接到遠(yuǎn)程數(shù)據(jù)庫(kù)。在某些情況下，選擇 TCP/IP 協(xié)議而不是命名管道可顯著提高數(shù)據(jù)庫(kù)性能。
配置
每個(gè)數(shù)據(jù)庫(kù)都需設(shè)置大量的配置項(xiàng)。通常情況下，默認(rèn)值可能不足以滿足數(shù)據(jù)庫(kù)所需的性能。所以，檢查所有的參數(shù)設(shè)置，包括以下問(wèn)題。
1. 緩沖區(qū)緩存太小
通過(guò)將數(shù)據(jù)存儲(chǔ)在內(nèi)核內(nèi)存，緩沖區(qū)緩存可以進(jìn)一步提高性能同時(shí)減少磁盤(pán) I/O。當(dāng)緩存太小時(shí)，緩存中的數(shù)據(jù)會(huì)更頻繁地刷新。如果它再次被請(qǐng)求，就必須從磁盤(pán)重讀。除了磁盤(pán)讀取緩慢之外，還給 I/O 設(shè)備增添了負(fù)擔(dān)從而成為瓶頸。除了給緩沖區(qū)緩存分配足夠的空間，調(diào)優(yōu) SQL 查詢可以幫助其更有效地利用緩沖區(qū)緩存。
2. 沒(méi)有查詢緩存
查詢緩存會(huì)存儲(chǔ)數(shù)據(jù)庫(kù)查詢和結(jié)果集。當(dāng)執(zhí)行相同的查詢時(shí)，數(shù)據(jù)會(huì)在緩存中被迅速檢索，而不需要再次執(zhí)行查詢。數(shù)據(jù)會(huì)更新失效結(jié)果，所以查詢緩存是唯一有效的靜態(tài)數(shù)據(jù)。但在某些情況下，查詢緩存卻可能成為性能瓶頸。比如當(dāng)鎖定為更新時(shí)，巨大的緩存可能導(dǎo)致?tīng)?zhēng)用沖突。
3. 磁盤(pán)上臨時(shí)表創(chuàng)建導(dǎo)致的 I/O 爭(zhēng)用
在執(zhí)行特定的查詢操作時(shí)，數(shù)據(jù)庫(kù)需要?jiǎng)?chuàng)建臨時(shí)表，如執(zhí)行一個(gè) GROUP BY 子句。如果可能，在內(nèi)存中創(chuàng)建臨時(shí)表。但是，在某些情況下，在內(nèi)存中創(chuàng)建臨時(shí)表并不可行，比如當(dāng)數(shù)據(jù)包含 BLOB 或 TEXT 對(duì)象時(shí)。在這些情況下，會(huì)在磁盤(pán)上創(chuàng)建臨時(shí)表。大量的磁盤(pán) I / O 都需要?jiǎng)?chuàng)建臨時(shí)表、填充記錄、從表中選擇所需數(shù)據(jù)并在查詢完成后舍棄。為了避免影響性能，臨時(shí)數(shù)據(jù)庫(kù)應(yīng)該從主數(shù)據(jù)庫(kù)中分離出來(lái)。重寫(xiě)查詢還可以通過(guò)創(chuàng)建派生表來(lái)減少對(duì)臨時(shí)表的需求。使用派生表直接從另一個(gè) SELECT 語(yǔ)句的結(jié)果中選擇，允許將數(shù)據(jù)加到內(nèi)存中而不是當(dāng)前磁盤(pán)上。
NoSQL 數(shù)據(jù)庫(kù)
NoSQL 的優(yōu)勢(shì)在于它處理大數(shù)據(jù)的能力非常迅速。但是在實(shí)際使用中，也應(yīng)該綜合參考 NoSQL 的缺點(diǎn)，從而決定是否適合你的用例場(chǎng)景。這就是為什么NoSQL通常被理解為 「不僅僅是 SQL」，說(shuō)明了 NoSQL 并不總是正確的解決方案，也沒(méi)必要完全取代 SQL，以下分別列舉出五大主要原因。
1. 挑剔事務(wù)
難以保持 NoSQL 條目的一致性。當(dāng)訪問(wèn)結(jié)構(gòu)化數(shù)據(jù)時(shí)，它并不能完全確保同一時(shí)間對(duì)不同表的更改都生效。如果某個(gè)過(guò)程發(fā)生崩潰，表可能會(huì)不一致。一致事務(wù)的典型代表是復(fù)式記賬法。相應(yīng)的信貸必須平衡每個(gè)借方，反之亦然。如果雙方數(shù)據(jù)不一致則不能輸入。NoSQL 則可能無(wú)法保證「收支平衡」。
2. 復(fù)雜數(shù)據(jù)庫(kù)
NoSQL 的支持者往往以高效代碼、簡(jiǎn)單性和 NoSQL 的速度為傲。當(dāng)數(shù)據(jù)庫(kù)任務(wù)很簡(jiǎn)單時(shí)，所有這些因素都是優(yōu)勢(shì)。但當(dāng)數(shù)據(jù)庫(kù)變得復(fù)雜，NoSQL 會(huì)開(kāi)始分解。此時(shí)，SQL 則比 NoSQL 更好地處理復(fù)雜需求，因?yàn)?SQL 已經(jīng)成熟，有符合行業(yè)標(biāo)準(zhǔn)的接口。而每個(gè) NoSQL 設(shè)置都有一個(gè)唯一的接口。
3. 一致聯(lián)接
當(dāng)執(zhí)行 SQL 的聯(lián)接時(shí)，由于系統(tǒng)必須從不同的表中提取數(shù)據(jù)進(jìn)行鍵對(duì)齊，所以有一個(gè)巨大的開(kāi)銷。而 NoSQL 似乎是一個(gè)空想，因?yàn)槿狈β?lián)接功能。所有的數(shù)據(jù)都在同一個(gè)表的一個(gè)地方。當(dāng)檢索數(shù)據(jù)時(shí)，它會(huì)同時(shí)提取所有的鍵值對(duì)。問(wèn)題在于這會(huì)創(chuàng)建同一數(shù)據(jù)的多個(gè)副本。這些副本也必須更新，而這種情況下，NoSQL 沒(méi)有功能來(lái)確保更新。
4. Schema設(shè)計(jì)的靈活性
由于 NoSQL 不需要 schema，所以在某些情況下也是獨(dú)一無(wú)二的。在以前的數(shù)據(jù)庫(kù)模型中，程序員必須考慮所有需要的列能夠擴(kuò)展，能夠適應(yīng)每行的數(shù)據(jù)條目。在 NoSQL 下，條目可以有多種字符串或者完全沒(méi)有。這種靈活性允許程序員迅速增加數(shù)據(jù)。但是，也可能存在問(wèn)題，比如當(dāng)有多個(gè)團(tuán)體在同一項(xiàng)目上工作時(shí)，或者新的開(kāi)發(fā)團(tuán)隊(duì)接手一個(gè)項(xiàng)目時(shí)。開(kāi)發(fā)人員能夠自由地修改數(shù)據(jù)庫(kù)，也可能會(huì)不斷實(shí)現(xiàn)各種各樣的密鑰對(duì)。
5. 資源密集型
NoSQL 數(shù)據(jù)庫(kù)通常比關(guān)系數(shù)據(jù)庫(kù)更加資源密集。他們需要更多的 CPU 儲(chǔ)備和 RAM 分配。出于這個(gè)原因，大多數(shù)共享主機(jī)公司都不提供 NoSQL。你必須注冊(cè)一個(gè) VPS 或運(yùn)行自己的專用服務(wù)器。另一方面，SQL 主要是在服務(wù)器上運(yùn)行。初期的工作都很順利，但隨著數(shù)據(jù)庫(kù)需求的增加，硬件必須擴(kuò)大。單個(gè)大型服務(wù)器比多個(gè)小型服務(wù)器昂貴得多，價(jià)格呈指數(shù)增長(zhǎng)。所以在這種企業(yè)計(jì)算場(chǎng)景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的服務(wù)器。
為什么大家都要NoSql
因?yàn)殛P(guān)系數(shù)據(jù)庫(kù)運(yùn)行的慢
處理大數(shù)據(jù)的大多數(shù)情況是nosql比較高效
但是nosql也沒(méi)法完全取代關(guān)系數(shù)據(jù)庫(kù)
nosql不能處理復(fù)雜的邏輯
但是很多情況下只是簡(jiǎn)單的mapping,匯總,
在目前互聯(lián)網(wǎng)大數(shù)據(jù)的環(huán)境下nosql會(huì)越來(lái)越普及
elasticsearch可以代替NoSQL嗎
elasticsearch 是一個(gè)基于Lucene的搜索服務(wù)器。把數(shù)據(jù)放在一個(gè)索引文件里面。
NoSQL 是緩存數(shù)據(jù)庫(kù)，例如 redis，mongodb 。這是把數(shù)據(jù)放在內(nèi)存里面的。
搜索服務(wù)器一般是用在搜索功能。
NoSQL 則一般是把一些臨時(shí)的數(shù)據(jù)保存一段時(shí)間。例如分布是系統(tǒng)之間的文件傳輸，可以放到?mongodb 里面。又例如一個(gè)配置信息，經(jīng)常使用，在互聯(lián)網(wǎng)產(chǎn)品中如果多次查詢數(shù)據(jù)庫(kù)的話會(huì)增數(shù)據(jù)庫(kù)的壓力，可以使用 NoSQL。
他們的功能不同，所以是不能代替的。
nosql會(huì)完全取代關(guān)系型數(shù)據(jù)庫(kù)嗎
不會(huì)的，兩者的適用場(chǎng)合不一樣，到目前為止，關(guān)系型數(shù)據(jù)還未完全替代文件型數(shù)據(jù)。 有些地方還在用層次型數(shù)據(jù)庫(kù)。
網(wǎng)頁(yè)題目：nosql無(wú)法取代,nosql缺點(diǎn)
瀏覽地址：http://fisionsoft.com.cn/article/dsdhppe.html
