按照id查詢，mysql、es、hbase三個(gè)哪個(gè)更快？就我而言，沒有場(chǎng)景的速度測(cè)試是無賴的。根據(jù)需求場(chǎng)景優(yōu)化數(shù)據(jù)庫(kù)和選擇數(shù)據(jù)庫(kù)前后的速度肯定是不同的。如果在一般情況下只有一個(gè)ID索引，這意味著您需要

按照id查詢，mysql、es、hbase三個(gè)哪個(gè)更快？

就我而言，沒有場(chǎng)景的速度測(cè)試是無賴的。根據(jù)需求場(chǎng)景優(yōu)化數(shù)據(jù)庫(kù)和選擇數(shù)據(jù)庫(kù)前后的速度肯定是不同的。

如果在一般情況下只有一個(gè)ID索引，這意味著您需要通過此ID定位數(shù)據(jù)，那么MySQL是最快的。毫無疑問。

在非結(jié)構(gòu)化文檔中，ES是最快的，數(shù)據(jù)量越大，速度就越快，因?yàn)镋S是NoSQL非關(guān)系數(shù)據(jù)庫(kù)，沒有事務(wù)處理能力。然而，ES作為一種基于Lucence服務(wù)器的全文搜索服務(wù)，非常適合于全文搜索。然而，ES一般用于復(fù)雜多變的檢索環(huán)境，單一的ID不能反映ES的性能。

對(duì)于大規(guī)模數(shù)據(jù)，HBase絕對(duì)是根據(jù)范圍讀寫數(shù)據(jù)的最佳選擇，它為大規(guī)模數(shù)據(jù)場(chǎng)景提供了更好的可擴(kuò)展性。

。我會(huì)在這里發(fā)表所有有關(guān)科技的有趣文章。偶爾，我能回答一些有趣的問題。如果您有任何問題，可以隨時(shí)在評(píng)論區(qū)回復(fù)和討論。

海量日志數(shù)據(jù)存儲(chǔ)用elasticsearch和hbase哪個(gè)好？

HBase面向列，很好的添加字段

！ES適用于搜索和分析小規(guī)模數(shù)據(jù)，其速度比HBase快。

HBase穩(wěn)定可靠，可以通過Mr spark提取大量數(shù)據(jù)。

mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫(kù)分表之外，還有沒有其他的解決方式？

在正常配置下，MySQL只能承載2000萬數(shù)據(jù)（同時(shí)讀寫，表中有大文本字段，單服務(wù)器）?，F(xiàn)在已經(jīng)超過1億，而且還在增加，建議按以下方式處理：

1子表。它可以按時(shí)間或一定的規(guī)則進(jìn)行拆分，以便盡可能地查詢子表中的數(shù)據(jù)庫(kù)。這是最有效的方法。特別是寫，放入一個(gè)新表，并定期同步。如果記錄不斷更新，最好將寫入的數(shù)據(jù)放在redis中，并定期同步表3的大文本字段，將它們分隔成一個(gè)新的獨(dú)立表。對(duì)于較大的文本字段，可以使用NoSQL數(shù)據(jù)庫(kù)

4優(yōu)化體系結(jié)構(gòu)，或者優(yōu)化SQL查詢，避免聯(lián)合表查詢，盡量不要使用count（*）、in、recursion等性能消耗語句

5使用內(nèi)存緩存，或者在前端讀取時(shí)增加緩存數(shù)據(jù)庫(kù)。重復(fù)讀取時(shí)，直接從緩存中讀取。

以上是一種低成本的管理方法，基本上幾個(gè)服務(wù)器就可以做到，但是管理起來有點(diǎn)麻煩。

當(dāng)然，如果總體數(shù)據(jù)量特別大，并且您不關(guān)心投資成本，請(qǐng)使用cluster或tidb

lasticearch本身提供了一種用于同步數(shù)據(jù)的river機(jī)制。

在這里您可以找到目前政府推薦的河流：

但是HBase河不是政府提供的。

事實(shí)上，ES河非常簡(jiǎn)單。它是由用戶打包的jar包。Es負(fù)責(zé)查找節(jié)點(diǎn)并啟動(dòng)河流。如果節(jié)點(diǎn)失敗，它將自動(dòng)找到另一個(gè)節(jié)點(diǎn)來啟動(dòng)河流。

elasticsearch-hbase-river插件怎么安裝？

在基本功能方面，兩者確實(shí)有相似之處，但根據(jù)不同的業(yè)務(wù)需求，我認(rèn)為有幾點(diǎn)需要考慮：1。查詢復(fù)雜度：HBase支持簡(jiǎn)單的行或范圍查詢，如查詢主鍵所在行的數(shù)據(jù)，查詢開始/結(jié)束的范圍數(shù)據(jù)。完成更復(fù)雜的功能并不容易。