mysql表數(shù)據(jù)量太大，達(dá)到了1億多條數(shù)據(jù)，除了分庫(kù)分表之外，還有沒有其他的解決方式？在正常配置下，MySQL只能承載2000萬數(shù)據(jù)（同時(shí)讀寫，表中有大文本字段，單服務(wù)器）?，F(xiàn)在已經(jīng)超過1億，而且還在

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等性能消耗語(yǔ)句

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

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

當(dāng)然，如果整體數(shù)據(jù)量特別大，而且你不在乎投資成本，可以使用cluster，使用tidb

目前l(fā)ogstash沒有cluster的概述，并且支持多個(gè)es節(jié)點(diǎn)的配置

這似乎是一種輪換訓(xùn)練機(jī)制。

對(duì)于此es加載，不同的日志存儲(chǔ)可以配置不同的es節(jié)點(diǎn)。

并發(fā)數(shù)據(jù)給ES集群，如何實(shí)現(xiàn)數(shù)據(jù)的負(fù)載均衡？

首先，ES基于Lucene，這是一個(gè)非常成熟的索引方案，再加上一些分布式實(shí)現(xiàn)：集群、分片、復(fù)制等

ES的優(yōu)勢(shì)體現(xiàn)在以下幾個(gè)方面：

橫向可擴(kuò)展性：只需添加一個(gè)服務(wù)器，做一點(diǎn)配置，并啟動(dòng)ES進(jìn)程合并到集群中；

分片機(jī)制提供更好的分布：將同一索引分為多個(gè)分片，這類似于HDFS的分塊機(jī)制；分治可以提高處理效率，相信這是一個(gè)很大的優(yōu)勢(shì)，家里不陌生；

高可用性：很好提供一個(gè)復(fù)制機(jī)制，在這個(gè)機(jī)制中，可以為一個(gè)分區(qū)設(shè)置多個(gè)復(fù)制，這樣當(dāng)服務(wù)器停機(jī)時(shí)，集群仍然可以正常運(yùn)行，并且由于服務(wù)器停機(jī)而丟失的復(fù)制將恢復(fù)到其他可用節(jié)點(diǎn)；這也類似于HDFS的復(fù)制機(jī)制（HDFS中的默認(rèn)值是3個(gè)復(fù)制）當(dāng)然，我們也應(yīng)該知道它的缺點(diǎn)：

每個(gè)節(jié)點(diǎn)的一致性：它的默認(rèn)機(jī)制是通過組播機(jī)制同步元數(shù)據(jù)信息。然而，在一個(gè)繁忙的集群中，每個(gè)節(jié)點(diǎn)的元數(shù)據(jù)不一致可能是由網(wǎng)絡(luò)擁塞或節(jié)點(diǎn)處理能力飽和引起的，這就是所謂的大腦裂縫問題。這將使集群處于不一致的狀態(tài)。目前，還沒有一個(gè)完整的解決方案來解決這個(gè)問題，但是可以通過將工作節(jié)點(diǎn)和元數(shù)據(jù)節(jié)點(diǎn)分離來緩解這個(gè)問題。

沒有詳細(xì)的權(quán)限管理機(jī)制，也就是說沒有mysql這樣的不同用戶，每個(gè)用戶擁有不同的權(quán)限。結(jié)語(yǔ)：但是，從優(yōu)缺點(diǎn)的比較來看，我認(rèn)為還存在不足之處，值得一試。