注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページのドキュメンテーションは、PostgresとElasticSearchでの最適なパフォーマンスを目指してインデックスをチューニングすることに焦点を当てています。一般的には、Slateアプリケーションをオントロジーの機能を基に構築し、Object SetsやActionsのような機能を使ってデータの読み書きを行うことを推奨しています。
パフォーマンスと保守性の高いアプリケーションは、適切にファクタリングされたデータセットと適切なインデックス設計に依存しています。
Postgresのスキーマ設計の大部分はSlateに対して完全に中立です。これらの概念は他の場所で十分に文書化されており、データベース設計の一般的なベストプラクティスはこの議論の範囲外です。異なるスキーマパターンや、どの行をインデックスに選ぶべきかについてのガイダンスにまだ馴染みがない場合、Googleはあなたをすぐにその奥深い世界に導くでしょう。
代わりに、私たちはSlateとFoundryにより具体的に関連するいくつかのベストプラクティスに焦点を当てます。
アプリケーション開発プロセスの各段階で、次の質問をします："この作業を行うのに適切な場所はどこか？"そして、常に作業をできるだけ上流に移すことを優先します。例えば、複雑なJavaScript関数を書いてデータを集計したりメトリクスを抽出したりすることになった場合、"これをクエリ内で行うことはできるか？"と自問します。
もし毎回のページロードで同じ作業をクエリで行っている場合、例えばSUM()で年間合計を導出したり、DISTINCT()でリストを作成したりする場合、"これを派生データセットで行うことはできるか？"と自問します。
Foundryでは、分散ストレージと計算はクエリやユーザーのブラウザで行われる作業に比べて"安価"なので、可能な限り事前に計算します。
Postgateは、PostgresまたはRDSをラップして、PostgreSQLのクエリを通じてFoundryのデータセットへの直接的な読み取り専用アクセスを提供します。アプリケーションのクエリの制約は、一般的にリレーショナルデータベースの特性（プラットフォームの残りの部分ではSpark/HDFSではなく）と、特にPostgresの特性によって決定されることを覚えておいてください。
データを取得するためのクエリを開発する際には、EXPLAIN ANALYZEを使用してクエリをプロファイリングし、ボトルネックを見つけます。Postgresがあなたのクエリをどのように解釈し、EXPLAIN ANALYZEのリクエスト結果をどのように解釈するかについての詳細は、このThoughtbot blog post (external link)を参照してください。また、Slate向けのPostgresクエリの最適化について詳しく説明しています。
Partialsを使用してモジュラーなクエリを構築することで、コードの再利用を防ぎ、共有ロジックをより適切にカプセル化できます。私たちは、クエリをシンプルに保ちつつ、十分に詳細にすることで読みやすくするためのバランスをとるために、部分と関数の使用を推奨します。
Phonographは、クエリと集計のためのElasticSearch風の構文を使用し、Foundryのデータセット上でのCRUD操作も許可する読み書きデータストアを提供します。Phonographの実践については、SlateからFoundryへのデータの書き戻しのセクションを参照してください。