Elasticsearch到底能玩多大的資料量

1樓：

單獨看es能玩多大資料意義不大，具體實踐中往往因為各種業務要求而無法繼續增加資料量。目大的方面考慮有如下幾點：

1、查詢速度。es可以支援的查詢型別多種多樣，單一的term匹配，複雜的historm agg，甚至父子文件模式下bool查詢之後繼續做文字高亮，資料量越大查詢時間越長。如果只是簡單的把資料寫進去然後按照id獲取資料，那就儘管往裡面寫資料吧。

2、寫入速度。資料量越大，寫入速度受影響的可能性越大。業務要求1小時的資料1小時內必須寫完，如果做不到就得考慮分索引或者分叢集了。

3、更新速度。同上，更新比單純的寫入操作更多，先get再merge再overwrite到es。

4、其他因素。

目前我遇到的es叢集，有1.5t-2t索引量的情況下，需要支援平均查詢在500ms以內的高併發高亮查詢。在我們的場景下這個量級不算小了。

elasticsearch 能夠儲存的資料量一般有多大

mysql到底能支援多大的資料量

2樓：娛樂小八卦啊

mysql 3.22 限制的表大小為4gb。由於在mysql 3.

23 中使用了myisam 儲存引擎，最大表尺寸增加到了65536tb（2567 – 1位元組）。由於允許的表尺寸更大，mysql資料庫的最大有效表尺寸通常是由作業系統對檔案大小的限制決定的，而不是由mysql內部限制決定的。

innodb 儲存引擎將innodb 表儲存在一個表空間內，該表空間可由數個檔案建立。這樣，表的大小就能超過單獨檔案的最大容量。表空間可包括原始磁碟分割槽，從而使得很大的表成為可能。

表空間的最大容量為64tb。

擴充套件資料

mysql資料庫中，資料量越來越大的優化方案：

單表優化可以從這幾個角度出發：

1、表分割槽

mysql在5.1之後才有的，可以看做是水平拆分，分割槽表需要在建表的需要加上分割槽引數，使用者需要在建表的時候加上分割槽引數；分割槽表底層由多個物理子表組成，但是對於**來說，分割槽表是透明的。

sql中的條件中最好能帶上分割槽條件的列，這樣可以定位到少量的分割槽上，否則就會掃描全部分割槽。

2、增加快取

主要的思想就是減少對資料庫的訪問，快取可以在整個架構中的很多地方；比如：資料庫本身有就快取，客戶端快取，資料庫訪問層對sql語句的快取，應用程式內的快取，第三方快取（如redis等）。

3樓：匿名使用者

1.最簡單的方法：

public static string reverse1(string str)

2.最常用的方法：

public static string reverse3(string s)

3.常用方法的變形：