◆ NoSQL資料存儲
傳統的架構方法是在服務之間共享一個資料庫，而微服務卻與之相反，每個微服務都擁有獨立、自主、專門的資料存儲。微服務資料存儲是基礎設施建構的重點，因為它提供服務解耦、資料存儲自主性、小型化開發、測試設定等特性，有助于應用程式更快地傳遞或更新。選擇理想的資料存儲的第一步是确定微服務資料的性質，可以根據資料的特點将資料大緻做如下劃分。
- 全局共享資料：緩存伺服器是存儲短暫資料很好的例子。它是一個臨時資料存儲，其目的是通過實時提供資訊來改善使用者體驗。
- 事務資料：從交易（如付款處理和訂單處理）收集的資料必須作為永久記錄存儲在支援強ACID控制的資料庫中。
- 加速資料：日志、消息和信号等資料通常以高容量和速度到達。資料提取服務通常要在将其傳遞到适當的目的地之前處理該資訊，這樣的資料存儲需要支援高速寫入。如果額外支援時間序列資料和内置JSON功能，會是一個加分項。瞬态資料的持久性要求高于短暫資料，但不如交易資料高。
- 操作資料：從使用者會話收集的資訊（如使用者基本資料、訂單資訊）被視為操作資料。微伺服器需要提供更好的使用者體驗與實時回報，即使存儲在資料庫中的資料不是永久的記錄，架構也必須盡最大努力保留資料以實作業務的連續性。對于操作資料，資料的持久性、一緻性和可用性要求很高。通常，企業會把操作資料放在特定的資料模型中。
為了優化微服務以獲得性能和資料持久性要求，一定要确認所選的資料庫為資料類型提供了适當的存儲技術。我們可以對微服務及其各自的資料存儲進行分類，如下表所示。
- 如果追求高性能，那麼純記憶體資料庫是理想的選擇。
- 如果追求持久性，那麼資料複制及磁盤或閃存上的持久性是最好的解決方案。
- 如果追求事務一緻性和複雜的關聯查詢，則可以采用資料庫查詢。
- 如 果 追 求 查 詢 性 能 ， 高 速 寫 入 數 據 ， 則 可 以 選 擇Elasticsearch。
- 如果是對JSON類資料的寫入和讀取，則可以使用文檔資料庫。
- 如果選擇寫入時序類型資料，則可以使用時序性資料庫。
下面是四類常見的NoSQL方案。
- K-V存儲：解決關系資料庫無法存儲資料結構的問題，主要适合對全局資料進行快速查找的低延時、高性能場景，以Redis為代表。
- 文檔資料庫：解決關系資料庫強Schema限制的問題，主要适合動态模式變更和支援靈活開發的場景，以MongoDB為代表。
- 列式資料庫：解決關系資料庫在大資料場景下的I/O問題，主要适合對資料量比較大或者對資料統計OLAP和聚合統計的場景，以HBase為代表。
- 全文搜尋引擎：解決關系資料庫的全文搜尋性能問題，主要适合檢索及過濾，以Elasticsearch為代表。
下面來介紹各種高性能NoSQL方案的典型特征和應用場景。
◆ K-V存儲
K-V存儲指按照鍵值（Key-Value）進行的資料存儲，其中Key是資料的辨別，和關系資料庫中的主鍵含義一樣；Value是具體的資料。
Redis是K-V存儲的典型代表，它是一款開源（基于BSD許可）的高性能K-V緩存和存儲系統。Redis的Value是具體的資料結構，包括string、hash、list、set、sorted set、bitmap和hyperloglog，是以常被稱為資料結構伺服器。
K-V存儲适合作為分布式記憶體緩存的解決方案。在微服務架構中，微服務共享的一些全局資料都儲存在K-V存儲中，例如，使用者資訊（如會話）、分布式鎖、配置檔案、參數、購物車等。這些資訊一般都和ID挂鈎。通過鍵值操作就可以獲得共享的Value，Redis提供的主從複制模式（Replication-Sentinel模式）和叢集模式（Redis-Cluster模式）可以很好地提供多資料中心、多向複制等高度可用性和高度擴充性。Redis高性能的資料存儲總結下來有下面幾個原因。
- Redis将所有資料放在記憶體中，記憶體的響應時間大約為100ns，這是Redis達到每秒萬級别通路的重要基礎。
- 非阻塞I/O特性，Redis使用epoll作為I/O多路複用技術的實作，再加上Redis自身的事件處理模型，将epoll中的連結、讀寫、關閉都轉換為事件，不在網絡I/O上耗費時間。
- 單線程避免了線程切換和鎖産生的消耗。
- Redis全程使用hash結構，讀取速度快，還有一些特殊的資料結構，對資料存儲進行了優化。如壓縮表，對短資料進行壓縮存儲；再如跳表，使用有序的資料結構加快讀取的速度。
◆ 文檔資料庫
為了解決關系資料庫Schema帶來的問題，文檔資料庫應運而生。MongoDB作為文檔資料庫的典型代表，是專為可擴充性、高性能和高可用性設計的資料庫。它可以從單伺服器部署擴充到大型、複雜的多資料中心架構。利用記憶體計算的優勢，MongoDB能夠提供高性能的資料讀寫操作。MongoDB的本地複制和自動故障轉移功能使應用程式具有企業級的可靠性和操作靈活性。
文檔資料庫最大的特點就是No-Schema（不使用表結構）存儲和可讀取任意資料。目前絕大部分文檔資料庫存儲的資料格式是JSON，因為JSON資料是自描述的，讀取一個JSON中不存在的字段也不會導緻SQL那樣的文法錯誤。文檔資料庫的No-Schema特性，為業務開發帶來了幾個明顯的優勢。
- 新增字段簡單：業務上增加新的字段，無須再像關系資料庫一樣先執行DDL修改表結構，程式代碼直接讀寫即可。
- 容易相容曆史資料：對于曆史資料，即使沒有新增的字段，也不會導緻錯誤，隻會傳回空值，此時對代碼進行相容處理即可。
- 容易存儲複雜資料：JSON是一種強大的描述語言，能夠描述複雜的資料結構。使用JSON來描述資料，比使用關系資料庫表來描述資料要友善和容易得多，而且更加容易了解。同時，對于很多資料在屬性差别比較大的情況下，也比較适合采用文檔資料庫；對于屬性變更的場景，關系資料庫需要使用DDL重新定義表字段，而文檔資料庫則更加友善。
◆ 列式資料庫
顧名思義，列式資料庫就是按照列來存儲資料的資料庫，與之對應的傳統關系資料庫被稱為“行式資料庫”，關系資料庫就是按照行來存儲資料的。
HBase是一個開源的非關系分布式資料庫，它參考了谷歌的BigTable模組化，實作的程式設計語言為Java。它是Apache軟體基金會Hadoop項目的一部分，運作于HDFS檔案系統上，為Hadoop提供類似BigTable規模的服務。是以，它可以存儲海量稀疏的資料。HBase基于LSM樹實作，它将對資料的修改增量保持在記憶體中，達到指定的大小後将這些修改操作批量寫入磁盤。在極端情況下，寫性能比MySQL高一個數量級，讀性能低一個數量級，是以列式資料庫的适用場景，以HBase為例說明如下：
- 适合大資料量（100TB級資料），有快速随機通路的需求。
- 适合寫密集型應用，每天寫入量巨大，比如即時消息的曆史消息、遊戲日志等。
- 适合不需要使用複雜查詢條件來查詢資料的應用。HBase隻支援基于Rowkey的查詢，對于HBase來說，單條記錄或者小範圍的查詢是可以接受的。但由于分布式的原因，大範圍的查詢可能在性能上有影響。HBase不适用于使用級聯、多級索引、表關系複雜的資料模型。
- 适合資料量較大且增長量無法預估的應用，以及需要進行優雅的資料擴充的應用。HBase支援線上擴充，即使在一段時間内，資料量呈井噴式增長，也可以通過HBase橫向擴充來滿足功能需求。
◆ 全文搜尋引擎
傳統的關系資料庫通過索引來達到快速查詢的目的，但是在全文搜尋的業務場景下，索引也無能為力，主要展現在：全文搜尋的條件可以随意排列組合，如果通過索引來滿足，則索引的數量會非常多。
全文搜尋的模糊比對方式，索引無法滿足，隻能用like查詢，而like查詢是整表掃描的，效率非常低。全文搜尋引擎（又稱為反向索引）的基本原理是建立單詞到文檔的索引。而正排索引的基本原理是建立文檔到單詞的索引。Elasticsearch是一個分布式可擴充的實時搜尋和分析引擎，一個建立在全文的搜尋引擎。當然Elasticsearch并不像Apache Lucene那麼簡單，它不僅具有全文搜尋功能，還具有下列特性和能力：
- 分布式實時檔案存儲，并将每一個字段都編入索引，使其可以被搜尋。
- 實時分析的分布式搜尋引擎。
- 橫向可擴充性：作為大型分布式叢集，很容易就能擴充新的伺服器到ES叢集中，處理PB級别的結構化或非結構化資料；也可運作在單機上作為輕量級搜尋引擎使用。
- 更豐富的功能：與傳統的關系資料庫相比，Elasticsearch提供了全文檢索、同義詞處理、相關度排名、複雜資料分析、海量資料的近實時處理等功能。
- 分片機制提供更好的分布性：同一個索引被分為多個分片（Shard），利用分而治之的思想提升處理效率。
- 高可用：提供副本（Replica）機制，一個分片可以設定多個副本，即使在某些伺服器當機後，叢集仍能正常工作。
- 開箱即用：提供簡單易用的API，使服務的搭建、部署和使用都很容易被操作。
下表是一份簡易的Elasticsearch和關系資料庫的術語對照表。
一個Elasticsearch叢集可以包含多個索引（資料庫），也就是說可以包含很多類型。這些類型中包含了很多的文檔（行），然後每個文檔中又都包含了很多字段（列）。Elasticsearch的互動可以使用Java Native API，也可以使用HTTP的Restful API。Elasticsearch通過Lucene的反向索引技術可以實作比關系資料庫更快的過濾。
Elasticsearch可以為任何形式的資料提供出色的搜尋和分析，通過Kibana提供互動式控制台。我們經常使用Elasticsearch來調試日志用例。
來源：
https://www.toutiao.com/article/7097471371168662048/?log_from=3230af473fd71_1654825830746
“IT大咖說”歡迎廣大技術人員投稿，投稿郵箱：[email protected]
來都來了，走啥走，留個言呗~
IT大咖說 | 關于版權
由“IT大咖說（ID：itdakashuo）”原創的文章，轉載時請注明作者、出處及微信公衆号。投稿、約稿、轉載請加微信：ITDKS10（備注：投稿），茉莉小姐姐會及時與您聯系！
感謝您對IT大咖說的熱心支援！
-
相關推薦
推薦文章
- 幹貨：RabbitMQ核心概念及工作原理
- 中進階程式員可能都不會使用spring-boot-starter-jdbc通路MySQL
- 探索雲原生技術之基石——Docker容器
- 一種并行，背壓的Kafka Consumer
- Nomad正在接管Kubernetes嗎
- MIT協定分布式檔案系統，一個簡單、友善的檔案存儲方案
- 深入淺出 Nginx 實戰與架構原理
- 技術專家帶你徹底掌握線程池
- 基于GF的背景管理系統，完善的權限使用者管理，緻力于快速高效開發
- Java 工程師相見恨晚的神兵利器和使用技巧
- MySQL 故障診斷：MySQL 占用 CPU 過高問題定位及優化