有哪些輕型的非關系型數(shù)據(jù)庫？

常見的非關系型數(shù)據(jù)庫有：1、mongodb；2、cassandra；3、redis；4、hbase；5、neo4j。其中mongodb是非常著名的NoSQL數(shù)據(jù)庫，它是一個面向文檔的開源數(shù)據(jù)庫。

成都創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站建設、網(wǎng)站重做改版、廊坊網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5頁面制作、商城建設、集團公司官網(wǎng)建設、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為廊坊等各大城市提供網(wǎng)站開發(fā)制作服務。

常見的幾種非關系型數(shù)據(jù)庫：

1、MongoDB

MongoDB是最著名的NoSQL數(shù)據(jù)庫。它是一個面向文檔的開源數(shù)據(jù)庫。MongoDB是一個可伸縮和可訪問的數(shù)據(jù)庫。它在c++中。MongoDB同樣可以用作文件系統(tǒng)。在MongoDB中，JavaScript可以作為查詢語言使用。通過使用sharding MongoDB水平伸縮。它在流行的JavaScript框架中非常有用。

人們真的很享受分片、高級文本搜索、gridFS和map-reduce功能。驚人的性能和新特性使這個NoSQL數(shù)據(jù)庫在我們的列表中名列第一。

特點：提供高性能；自動分片；運行在多個服務器上；支持主從復制；數(shù)據(jù)以JSON樣式文檔的形式存儲；索引文檔中的任何字段；由于數(shù)據(jù)被放置在碎片中，所以它具有自動負載平衡配置；支持正則表達式搜索；在失敗的情況下易于管理。

優(yōu)點：易于安裝MongoDB；MongoDB Inc.為客戶提供專業(yè)支持；支持臨時查詢；高速數(shù)據(jù)庫；無模式數(shù)據(jù)庫；橫向擴展數(shù)據(jù)庫；性能非常高。

缺點：不支持連接；數(shù)據(jù)量大；嵌套文檔是有限的；增加不必要的內(nèi)存使用。

2、Cassandra

Cassandra是Facebook為收件箱搜索開發(fā)的。Cassandra是一個用于處理大量結構化數(shù)據(jù)的分布式數(shù)據(jù)存儲系統(tǒng)。通常，這些數(shù)據(jù)分布在許多普通服務器上。您還可以添加數(shù)據(jù)存儲容量，使您的服務保持在線，您可以輕松地完成這項任務。由于集群中的所有節(jié)點都是相同的，因此不需要處理復雜的配置。

Cassandra是用Java編寫的。Cassandra查詢語言(CQL)是查詢Cassandra數(shù)據(jù)庫的一種類似sql的語言。因此，Cassandra在最佳開源數(shù)據(jù)庫中排名第二。Facebook、Twitter、思科(Cisco)、Rackspace、eBay、Twitter、Netflix等一些最大的公司都在使用Cassandra。

特點：線性可伸縮；；保持快速響應時間；支持原子性、一致性、隔離性和耐久性(ACID)等屬性；使用Apache Hadoop支持MapReduce；分配數(shù)據(jù)的最大靈活性；高度可伸縮；點對點架構。

優(yōu)點：高度可伸縮；無單點故障；Multi-DC復制；與其他基于JVM的應用程序緊密集成；更適合多數(shù)據(jù)中心部署、冗余、故障轉移和災難恢復。

缺點：對聚合的有限支持；不可預知的性能；不支持特別查詢。

3、Redis

Redis是一個鍵值存儲。此外，它是最著名的鍵值存儲。Redis支持一些c++、PHP、Ruby、Python、Perl、Scala等等。Redis是用C語言編寫的。此外，它是根據(jù)BSD授權的。

特點：自動故障轉移；將其數(shù)據(jù)庫完全保存在內(nèi)存中；事務；Lua腳本；將數(shù)據(jù)復制到任意數(shù)量的從屬服務器；鑰匙的壽命有限；LRU驅逐鑰匙；支持發(fā)布/訂閱。

優(yōu)點：支持多種數(shù)據(jù)類型；很容易安裝；非常快（每秒執(zhí)行約11萬組，每秒執(zhí)行約81000次）；操作都是原子的；多用途工具（在許多用例中使用）。

缺點：不支持連接；存儲過程所需的Lua知識；數(shù)據(jù)集必須很好地適應內(nèi)存。

4、HBase

HBase是一個分布式的、面向列的開源數(shù)據(jù)庫，該技術來源于 Fay Chang 所撰寫的Google論文“Bigtable：一個結構化數(shù)據(jù)的分布式存儲系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（File System）所提供的分布式數(shù)據(jù)存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。

HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系數(shù)據(jù)庫，它是一個適合于非結構化數(shù)據(jù)存儲的數(shù)據(jù)庫。另一個不同的是HBase基于列的而不是基于行的模式。

5、neo4j

Neo4j被稱為原生圖數(shù)據(jù)庫，因為它有效地實現(xiàn)了屬性圖模型，一直到存儲層。這意味著數(shù)據(jù)完全按照白板的方式存儲，數(shù)據(jù)庫使用指針導航和遍歷圖。Neo4j有數(shù)據(jù)庫的社區(qū)版和企業(yè)版。企業(yè)版包括Community Edition必須提供的所有功能，以及額外的企業(yè)需求，如備份、集群和故障轉移功能。

特點：它支持唯一的約束；Neo4j支持完整的ACID(原子性、一致性、隔離性和持久性)規(guī)則；Java API: Cypher API和本機Java API；使用Apache Lucence索引；簡單查詢語言Neo4j CQL；包含用于執(zhí)行CQL命令的UI: Neo4j Data Browser。

優(yōu)點：容易檢索其相鄰節(jié)點或關系細節(jié)，無需連接或索引；易于學習Neo4j CQL查詢語言命令；不需要復雜的連接來檢索數(shù)據(jù)；非常容易地表示半結構化數(shù)據(jù)；大型企業(yè)實時應用程序的高可用性；簡化的調(diào)優(yōu)。

缺點：不支持分片

Redis是什么，用來做什么

Redis是一個nosql數(shù)據(jù)庫，可以存儲key-value值。因為其底層實現(xiàn)中，數(shù)據(jù)讀寫是基于內(nèi)存，速度非常快，所以常用于緩存；進而因其為獨立部署的中間件，常用于分布式緩存的實現(xiàn)方案。

常用場景有：緩存、秒殺控制、分布式鎖。

雖然其是基于內(nèi)存讀寫，但底層也有持久化機制；同時具備集群模式；不用擔心其可用性。

關于Redis的使用，可以參考《Redis的使用方法、常見應用場景》

網(wǎng)易傳媒技術團隊：消息中間件實現(xiàn)延遲隊列的應用與實踐

早期需要延遲處理的業(yè)務場景，更多的是通過定時任務掃表，然后執(zhí)行滿足條件的記錄，具有頻率高、命中低、資源消耗大的缺點。隨著消息中間件的普及，延遲消息可以很好的處理這種場景，本文主要介紹延遲消息的使用場景以及基于常見的消息中間件如何實現(xiàn)延遲隊列，最后給出了一個在網(wǎng)易公開課使用延遲隊列的實踐。

1、有效期：限時活動、拼團。。。

2、超時處理：取消超時未支付訂單、超時自動確認收貨。。。

4、重試：網(wǎng)絡異常重試、打車派單、依賴條件未滿足重試。。。

5、定時任務：智能設備定時啟動。。。

1、RabbitMQ

1）簡介：基于AMQP協(xié)議，使用Erlang編寫，實現(xiàn)了一個Broker框架

a、Broker：接收和分發(fā)消息的代理服務器

b、Virtual Host：虛擬主機之間相互隔離，可理解為一個虛擬主機對應一個消息服務

c、Exchange：交換機，消息發(fā)送到指定虛擬機的交換機上

d、Binding：交換機與隊列綁定，并通過路由策略和routingKey將消息投遞到一個或多個隊列中

e、Queue：存放消息的隊列，F(xiàn)IFO，可持久化

f、Channel：信道，消費者通過信道消費消息，一個TCP連接上可同時創(chuàng)建成百上千個信道，作為消息隔離

2）延遲隊列實現(xiàn)：RabbitMQ的延遲隊列基于消息的存活時間TTL（Time To Live）和死信交換機DLE（Dead Letter Exchanges）實現(xiàn)

a、TTL：RabbitMQ支持對隊列和消息各自設置存活時間，取二者中較小的值，即隊列無消費者連接或消息在隊列中一直未被消費的過期時間

b、DLE：過期的消息通過綁定的死信交換機，路由到指定的死信隊列，消費者實際上消費的是死信隊列上的消息

3）缺點：

a、配置麻煩，額外增加一個死信交換機和一個死信隊列的配置

b、脆弱性，配置錯誤或者生產(chǎn)者消費者連接的隊列錯誤都有可能造成延遲失效

2、RocketMQ

1）簡介：來源于阿里，目前為Apache頂級開源項目，使用Java編寫，基于長輪詢的拉取方式，支持事務消息，并解決了順序消息和海量堆積的問題

a、Broker：存放Topic并根據(jù)讀取Producer的提交日志，將邏輯上的一個Topic分多個Queue存儲，每個Queue上存儲消息在提交日志上的位置

b、Name Server：無狀態(tài)的節(jié)點，維護Topic與Broker的對應關系以及Broker的主從關系

2）延遲隊列實現(xiàn)：RocketMQ發(fā)送延時消息時先把消息按照延遲時間段發(fā)送到指定的隊列中(rocketmq把每種延遲時間段的消息都存放到同一個隊列中)，然后通過一個定時器進行輪訓這些隊列，查看消息是否到期，如果到期就把這個消息發(fā)送到指定topic的隊列中

3）缺點：延遲時間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）簡介：來源于Linkedin，目前為Apache頂級開源項目，使用Scala和Java編寫，基于zookeeper協(xié)調(diào)的分布式、流處理的日志系統(tǒng)，升級版為Jafka

2）延遲隊列實現(xiàn)：Kafka支持延時生產(chǎn)、延時拉取、延時刪除等，其基于時間輪和JDK的DelayQueue實現(xiàn)

a、時間輪(TimingWheel)：是一個存儲定時任務的環(huán)形隊列，底層采用數(shù)組實現(xiàn)，數(shù)組中的每個元素可以存放一個定時任務列表

b、定時任務列表(TimerTaskList)：是一個環(huán)形的雙向鏈表，鏈表中的每一項表示的都是定時任務項

c、定時任務項(TimerTaskEntry)：封裝了真正的定時任務TimerTask

d、層級時間輪：當任務的到期時間超過了當前時間輪所表示的時間范圍時，就會嘗試添加到上層時間輪中，類似于鐘表就是一個三級時間輪

e、JDK DelayQueue：存儲TimerTaskList，并根據(jù)其expiration來推進時間輪的時間，每推進一次除執(zhí)行相應任務列表外，層級時間輪也會進行相應調(diào)整

3）缺點：

a、延遲精度取決于時間格設置

b、延遲任務除由超時觸發(fā)還可能被外部事件觸發(fā)而執(zhí)行

4、ActiveMQ

1）簡介：基于JMS協(xié)議，Java編寫的Apache頂級開源項目，支持點對點和發(fā)布訂閱兩種模式。

a、點對點（point-to-point）：消息發(fā)送到指定的隊列，每條消息只有一個消費者能夠消費，基于拉模型

b、發(fā)布訂閱（publish/subscribe）：消息發(fā)送到主題Topic上，每條消息會被訂閱該Topic的所有消費者各自消費，基于推模型

2）延遲隊列實現(xiàn)：需要延遲的消息會先存儲在JobStore中，通過異步線程任務JobScheduler將到達投遞時間的消息投遞到相應隊列上

a、Broker Filter：Broker中定義了一系列BrokerFilter的子類構成攔截器鏈，按順序對消息進行相應處理

b、ScheduleBroker：當消息中指定了延遲相關屬性，并且jobId為空時，會生成調(diào)度任務存儲到JobStore中，此時消息不會進入到隊列

c、JobStore：基于BTree存儲，key為任務執(zhí)行的時間戳，value為該時間戳下需要執(zhí)行的任務列表

d、JobScheduler：取JobStore中最小的key執(zhí)行（調(diào)度時間最早的），執(zhí)行時間=當前時間，將該任務列表依次投遞到所屬的隊列，對于需要重復投遞和投遞失敗的會再次存入JobStore中。

注： 此處JobScheduler的執(zhí)行時間間隔可動態(tài)變化，默認0.5s，有新任務時會立即執(zhí)行（Object-notifyAll()）并設置時間間隔為0.1s，沒有新任務后，下次執(zhí)行時間為最近任務的調(diào)度執(zhí)行時間。

3）缺點：投遞到隊列失敗，將消息重新存入JobStore，消息調(diào)度執(zhí)行時間=系統(tǒng)當前時間+延遲時間，會導致消息被真實投遞的時間可能為設置的延遲時間的整數(shù)倍

5、Redis

1）簡介：基于Key-Value的NoSQL數(shù)據(jù)庫，由于其極高的性能常被當作緩存來使用，其數(shù)據(jù)結構支持：字符串、哈希、列表、集合、有序集合

2）延遲隊列實現(xiàn)：Redis的延遲隊列基于有序集合，score為執(zhí)行時間戳，value為任務實體或任務實體引用

3）缺點：

a、實現(xiàn)復雜，本身不支持

b、完全基于內(nèi)存，延遲時間長浪費內(nèi)存資源

6、消息隊列對比

1、公開課延遲隊列技術選型

1）業(yè)務場景：關閉超時未支付訂單、限時優(yōu)惠活動、拼團

2）性能要求：訂單、活動、拼團 數(shù)據(jù)量可控，上述MQ均能滿足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延遲隊列功能，且目前公開課業(yè)務中使用的中間件為ActiveMQ和Kafka

5）延遲時間靈活：活動的開始和結束時間比較靈活，而RocketMQ時間粒度較粗，Kafka會依賴時間格有精度缺失

結論： 最終選擇ActiveMQ來作為延遲隊列

2、業(yè)務場景：關閉未支付訂單

1）關閉微信未支付訂單

2）關閉IOS未支付訂單

3、ActiveMQ使用方式

1）activemq.xml中支持調(diào)度任務

2）發(fā)送消息時，設置message的延遲屬性

其中：

a、延遲處理

AMQ_SCHEDULED_DELAY：設置多長時間后，投遞給消費者（毫秒）

b、重復投遞

AMQ_SCHEDULED_PERIOD：重復投遞時間間隔（毫秒）

AMQ_SCHEDULED_REPEAT：重復投遞次數(shù)

c、指定調(diào)度計劃

AMQ_SCHEDULED_CRON：corn正則表達式

4、公開課使用中進行的優(yōu)化

1）可靠性：針對實際投遞時間可能翻倍的問題，結合ActiveMQ的重復投遞，在消費者邏輯中做冪等處理來保證延遲時間的準確性

2）可追溯性：延遲消息及消費情況做數(shù)據(jù)庫冗余存儲

3）易用性：業(yè)務上定義好延遲枚舉類型，直接使用JmsDelayTemplate發(fā)送，無需關心數(shù)據(jù)備份和參數(shù)等細節(jié)

1、無論是基于死信隊列還是基于數(shù)據(jù)先存儲后投遞，本質(zhì)上都是將延遲待發(fā)送的消息數(shù)據(jù)與正常訂閱的隊列分開存儲，從而降低耦合度

2、無論是檢查隊頭消息TTL還是調(diào)度存儲的延遲數(shù)據(jù)，本質(zhì)上都是通過定時任務來完成的，但是定時任務的觸發(fā)策略以及延遲數(shù)據(jù)的存儲方式?jīng)Q定了不同中間件之間的性能優(yōu)劣

張浩，2018年加入網(wǎng)易傳媒，高級Java開發(fā)工程師，目前在網(wǎng)易公開課主要做支付財務體系、版本迭代相關的工作。

標題名稱：支持發(fā)布訂閱的nosql,什么是發(fā)布訂閱
標題網(wǎng)址：http://vcdvsql.cn/article38/dsiiipp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、云服務器、網(wǎng)站營銷、品牌網(wǎng)站設計、域名注冊、ChatGPT

廣告

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