幾種nosql的淺談

1、性能

成都創新互聯主要從事網站建設、成都網站制作、網頁設計、企業做網站、公司建網站等業務。立足成都服務仁化,十年網站建設經驗,價格優惠、服務專業,歡迎來電咨詢建站服務:028-86922220

都比較高，性能對我們來說應該都不是瓶頸。

總體來講，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。

2、操作的便利性

memcache 數據結構單一。（key-value）

redis 豐富一些，數據操作方面，redis 更好一些，較少的網絡 IO 次數，同時還提供 list，set，

hash 等數據結構的存儲。

mongodb 支持豐富的數據表達，索引，最類似關系型數據庫，支持的查詢語言非常豐富。

3、內存空間的大小和數據量的大小

redis 在 2.0 版本后增加了自己的 VM 特性，突破物理內存的限制；可以對 key value 設置過

期時間（類似 memcache）

memcache 可以修改最大可用內存,采用 LRU 算法。Memcached 代理軟件 magent，比如建立

10 臺 4G 的 Memcache 集群，就相當于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b

10.1.2.3:14000 mongoDB 適合大數據量的存儲，依賴操作系統 VM 做內存管理，吃內存也比較厲害，服務

不要和別的服務在一起。

4、可用性（單點問題）

對于單點問題，

redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整

個快照,無增量復制，因性能和效率問題，

所以單點問題比較復雜；不支持自動 sharding,需要依賴程序設定一致 hash 機制。

一種替代方案是，不用 redis 本身的復制機制，采用自己做主動復制（多份存儲），或者改成

增量復制的方式（需要自己實現），一致性問題和性能的權衡

Memcache 本身沒有數據冗余機制，也沒必要；對于故障預防，采用依賴成熟的 hash 或者環

狀的算法，解決單點故障引起的抖動問題。

mongoDB 支持 master-slave,replicaset（內部采用 paxos 選舉算法，自動故障恢復）,auto sharding 機制，對客戶端屏蔽了故障轉移和切分機制。

5、可靠性（持久化）

對于數據持久化和數據恢復，

redis 支持（快照、AOF）：依賴快照進行持久化，aof 增強了可靠性的同時，對性能有所影

響

memcache 不支持，通常用在做緩存,提升性能；

MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性

6、數據一致性（事務支持）

Memcache 在并發場景下，用 cas 保證一致性redis 事務支持比較弱，只能保證事務中的每個操作連續執行

mongoDB 不支持事務

7、數據分析

mongoDB 內置了數據分析的功能(mapreduce),其他不支持

8、應用場景

redis：數據量較小的更性能操作和運算上

memcache：用于在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫

少，對于數據量比較大，可以采用 sharding）

MongoDB:主要解決海量數據的訪問效率問題。

表格比較：

memcache redis 類型 內存數據庫 內存數據庫

數據類型 在定義 value 時就要固定數據類型 不需要

有字符串，鏈表，集 合和有序集合

虛擬內存 不支持 支持

過期策略 支持 支持

分布式 magent master-slave，一主一從或一主多從

存儲數據安全 不支持 使用 save 存儲到 dump.rdb 中

災難恢復 不支持 append only file(aof)用于數據恢復

性能

1、類型——memcache 和 redis 都是將數據存放在內存，所以是內存數據庫。當然，memcache 也可用于緩存其他東西，例如圖片等等。

2、 數據類型——Memcache 在添加數據時就要指定數據的字節長度,而 redis 不需要。

3、 虛擬內存——當物理內存用完時，可以將一些很久沒用到的 value 交換到磁盤。

4、 過期策略——memcache 在 set 時就指定，例如 set key1 0 0 8,即永不過期。Redis 可以通

過例如 expire 設定，例如 expire name 10。

5、 分布式——設定 memcache 集群，利用 magent 做一主多從;redis 可以做一主多從。都可

以一主一從。

6、 存儲數據安全——memcache 斷電就斷了，數據沒了；redis 可以定期 save 到磁盤。

7、 災難恢復——memcache 同上，redis 丟了后可以通過 aof 恢復。

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 啟動一個守護進程

-p 端口

-m 分配的內存是 M

-c 最大運行并發數-P memcache 的 pid

//0 壓縮（是否 MEMCACHE_COMPRESSED） 30 秒失效時間

//delete 5 是 timeout

userip = nosql(Request.("HTTP_X_FORWARDED_FOR"))

《HTTP_X_FORWARDED_FOR REMOTE_ADDR》

在 ASP 中使用 Request.ServerVariables("REMOTE_ADDR") 來取得客戶端的 IP 地址，但如果客戶端是使用代理服務器來訪問，那取到的就是代理服務器的 IP 地址，而不是真正的客戶端 IP 地址。要想透過代理服務器取得客戶端的真實 IP 地址，就要使用 Request.ServerVariables("HTTP_X_FORWARDED_FOR") 來讀取。

不過要注意的事，并不是每個代理服務器都能用 Request.ServerVariables("HTTP_X_FORWARDED_FOR") 來讀取客戶端的真實 IP，有些用此方法讀取到的仍然是代理服務器的 IP。

還有一點需要注意的是：如果客戶端沒有通過代理服務器來訪問，那么用Request.ServerVariables ("HTTP_X_FORWARDED_FOR") 取到的值將是空的。因此，如果要在程序中使用此方法，可以這樣處理：

......

userip = Request.ServerVariables("HTTP_X_FORWARDED_FOR")

If userip = "" Then userip = Request.ServerVariables("REMOTE_ADDR")

......

即：如果客戶端通過代理服務器，則取 HTTP_X_FORWARDED_FOR 的值，如果沒通過代理服務器，就取 REMOTE_ADDR 的值。

predixy一款高性能全功能redis代理

redis作為一款優秀的NoSQL代表軟件，正變得越來越流行，雖然Redis很容易就可以啟動并使用，但是要想在線上用好它卻也并非易事。redis的高可用和可擴展無論是自帶的Redis Sentinel還是Redis Cluster都要求客戶端進行額外的支持，而目前基本上沒有合適的客戶端能夠做這些事情，實際上客戶端來做這些事情也并不合適，它會讓維護變得特別困難。因此在客戶端和redis服務端之間加一層代理成了一種理想的方案，代理屏蔽后端Redis實現細節向客戶端提供redis服務，可以完美的解決Redis的高可用和擴展性問題，同時代理的引入也使得Redis維護變得更加簡單。在本文所要介紹的代理predixy之前，已經有幾款流行的redis代理，它們各具特色。接下來，我們就來比較以下代理：

簡單來說，predixy既支持Redis Sentinel也支持Redis Cluster

作為redis代理，高性能是硬性要求，為了測試上面四款代理的性能接下來我們就來做個簡單的評測，測試平臺及各代理具體的版本信息如下：

redis-server、各代理、redis-benchmark均在這一臺機器上運行。

redis部署：

以下測試的結果中，橫坐標為數據大小、縱坐標為qps或者毫秒。

這里單線程是指四款代理都運行在單線程下（下同），redis-benchmark默認并發50個客戶端連接，每個連接每次發送一個命令收到響應后再發下一個命令。這是很多線上實際的場景。

在吞吐上，四款代理的性能排列的整齊有序，predixy大幅領先于另外三款代理，而twemproxy又以較大優勢領先另外兩個，剩下的兩個codis在數據量小于512的時候稍稍領先cerberus，而當數據量大于512的時候，codis對cerberus的領先越來越大。整體上在數據量達到16KB時，由于redis-benchmark本身成為瓶頸，predixy和twemproxy的SET成績差不多了。

在延時上，codis由于語言的問題，一直都大于另外三款代理，后續測試也一樣。

在有些場景下，客戶端可能在處理一個請求時可能需要發起多次redis請求，這時如果把多個redis請求pipeline一起請求的話，會大幅改善性能。本輪測試就來看看當客戶端一次發送多個請求時我們各代理表現如何？Redis-benchmark依舊是并發50個連接，但是一次發送20個命令。

在吞吐上，redis-benchmark一次pipeline 20個命令后，各代理的吞吐量全都猛增。predixy更是一騎絕塵，遙遙領先另外三個，而最后看到在GET 4K數量據的時候predixy表現和其它代理差不多是因為對predixy來說，當數據量大于2K時redis-benchmark自身已經成為瓶頸。另外三款代理，在上輪測試中落后的cerberus在本輪測試一開始表現遠好過twemproxy和codis，但cerberus還是存在隨著數據量變大性能迅速降低的問題。twemproxy和codis在本輪測試中表現基本相當。

在時延上，codis固有的問題表現較差，另外三款在數據量較小時差別較小，而當數據量超過512時，predixy則表現出較明顯的優勢。

測完了單線程，現在我們開始多線程測試，由于twemproxy不支持多線程，因此twemproxy不參與多線程的測試。考慮到redis-benchmark本身是個單線程程序，在多線程代理下如果我們再測單個命令的性能，那redis-benchmark很可能就是瓶頸，則無法更明確的看出各代理的性能差異，因此我們直接測試pipeline，還跟上輪一樣，50個并發連接，一次發送20個命令。

總體趨勢和第二輪單線程pipeline測試一致，predixy在本輪測試中依舊取得了領先，不過在開始階段cerberus和predixy遙遙領先于codis，cerberus和predixy差距不大。但是隨著數據量的變大，cerberus再次顯示出了性能急劇降低的問題，到1K以后甚至就比codis差了。

在功能的對比上，predixy相比另外三款代理更為全面，基本可以完全適用原生redis的使用場景。在性能上，predixy在各輪測試中都以較大優勢領先。對各代理的總結如下：

分享標題：nosql代理,NoSql
分享鏈接：http://vcdvsql.cn/article22/dsigojc.html

成都網站建設公司_創新互聯，為您提供網站收錄、App開發、定制開發、品牌網站建設、企業建站、品牌網站設計

廣告

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