他言語化対応をする必要がある、検索の場合、構築がかなり楽ちんかと思います。ちなみに、日本語についてもトークナイゼーション辞書を追加して、形態素解析の動作をカスタムできると、書いてありますが、ブログにもあるとおりで、10月半のアップデートで追加された機能になります。こちらは、検証を軽くやってみたので、気になる方は以下のエントリを参照ください。)検索ドメインの作成時に、パーティション数を指定できるようになりました。パーティションを指定することで、ドキュメントの更新パフォーマンスの向上や、1パーティション当たりのドキュメントが減ることによる検索パフォーマンスの向上が期待できます。使用されているとのことですので、シャード数として扱われる形になるかと思われますので、インデックスを分けて持つことでパフォーマンスの向上を実現する、という機能になるかと思います。このため、あまりドキュメント数が多くない状態で、パーティションを分けてもパフォーマンスの向上には、役に立たないどころか、検索時は結果のマージ処理によるオーバーヘッドが発生するので、分けない場合と比較して遅くなる場合もあります。1点、ブログなどには明示されていないのですが、パーティション数を増やした場合の料金への影響です。シャードを切る場合、別々のマシンにシャードを配置します。このため、インデックスの更新処理や検索処理を分散することで、高速化を図るわけです。内部的にインスタンスをパーティション数に合わせて増やす必要があるので、パーティション数を増やすと料金が高くなると思われます。レプリカ数の指定と合わせると、例えばレプリカ2、パーティション2で指定すると4インスタンスが常に起動する構成になるので、注意が必要かと思います。さんに聞いてみたいところです。追記:アマゾンのソリューションアーキテクトの篠原さんにコメント頂きました!まとめるとこんな感じ。インスタンス数は、レプリケーション数☓パーティション数で決まります。負荷に応じて自動的にスケールアウト、スケールインするので固定ではありません。明示的に指定すると、その数を下回ることは無いので、2☓2を指定すると最低でも4インスタンスは常に稼働している計算になります。レプリカ、パーティション共にあとで減らすことが出来ます!なので、想定よりもアクセスやドキュメント数が少なかったら、後で減らして、コストを抑えるなんてことも可能です。一時的に一貫性が失われることがあるそうで、ヒットしないドキュメントが出てきたりするので、タイミングには注意。パーティションは、特にインデックスの更新パフォーマンスに効きます。初回のインデキシング時など大量にインデックス処理が発生するタイミングなどに使うといいんじゃないでしょうか。ブログ執筆ありがとうございます〜!CloudSearchはEC2やRDSと同様に起動しているインスタンスの1時間毎の課金になります〜。パーティションが3でレプリカが2の場合は3x2=6インスタンスという感じです。マルチプロセスでやる場合に有利だったりします、レプリカは予め沢山の検索リクエストを受け付ける事が分かっている場合にやっていただくとよろしい感じです。はい、ご認識の通りです〜。データがガッポリ減ったりすればパーティションの数はそれに合わせて減っていきます。Consistencyなアレで、クエリでデータが取得出来たり出来なかったりするので、その辺は考慮が必要になります〜。サポートこちらも10月のアップデートで追加されていましたね。保存しておくことができます。こちらの機能は、サービスAPIに対する操作のみを記録対象としています。このため、検索クエリのログは取得されませんので、残念ながら検索クエリの分析には使用できません。どちらかというと、監査とか管理とかの目的で使用する形になりそうです。反映されていませんでした。アップデートと日本語ユーザー辞書を試してみる。調べてみたけど、ちょっと違ったという話。こんな投稿をしていたのですが。DDoS攻撃について。有効な対策はなさそう。DDoS攻撃とは、よしだの造語です。!だいぶ間が空きました。はてなブログPro検索プラットフォームの開発・運用をしているプログラマーです。好き勝手なことを綴りますが、どうぞ宜しくお願いします。所属組織とは関係のない個人の見解です。(41)月別アーカイブはてなブログをはじめよう!yoshi0309さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。