redis數(shù)據(jù)庫有哪些特點?

redis是一個使用ANSI C編寫的開源、支持網(wǎng)絡(luò)、基于內(nèi)存、可選持久性的鍵值對存儲數(shù)據(jù)庫。是NoSQL(非關(guān)系型數(shù)據(jù)庫)的典型代表，也是時下是最流行的鍵值對存儲數(shù)據(jù)庫。它支持字符串、哈希、鏈表、集合、有序集合五種數(shù)據(jù)存儲類型。由于其基于內(nèi)存運行的特性，相較于基于硬盤的數(shù)據(jù)庫系統(tǒng)，從執(zhí)行效率上講有非常大的優(yōu)勢。但其本身的讀與寫的速度沒有太大的差別。如果對這部分內(nèi)容感興趣，可以從黑馬程序員獲取測試相關(guān)課程了解一下。也有免費的公開課，官網(wǎng)對話框問一下就給

余杭ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

ElasticSearch海量數(shù)據(jù)使用簡述

應(yīng)用場景當中經(jīng)常會遇到模糊查詢或多條件匹配查詢，數(shù)據(jù)量較小的情況下通過簡單的數(shù)據(jù)庫模糊查詢是可以解決的，但是對于數(shù)據(jù)量龐大的情況，數(shù)據(jù)庫模糊查詢就會出現(xiàn)性能問題。這種情況下的一種解決方案就是根據(jù)查詢內(nèi)容構(gòu)建反向索引，借助搜索引擎進行查詢，提升查詢性能。

目前使用比較多的分布式搜索引擎是ElasticSearch。那么項目中如何使用ES？如何保證ES的數(shù)據(jù)更新？下面簡單做個描述。

Elasticsearch使用可以簡單分為兩個階段。數(shù)據(jù)初始化階段、數(shù)據(jù)更新階段。

數(shù)據(jù)初始化階段。數(shù)據(jù)初始化常見的方式如下：

一、通過應(yīng)用程序手動將數(shù)據(jù)庫中的數(shù)據(jù)，調(diào)用ES接口API插入ES索引庫中。

二、同過數(shù)據(jù)遷移工具將數(shù)據(jù)初始化到ES數(shù)據(jù)庫。目前常用的ES同步工具有l(wèi)ogstash-input-jdbc、DataX。通過同步遷移工具可以全量將數(shù)據(jù)庫數(shù)據(jù)初始化到ES索引庫中。

數(shù)據(jù)更新階段。數(shù)據(jù)更新階段常見的處理方式如下：

一、通過應(yīng)用服務(wù)直接調(diào)用ES更新接口。這種方式實現(xiàn)比較簡單但是對業(yè)務(wù)侵入性比較大。

二、對于實時性要求不高的可以采用定時任務(wù)監(jiān)控數(shù)據(jù)表變化然后調(diào)用ES接口實現(xiàn)數(shù)據(jù)更新。

三、業(yè)務(wù)應(yīng)用中通過發(fā)送消息異步更新數(shù)據(jù)。

四、通過DataX同步工具定時將修改的數(shù)據(jù)同步到ES庫中。

上述是ElasticSearch使用的簡單描述。使用的關(guān)鍵還是數(shù)據(jù)庫與ES間的數(shù)據(jù)同步。能否用的好關(guān)鍵也是數(shù)據(jù)間的同步。

NewSQL為何使傳統(tǒng)關(guān)系數(shù)據(jù)庫黯然失色？

傳統(tǒng)數(shù)據(jù)庫仍舊會有一席之地，至于NewSQL的優(yōu)勢又是什么，簡單和大家說說：

首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫分庫分表”算不算NewSQL分布式數(shù)據(jù)庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是第一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫，本文暫不詳細介紹）。

基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關(guān)系數(shù)據(jù)庫（分庫分表）模式是不是分布式架構(gòu)？我覺得是的，因為存儲確實也分布式了，也能實現(xiàn)橫向擴展。但是不是“偽”分布式數(shù)據(jù)庫？從架構(gòu)先進性來看，這么說也有一定道理。

“偽”主要體現(xiàn)在中間件層與底層DB重復(fù)的SQL解析與執(zhí)行計劃生成、存儲引擎基于B+Tree等，這在分布式數(shù)據(jù)庫架構(gòu)中實際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫特指這種新架構(gòu)NewSQL數(shù)據(jù)庫。

NewSQL數(shù)據(jù)庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構(gòu)對比圖：

傳統(tǒng)數(shù)據(jù)庫面向磁盤設(shè)計，基于內(nèi)存的存儲管理及并發(fā)控制，不如NewSQL數(shù)據(jù)庫那般高效利用；

中間件模式SQL解析、執(zhí)行計劃優(yōu)化等在中間件與數(shù)據(jù)庫中重復(fù)工作，效率相比較低；

NewSQL數(shù)據(jù)庫的分布式事務(wù)相比于XA進行了優(yōu)化，性能更高；

新架構(gòu)NewSQL數(shù)據(jù)庫存儲設(shè)計即為基于paxos（或Raft）協(xié)議的多副本，相比于傳統(tǒng)數(shù)據(jù)庫主從模式（半同步轉(zhuǎn)異步后也存在丟數(shù)問題），在實現(xiàn)了真正的高可用、高可靠（RTO30s，RPO=0）；

NewSQL數(shù)據(jù)庫天生支持數(shù)據(jù)分片，數(shù)據(jù)的遷移、擴容都是自動化的，大大減輕了DBA的工作，同時對應(yīng)用透明，無需在SQL指定分庫分表鍵。

elasticsearch可以代替NoSQL嗎

ES完全勝任MongoDB能干的事情，而且還加上了檢索功能，你可以選擇分詞檢索或者把你存的整個文檔當作一個詞，前者類似于搜索引擎，后者類似于數(shù)據(jù)庫，而且ES最擅長的就是用Facet和Agg做數(shù)據(jù)統(tǒng)計，當不分詞時，可以結(jié)合Redis等把詞條映射為整形數(shù)，查詢效率會非常高。而且數(shù)據(jù)分區(qū)更靈活，可以隨時以編碼的方式打開或關(guān)閉某部分數(shù)據(jù)節(jié)點。一般來說，把ES以數(shù)據(jù)庫的模式存儲，合理使用查詢語法，都可以秒級返回，不管多大的數(shù)據(jù)量，當然做統(tǒng)計肯定會慢一些。對有些特殊查詢注意一下就行了：比如用wildcard的 *keyword 模式就比 keyword*模式要慢很多，需要合理規(guī)劃自己的業(yè)務(wù)場景和數(shù)據(jù)的mapping映射方式。