注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページのドキュメントでは、PostgresとElasticSearchでの最適なパフォーマンスを実現するためのインデックスのチューニングに焦点を当てています。一般的には、Slateアプリケーションをオントロジー機能の上に構築し、Object SetsやActionsを使ってデータの読み書きを行うことをお勧めします。
パフォーマンスとメンテナンス性の高いアプリケーションは、よく整理されたデータセットと適切なインデックスに依存しています。
Postgresのスキーマ設計のほとんどの側面は、Slateとは完全に無関係です。これらの概念は他の場所で十分に文書化されており、データベース設計の一般的なベストプラクティスは、この議論の範囲外です。異なるスキーマパターンや、どの列をインデックスにするかを選択するためのガイダンスに慣れていない場合は、Googleで素早くその情報を得ることができます。
代わりに、SlateおよびFoundryにより具体的に関連するいくつかのベストプラクティスに焦点を当てます。
アプリケーション開発プロセスの各段階で、「この作業を行う適切な場所はどこか？」という質問をし、できるだけ上流で作業を行うことを優先してください。例えば、データを集計したり指標を抽出する複雑なJavaScript関数を書いている場合、「この作業はクエリで代わりに行えますか？」と尋ねてみましょう。
例えば、ページの読み込みごとにクエリで同じ作業を行っている場合、SUM()で年間合計を算出したり、DISTINCT()でリストを作成したりしている場合、「これを派生したデータセットで行うことができますか？」と自問してください。
Foundryでは、分散ストレージとコンピュートはクエリやユーザーのブラウザで行われる作業と比較して「安価」なので、できるだけ事前に計算しておきましょう。
Postgateは、PostgreSQLクエリを通じてFoundryデータセットへの読み取り専用アクセスを簡単に実現するために、PostgresまたはRDSをラップしています。アプリケーションクエリの制約は、関係データベース（プラットフォーム内のSpark/HDFSではなく）およびPostgresの特性によって決まることに注意してください。
データを取得するためのクエリを開発する際には、EXPLAIN ANALYZEを使ってクエリをプロファイリングし、ボトルネックを見つけましょう。Postgresがクエリをどのように解釈し、EXPLAIN ANALYZEの結果をどのように解釈するかについては、Thoughtbotブログ記事 ↗で詳しく説明しています。また、Slate用のPostgresクエリの最適化に関する詳細な説明も読むことができます。
Partialsを使って、コードの再利用を防ぎ、共有ロジックをより適切にカプセル化するためにモジュール化されたクエリを構築することができます。クエリをシンプルに保ちながら、十分に読みやすくするために、パーシャルと関数を使ってトレードオフを図ることをお勧めします。
Phonographは、ElasticSearchスタイルの構文を用いたクエリと集計を行い、Foundryデータセットの上にCRUD操作を可能にするデータストアを提供します。Phonographの実践に関する詳細は、SlateからFoundryへのデータの書き戻しセクションを参照してください。