1.1 技術發展
redis是用來解決性能問題的資料庫
技術的分類：
- 解決功能性問題：Java、Jsp、RDBMS、Tomcat、HTML、Linux、JDBC、SVN
- 解決擴展性問題：Struts、Spring、SpringMVC、Hibernate、Mybatis
- 解決性能問題：
NoSQL、Java執行緒、Hadoop、Nginx、MQ、ElasticSearch
1.1.1 Web1.0時代
在Web1.0時代，資料訪問量很有限，用一夫當關的高性能的單點服務器可以解決大部分問題，
1.1.2 Web2.0時代
隨著Web2.0的時代的到來，用戶訪問量大幅度提升，同時產生了大量的用戶資料，加上后來的智能移動設備的普及，所有的互聯網平臺都面臨了巨大的性能挑戰，如果我們依然使用單體的架構服務，那么服務器無法承受大量用戶的訪問，會導致服務器的CPU有很大的壓力，并且資料庫有IO壓力，
1.1.3 解決CPU及記憶體壓力
問題：session我們存盤在哪？
-
存盤在cookie中
缺點：cookie一般存盤在客戶端中，所以不安全 -
存盤在檔案服務器或者資料庫里
缺點：會有大量的IO效率問題 -
session復制，用戶一開始訪問，服務器A存盤了用戶的資訊，第二次用戶訪問的時候，請求走向了服務器B，但此時session在服務器A上，所以就將session復制一份給服務器B即可
缺點：session資料冗余，節點越多越浪費 -
存盤在快取資料庫中
優點：完全存盤在記憶體中，讀取速度更快，資料結構簡單
1.1.4 解決IO壓力
當你資料庫中的資料越來越多，那么一般你就會使用分庫分表的技術，但是它會破壞一定的業務邏輯來換取性能，它不是最好的處理方式，我們可以把頻繁查詢的資料放入快取資料庫中，它能極大的提高你的查詢速度，減少io的讀操作，
1.2 NoSQL
1.2.1 NoSQL資料庫概述
NoSQL(Not Only SQL)，意思是"不僅僅是SQL"，泛指非關系型資料庫，
NoSQL不依賴業務邏輯方式存盤，而是以簡單的key-value模式存盤，因此大大的增加了資料庫的擴展能力，
它有以下特性：
- 不遵循SQL標準
- 不支持ACID
- 遠超SQL的性能
1.2.2 NoSQL適用場景
- 對資料高并發的讀寫
- 海量資料的讀寫
- 對資料高可擴展性的
1.2.3 NoSQL不適用場景
- 需要事務支持
- 基于sql的結構化查詢存盤，處理復雜的關系，需要
即席查詢
總結：用不著SQL和用了SQL也解決不了的情況，請考慮使用NoSQL
1.2.4 常見的NoSQL資料庫
- Memcache
- 很早出現的NoSQL資料庫
- 資料都在記憶體中，一般不持久化
- 支持簡單的key-value模式，支持型別單一
- 一般是作為
快取資料庫輔助持久化的資料庫
- Redis
- 幾乎覆寫了Memcached的絕大部分功能
- 資料都在記憶體中，支持持久化，主要用作備份恢復
- 除了支持簡單的key-value模式，還支持多種資料結構的存盤，比如list、set、hash、zset等
- 一般是作為
快取資料庫輔助持久化的資料庫
- MongoDB
- 高性能、開源、模式自由的
檔案型資料庫 - 資料都在記憶體中，如果記憶體不足，把不常用的資料保存到硬碟中
- 雖然是key-value模式，但是對value(尤其是
json)提供了豐富的查詢功能 - 支持二進制資料及大型物件
- 可以根據資料的特點替代RDBMS，成為獨立的資料庫，或者配合RDBMS，存盤特定的資料
- 高性能、開源、模式自由的
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/544902.html
標籤：NoSQL
上一篇：MySQL調優
下一篇：搜索EE場景排序鏈路升級