はじめに
ZOZOTOWNでは検索エンジンとしてElasticsearchを使用しています。
ElasticsearchではMappingとSettingを行いインデックスの構成を決定します。
Mappingはインデックス内のドキュメントのフィールドとそのデータ型を定義するもので、Settingはシャード数やレプリカ数、使用するアナライザーなどインデックス全体に関する設定を管理するものです。
私のチームではコスト削減とレイテンシの改善を目的としMappingとSettingを見直すことにしました。
見直し案
チームで見直し案に上がったのはmulti fieldにおいてkeyword型とtext型の両方を定義されているがどちらか一方しか検索に利用していないフィールドをkeyword型またはtext型のどちらかにするというものです。
これは検索に用いていない型の定義を削除することでディスクサイズが削減され、コスト削減につながるのではないかと考えたためです。
結論
結論としてこの見直し案ではコスト削減は見込めませんでした。
基本的にElasticsearchの各インデックスはシャードに分割され、各シャードは複数のコピーを持ちます（レプリケーション）。このコピーはドキュメントの追加や削除があった場合に同期を保つ必要があります。
ディスクサイズの削減は、このコピーが同期を保つために行うクラスタ内のデータ転送への影響がありそうでした。
しかし、Elasticsearchはドキュメント（リクエスト）レプリケーションをしているため、multi fieldの展開はデータノード内部での処理になり、データ転送量に違いは出ず、コスト削減は見込めませんでした。
ただ、ディスクストレージやI/O負荷が軽減される可能性はあると分かりました。
まとめ
multi fieldはデータノード内の展開になるため、クラスタ内のデータ転送に現れず、コスト削減が見込めないと分かりました。
コスト削減が見込めないため私のチームでは修正を見送りましたが、検索に使用していない型を整理することで開発者にとって仕様を理解しやすくなったり、ディスクストレージやI/O負荷が軽減出来るというメリットはあるのでチームの状況に応じて検討いただけたらと思います。
最後になりますが、間違った記述をしている場合はお気軽にご指摘ください。
本記事が誰かの参考になれば幸いです。