數據多的時候為什麼要使用redis而不用mysql?

米斯特庫


通常來說,當數據多、併發量大的時候,架構中可以引入Redis,幫助提升架構的整體性能,減少Mysql(或其他數據庫)的壓力,但不是使用Redis,就不用MySQL。

因為Redis的性能十分優越,可以支持每秒十幾萬此的讀/寫操作,並且它還支持持久化、集群部署、分佈式、主從同步等,Redis在高併發的場景下數據的安全和一致性,所以它經常用於兩個場景:

緩存

  • 經常會被查詢,但是不經常被修改或者刪除的數據;比如數據字典,業務數據中的熱點數據;這樣不僅提升查詢效率,還可以減少數據庫的壓力;

  • 經常被查詢,實時性要求不高數據,比如網站的最新列表、排行榜之類的數據,只需要定時統計一次,然後把統計結果放到Redis中提供查詢(請不要使用select top 10 from xxxx)。

  • 緩存可以方便數據共享,比如我先用電腦網頁打開X東,選了兩件商品放到購物車裡面,再登錄手機APP,也是可以看到購物車裡面的商品的。

判斷數據是否適合緩存到Redis中,可以從幾個方面考慮:會經常查詢麼?命中率如何?寫操作多麼?數據大小?

我們經常採用這樣的方式將數據刷到Redis中:查詢的請求過來,現在Redis中查詢,如果查詢不到,就查詢數據庫拿到數據,再放到緩存中,這樣第二次相同的查詢請求過來,就可以直接在Redis中拿到數據;不過要注意【緩存穿透】的問題。

緩存的刷新會比較複雜,通常是修改完數據庫之後,還需要對Redis中的數據進行操作;代碼很簡單,但是需要保證這兩步為同一事務,或最終的事務一致性。

高速讀寫

常見的就是計數器,比如一篇文章的閱讀量,不可能每一次閱讀就在數據庫裡面update一次。

高併發的場景很適合使用Redis,比如雙11秒殺,庫存一共就一千件,到了秒殺的時間,通常會在極為短暫的時間內,有數萬級的請求達到服務器,如果使用數據庫的話,很可能在這一瞬間造成數據庫的崩潰,所以通常會使用Redis(秒殺的場景會比較複雜,Redis只是其中之一,例如如果請求超過某個數量的時候,多餘的請求就會被限流)。

這種高併發的場景,是當請求達到服務器的時候,直接在Redis上讀寫,請求不會訪問到數據庫;程序會在合適的時間,比如一千件庫存都被秒殺,再將數據批量寫到數據庫中。


所以通常來說,在必要的時候引入Redis,可以減少MySQL(或其他)數據庫的壓力,兩者不是替代的關係。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


題主你錯了,不是用redis代替MySQL,而是引入redis來優化。

BAT裡越來越多的項目組已經採用了redis+MySQL的架構來開發平臺工具。

如題主所說,當數據多的時候,MySQL的查詢效率會大打折扣。我們通常默認如果查詢的字段包含索引的話,返回是毫秒級別的。但是在實際工作中,我曾經遇到過一張包含10個字段的表,1800萬+條數據,當某種場景下,我們不得不根據一個未加索引的字段進行精確查詢的時候,單條sql語句的執行時長有時能夠達到2min以上,就更別提如果用like這種模糊查詢的話,其效率將會多麼低下。

我們最開始是希望能夠通過增加索引的方式解決,但是面對千萬級別的數據量,我們也不敢貿然加索引,因為一旦數據庫hang住,期間的所有數據庫寫入請求都會被放到等待隊列中,如果請求是通過http請求發過來的,很有可能導致服務發生分鐘級別的超時不響應。

經過一番調研,最終敲定的解決方案是引入redis作為緩存。redis具有運行效率高,數據查詢速度快,支持多種存儲類型以及事務等優勢,我們把經常讀取,而不經常改動的數據放入redis中,服務器讀取這類數據的時候時候,直接與redis通信,極大的緩解了MySQL的壓力。

然而,我在上面也說了,是redis+MySQL結合的方式,而不是替代。原因就是redis雖然讀寫很快,但是不適合做數據持久層,主要原因是使用redis做數據落盤是要以效率作為代價的,即每隔制定的時間,redis就要去進行數據備份/落盤,這對於單線程的它來說,勢必會因“分心”而影響效率,結果得不償失。

以上就是我的淺見,歡迎各位在下方點贊,留言。

我是蘇蘇思量,來自BAT的java開發工程師,每天都會分享科技類見聞,歡迎關注我,與我共同進步。


蘇蘇思量


樓主你好,首先糾正下,數據多並不是一定就用Redis,Redis歸屬於NoSQL數據庫中,其特點擁有高性能讀寫數據速度,主要解決業務效率瓶頸。下面就詳細說下Redis的相比MySQL優點。(關於Redis詳細瞭解參見我近期文章:https://www.toutiao.com/i6543810796214813187)

讀寫異常快

Redis非常快,每秒可執行大約10萬次的讀寫速度。

豐富的數據類型

Redis支持豐富的數據類型,有二進制字符串、列表、集合、排序集和散列等等。這使得Redis很容易被用來解決各種問題,因為我們知道哪些問題可以更好使用地哪些數據類型來處理解決。

原子性

Redis的所有操作都是原子操作,這確保如果兩個客戶端併發訪問,Redis服務器能接收更新的值。

豐富實用工具

Redis是一個多實用工具,可用於多種用例,如:緩存,消息隊列(發佈/訂閱),通知,key值過期等等。

支持異機主從複製

Redis支持主從複製的配置,它可以實現主服務器的完全拷貝。

以上為開發者青睞Redis的主要幾個可取之處。但是,請注意實際生產環境中企業都是結合Redis和MySQL的特定進行不同應用場景的取捨。如緩存——熱數據、計數器、消息隊列(與ActiveMQ,RocketMQ等工具類似)、位操作(大數據處理)、分佈式鎖與單線程機制、最新列表(如新聞列表頁面最新的新聞列表)以及排行榜等等可以看見Redis大顯身手的場景。可是對於嚴謹的數據準確度和複雜的關係型應用MySQL等關係型數據庫依然不可替。

更多技術瞭解,關注小伍


小伍科技


Redis和MySQL的應用場景是不同的。

通常來說,沒有說用Redis就不用MySQL的這種情況。

因為Redis是一種非關係型數據庫(NoSQL),而MySQL是一種關係型數據庫。

和Redis同類的數據庫還有MongoDB和Memchache(其實並沒有持久化數據)

那關係型數據庫現在常用的一般有MySQL,SQL Server,Oracle。

我們先來了解一下關係型數據庫和非關係型數據庫的區別吧。

1.存儲方式

關係型數據庫是表格式的,因此存儲在表的行和列中。他們之間很容易關聯協作存儲,提取數據很方便。而Nosql數據庫則與其相反,他是大塊的組合在一起。通常存儲在數據集中,就像文檔、鍵值對或者圖結構。

2.存儲結構

關係型數據庫對應的是結構化數據,數據表都預先定義了結構(列的定義),結構描述了數據的形式和內容。這一點對數據建模至關重要,雖然預定義結構帶來了可靠性和穩定性,但是修改這些數據比較困難。而Nosql數據庫基於動態結構,使用與非結構化數據。因為Nosql數據庫是動態結構,可以很容易適應數據類型和結構的變化。

3.存儲規範

關係型數據庫的數據存儲為了更高的規範性,把數據分割為最小的關係表以避免重複,獲得精簡的空間利用。雖然管理起來很清晰,但是單個操作設計到多張表的時候,數據管理就顯得有點麻煩。而Nosql數據存儲在平面數據集中,數據經常可能會重複。單個數據庫很少被分隔開,而是存儲成了一個整體,這樣整塊數據更加便於讀寫

4.存儲擴展

這可能是兩者之間最大的區別,關係型數據庫是縱向擴展,也就是說想要提高處理能力,要使用速度更快的計算機。因為數據存儲在關係表中,操作的性能瓶頸可能涉及到多個表,需要通過提升計算機性能來克服。雖然有很大的擴展空間,但是最終會達到縱向擴展的上限。而Nosql數據庫是橫向擴展的,它的存儲天然就是分佈式的,可以通過給資源池添加更多的普通數據庫服務器來分擔負載。

5.查詢方式

關係型數據庫通過結構化查詢語言來操作數據庫(就是我們通常說的SQL)。SQL支持數據庫CURD操作的功能非常強大,是業界的標準用法。而Nosql查詢以塊為單元操作數據,使用的是非結構化查詢語言(UnQl),它是沒有標準的。關係型數據庫表中主鍵的概念對應Nosql中存儲文檔的ID。關係型數據庫使用預定義優化方式(比如索引)來加快查詢操作,而Nosql更簡單更精確的數據訪問模式。

6.事務

關係型數據庫遵循ACID規則(原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)),而Nosql數據庫遵循BASE原則(基本可用(Basically Availble)、軟/柔性事務(Soft-state )、最終一致性(Eventual Consistency))。由於關係型數據庫的數據強一致性,所以對事務的支持很好。關係型數據庫支持對事務原子性細粒度控制,並且易於回滾事務。而Nosql數據庫是在CAP(一致性、可用性、分區容忍度)中任選兩項,因為基於節點的分佈式系統中,很難全部滿足,所以對事務的支持不是很好,雖然也可以使用事務,但是並不是Nosql的閃光點。

7.性能

關係型數據庫為了維護數據的一致性付出了巨大的代價,讀寫性能比較差。在面對高併發讀寫性能非常差,面對海量數據的時候效率非常低。而Nosql存儲的格式都是key-value類型的,並且存儲在內存中,非常容易存儲,而且對於數據的 一致性是 弱要求。Nosql無需sql的解析,提高了讀寫性能。

大多數的關係型數據庫都是付費的並且價格昂貴,成本較大(MySQL是開源的,所以應用的場景最多),而Nosql數據庫通常都是開源的。


所以,在實際的應用環境中,我們一般會使用MySQL存儲我們的業務過程中的數據,因為這些數據之間的關係比較複雜,我們常常會需要在查詢一個表的數據時候,將其他關係表的數據查詢出來,例如,查詢某個用戶的訂單,那至少是需要用戶表和訂單表的數據。

查詢某個商品的銷售數據,那可能就會需要用戶表,訂單表,訂單明細表,商品表等等。

而在這樣的使用場景中,我們使用Redis來存儲的話,也就是KeyValue形式存儲的話,其實並不能滿足我們的需要。

即使Redis的讀取效率再高,我們也沒法用。

但,對於某些沒有關聯少,且需要高頻率讀寫,我們使用Redis就能夠很好的提高整個體統的併發能力。

例如商品的庫存信息,我們雖然在MySQL中會有這樣的字段,但是我們並不想MySQL的數據庫被高頻的讀寫,因為使用這樣會導致我的商品表或者庫存表IO非常高,從而影響整個體統的效率。

所以,對於這樣的數據,且有沒有什麼複雜邏輯關係(就只是隸屬於SKU)的數據,我們就可以放在Redis裡面,下單直接在Redis中減掉庫存,這樣,我們的訂單的併發能力就能夠提高了。


會技術的葛大爺


個人覺得應該站出來更正一下,相反的數據量大,更不應該用redis。


為什麼?<strong>

因為redis是內存型數據庫啊,是放在內存裡的。

設想一下,假如你的電腦100G的資料,都用redis來存儲,那麼你需要100G以上的內存!

使用場景

  • 緩存

Redis最明顯的用例之一是將其用作緩存。只是保存熱數據,或者具有過期的cache。

例如facebook,使用Memcached來作為其會話緩存。

faceboo使用memcached來緩解數據庫負,使用超過800臺服務器為用戶提供超過28 TB的內存。


  • 隊列

  • 排行榜/計數

  • Pub 發佈/ Sub訂閱


總之,沒有見過哪個大公司數據量大了,換掉mysql用redis的。


歡迎關注,解鎖更多,同步進步!

小鳥攻城獅


首先,不是選用redis或者mysql是根據數據多少來定的,這兩個數據庫的用法區別並不是在於儲存數據的多少。

其次,我們來看下這兩個數據庫,mysql是一種關係數據庫管理系統,是持久化儲存,它將數據保存在不同的表中。而redis是一個高性能的key-value數據庫,它並不存在關係型數據庫。redis的數據是緩存並留駐在內存中運行的,而mysql的是放在磁盤中的,單就這點來說,你還會覺得這個問題問得正確嗎?mysql是關係型數據庫,它的功能比較強大,但是當cpu訪問數據時,它可不會先去訪問磁盤,而是先去訪問內存當前正在運行的那部分數據,這樣以來,redis的速度就要比mysql快。一般中小型網站的開發選擇用mysql,因為mysq體積小、速度快、總體擁有成本低,還有一個特殊的地方,就是源代碼公開。但是對於大型互聯網公司來說,mysq就很難滿足他們的需求,因為特定的系統絕大部分的檢索在很多時候都是基於主鍵的查詢,這樣一來,如果選用關係型數據庫的話,那麼將會使得效率比較低下。一般web每次只訪問redis,然後在沒有找到數據的情況下,才去訪問mysql,因此,選擇key-value數據庫就是無可厚非的。

最後,我覺得,你在選擇時應該是要看情況是怎樣的,哪種更符合需求,而不是單看數據的大小。


紅塵小書童


Redis是內存數據庫,數據保存在內存中,速度快。

Mysql是關係型數據庫,數據存儲在磁盤中,數據訪問也就慢。

redis適合放一些頻繁使用,比較熱的數據,因為是放在內存中,讀寫速度都非常快 。

目前大多數公司的存儲都是mysql + redis,mysql作為主存儲,redis作為輔助存儲被用作緩存,加快訪問讀取的速度,提高性能


語言密碼


redis是Nosql數據庫中使用較為廣泛的非關係型內存數據庫,redis內部是一個key-value存儲系統。它支持存儲的value類型相對更多,包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set –有序集合)和hash(哈希類型,類似於Java中的map)。Redis基於內存運行並支持持久化的NoSQL數據庫,是當前最熱門的NoSql數據庫之一,也被人們稱為數據結構服務器。


樂哈哈電影


不能籠統的這麼說,這兩個東西有完全不同的應用場景。也要看數據多到什麼程度。

redis是一個內存數據結構的服務,它將數據存儲在內存中,從而實現了非常好的吞吐量和性能。它有提供了很豐富的數據結構,特別適合社交類業務的系統。但是內存數據庫要求服務器的內存足夠才行,存儲的數據量越大消耗的內存也就越大,如果內存不夠就會導致操作系統進行內存到磁盤的交換結構性能急劇下降。新浪微博的數據存儲就是用的redis來實現的。

mysql是一個傳統的數據庫系統,因為它的架構非常的靈活,可以集成很多不同方式的存儲。mysql因為大部分都是磁盤操作自然性能比不上redis,但是支持事務等功能。適合於各種業務系統,對於海量的數據存儲並沒有問題。Facebook用的是MySQL的集群。

數據量大,有多大,業務是什麼樣,不能一概而論。用的好一樣可以解決大部分的問題,新浪微博的冷數據就是用MySQL。


平凡的上班族


數據多而且調用頻繁的話,用mysql存儲的話數據庫連接被一直佔用,其它的數據請求就進來了,導致連接超時,數據量大的話,數據庫直接死機了。只能重啟才能解決問題。



這個時候如果把數據請求量大的數據放在redis中的話就可以分擔一下mysql的壓力,從而提高系統的性能,解決請求併發問題。


分享到:


相關文章: