從MySQL導入海量數據到Elasticsearch

Question

我正在嘗試使用Logstash從MySQL導入32m行到Elasticsearch，它工作正常，但在達到3,5m時會中斷。 檢查過MySQL，Logstash工作正常，Elasticsearch中的問題請查看日志：

[2018-08-14T23:06:44,299][WARN ][o.e.x.s.a.s.m.NativeRoleMappingStore] [4OtmyM2] Failed to clear cache for realms [[]]
[2018-08-14T23:06:44,345][INFO ][o.e.l.LicenseService     ] [4OtmyM2] license [23fbbbff-0ba9-44f5-be52-7f5a6498dbd1] mode [basic] - valid
[2018-08-14T23:06:44,368][INFO ][o.e.g.GatewayService     ] [4OtmyM2] recovered [1] indices into cluster_state
[2018-08-14T23:06:46,120][INFO ][o.e.c.r.a.AllocationService] [4OtmyM2] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[clustername][2]] ...]).
[2018-08-14T23:55:55,780][INFO ][o.e.m.j.JvmGcMonitorService] [4OtmyM2] [gc][2953] overhead, spent [378ms] collecting in the last [1s]

我已將堆大小增加到2GB，但仍然無法處理。 用於遷移的配置文件如下：

input {
    jdbc {
        jdbc_connection_string => "jdbc:mysql://localhost:3306/clustername?useCursorFetch=true"
        jdbc_user => "USER"
        jdbc_password => "PSWD"
        jdbc_validate_connection => true
        jdbc_driver_library => "/usr/share/java/mysql-connector-java-5.1.42.jar"
        jdbc_driver_class => "com.mysql.jdbc.Driver"
        jdbc_paging_enabled => "true"
        #jdbc_fetch_size => "50000"
        jdbc_page_size => 100000
        statement => "SELECT * FROM `video` ORDER by `id` ASC LIMIT 100000 OFFSET 3552984"
    }
}

感謝您的任何建議。

Answer 1

您沒有提供足夠的數據來幫助診斷問題。 要正確索引大量數據，您必須真正了解數據是什么，將要占用多少存儲空間以及將要使用多少內存。

Elasticsearch不是魔術。 如果您要超越簡單的概念證明，就必須了解一些事情。 當看到諸如gc開銷之類的事情花費大量時間時，您必須假設您沒有正確調整Elasticsearch集群的大小。

您需要考慮的事情：

• 我需要多少個碎片？
  • elasticsearch配置文件中的默認＃5可能有效，或者太多或太少。
  • 分片過多會導致Elasticsearch內存不足。 分片太少會導致性能下降。
  • 為了幫助群集恢復，您的碎片不應太大-2 GB至4GB范圍內的某個部分應視為“大”
  • Elasticsearch提供了API以查看您正在使用的分片以及它們的大小

• elasticsearch需要多少內存？

  • 對於數據節點，建議的使用量是系統RAM的50％
  • 建議的50％與允許操作系統將其他50％用於磁盤緩存有關
  • 如果您正在節點上運行其他內容，則可能需要重新架構或調整性能是否允許
  • 如果您的數據是基於時間序列的，則您可能應該使用時間序列命名索引（頻率是每年/每月/每周/每天，具體取決於每天生成的記錄數量）

• 您需要多少個節點

  • 沒有第二個節點，您將沒有副本。
  • 沒有副本，您最終將丟失數據
  • 您需要具有奇數個符合條件的主節點（否則，您將陷入集群已分區的裂腦情況）
  • 越多的節點越好-尤其是在您需要大量分片的情況下
• 您的數據有多大
  • 您可以通過將字段配置為僅關鍵字字段來減小大小（即，如果您不需要搜索某些字段，或者只需要基於_all搜索）
  • 每個記錄使用多少個字段-更多的字段=每行更多的RAM

您還需要考慮很多其他事情，但是作為一般規則，請嘗試找出錯誤的根源所在，即通過生成一些看起來像真實數據的隨機數據來從混合中刪除SQL Server / logstash。您可以收集適當調整群集大小所需的指標。