序言
Elasticsearch 是一個實時的分布式搜索分析引擎。Teambition 使用 Elastisearch 作為搜索引擎，為用戶提供搜索服務，當我們決定存儲某種數據時，我們需要使用PUT /teambition創建索引，在創建索引的時候需要將數據結構完整確定下來，于此同時索引的設定和很多固定配置將用不能改變。當需要改變數據結構時，就需要重新建立索引，為此，Elastic團隊提供了很多輔助工具幫助開發人員進行重建索引。
決定是否需要重建？
重建時相當痛苦的，如果沒有很好的基礎，服務可能中斷，當數據量非常大時，重建恢復時間可能很長，甚至在重建過程中出錯等等。所以，沒有萬不得已的情況下還是盡量避免重建索引。Teambition 重建索引的理由略，因為這并不重要。
使用正確的工具
kibana 是 Elasticsearch 的最佳拍檔，從 ES 5.0 開始，Kibana 強大的功能能夠替代幾乎所有舊時代 ES 1.x 和 ES 2.x 的插件。關鍵是人家還是免費的！
先決條件
正在運行的服務必須使用別名(alias)來訪問索引(index)，原因很簡單，搜索服務最終要使用重建的索引，原始的索引將被刪除。如果你的服務正在直接使用索引名，在重建前創建別名，更新服務。
POST /_aliases
{"actions": [{"add": {"index": "teambition", // 原有索引"alias": "teambition_latest" // 服務的別名}}]
}
復制代碼先決條件2
記得查看 Elasticsearch 的 Disk Usage，如果不夠，請先申請好足夠的空間。
創建新索引
和創建普通索引一樣創建新索引。這里值得一提的時，當數據量很大的時候，需要設置刷新時間間隔，在此期間寫入的數據不能搜到，從而提高重建速度：refresh_intervals = -1, number_of_replicas = 0。實踐告訴我，大概會提高100% ~ 400%的提升。
PUT /teambition_20180328
{"settings": {...},"mapping": {...}
}
復制代碼記錄同步數據的偏移值(offset)
Teambition使用Kafka把MongoDB中的數據導入到Elasticsearch中，如果沒有kafka，亦可讀取oplog的數據寫入Elasticsearch。無論使用哪種同步數據的方式，都需要記錄同步數據的offset。重建索引可能非常耗時，在這段時間內，同步進程仍然在向舊索引更新數據，此時重建索引是無法更新這些新數據的。這里記錄的方法就不多說了，Teambition 使用 kafka-admin 的API記錄 offset。
開始重建索引
使用 Elasticsearch 團隊提供的 reindex api 就可以將數據 copy 到新索引中。這里幾條路可以選：
- 當只是改變 mapping 數據結構時，可以僅僅使用 reindex api 即可。例如：刪除字段，更新字段分詞方式等。
- 當需要寫入新的字段，新的字段是由老的字段計算得到時，可以使用
script參數。例如，計算某條數據某字段的總和。script 有很多坑，當 script 出錯時，reindex 跑了很久之后失敗，即使將數據恢復，也需要重新跑 reindex。 - 當含有很復雜的邏輯時，額，還是自己寫程序吧。
調用 reindex 接口，接口將會在 reindex 結束后返回，而接口返回超時只有30秒，如果 reindex 時間過長，建議加上wait_for_completion=false的參數條件，這樣 reindex 將直接返回taskId
POST _reindex?wait_for_completion=false
{"source": {"index": "teambition"},"dest": {"index": "teambition_20180328"},"script": {...}
}
復制代碼重建索引中
重建索引非常耗時，喝杯咖啡歇一會兒吧（順便去打個球，睡個覺，旅個游）。
在沒有設置 refresh_intervals 和 number_of_replicas 時，reindex 的速度在 500~1000 doc/sec, 如果包含 script 時可能會更低。設置之后，可以到 4000~8000 doc/sec。 Teambition 70M Documents 大概耗時4小時。
可以使用GET _tasks/{taskID}可以看到重建進程，其中包含耗時，剩余doc數量等信息。
如果發現錯誤，可以使用PUT _tasks/{taskID}/cancel接口放棄任務，從頭再來。
恢復同步數據
重建索引結束后，別忘了在setting中的將number_of_replicas和refresh_intervals設為原有值. 啟動新的同步索引的進程（從記錄 offset 開始同步）
建立新的alias
需要在同時綁定建立的新索引以及解綁舊索引，語句如下：
POST _aliases
{"actions": [{"add": {"index": "teambition_20180328","alias": "teambition_latest"}}, {"remove": {"index": "teambition","alias": "teambition_latest"}}]
}
復制代碼刪掉index
刪除舊的 index，釋放磁盤空間；停止原有同步進程。
DELETE teambition
復制代碼總結
修改索引真的是一件費時費力的工作，特別是如果發生了錯誤，整個人都不好了。所以還是在創建索引的時候盡量想好能否滿足需求，當然大家都知道這幾乎是不可能的，因為存在著萬惡的產品經理。
這里還有一個很重要的內容沒有詳細介紹就是同步進程，前面提到同步進程是將 MongoDB 的數據同步到 ES 中去的程序，這個程序同時還需要有能力暫停同步，重復同步的等能力。
