各アカウント (ユーザー?) をそれぞれ独自のインデックスで物理的に分離することについて言及していますか? これは一般に「マルチテナント」と呼ばれますhttp://en.wikipedia.org/wiki/Multitenancy
これが実際にあなたがやろうとしていることだと仮定します:
パーティショニングの「必要性」については過去に多くのことが言われてきました (セキュリティ上の理由からこれが必要だと思います。私はマルチテナンシー アプリの専門家ではありませんが、これが必要な他の理由についてはよくわかりません)。アカウント/ユーザーごとのデータ。たとえば、フィールドを持っているだけでなく、accountid
すべてContact
のクエリが少なくともaccountid
. 多くの場合、システムで使用されるすべてのクエリが設定が必要な「スーパークエリ」から継承される、慎重に設計されたクエリコンポーネントであるIMOでaccountid
十分です。
将来どのアプリがこれらのインデックスにクエリを実行する必要があるかを事前に把握していなくても、たとえば ES の周りに薄い REST サービスを用意し、すべてのプログラムがこのサービスを介して ES と対話するように要求することで、上記を強制することができます。次に、このタイプのセキュリティを強制するか、現在ログインしているユーザーがリクエストを行っているとaccountid
推測することで、このタイプのセキュリティを処理することができます。accountid
それでもマルチテナンシーを追求したい場合は、http: //elasticsearch-users.115913.n3.nabble.com/Multi-tenacy-td471400.htmlをご覧ください(すぐにこれを検索しました。おそらくもっと良いものがあります) 'Kimchy ' (ES の作成者) もそのスレッドにコメントしています。
いずれにせよ、ES でマルチテナンシーを実現する最善の方法は、おそらく account/user ごとに 1 つの index を持つことです。その中には、複数の「タイプ」(ES コンストラクト) を含めることがContact
できます。
http://www.elasticsearch.org/guide/reference/mapping/
http://www.elasticsearch.org/guide/reference/api/search/indices-types.html
あなたが示唆しているように、モデルでこれを強制することは、おそらく正しい方法ではありません。一般に、ストレージ バックエンド (データが格納されているインデックスを含む) に関する知識からドメイン モデルをクリーンに保つ必要があります。
私にとってより良い解決策は、以前に提案したように、アカウント/ユーザーに基づいて正しいインデックスを選択するロジックが含まれるクエリ コンポーネントを持つことです。上記のrest-serviceアプローチを使用すると、動的インデックス名は、提案したように、リクエストを実行しているログインユーザーから派生できます。
これはおそらくあなたの質問に対する直接的な答えではなかったと思いますが、それでもなお役に立てば幸いです.