注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページのドキュメントでは、Postgres と ElasticSearch で最適なパフォーマンスを得るためのインデックスの調整について説明します。一般的には、オントロジーの機能を基盤として Slate アプリケーションを構築し、オブジェクトセットやアクションなどの機能を使ってデータを読み書きすることを推奨します。
パフォーマンスが高く、保守しやすいアプリケーションには、適切に分割されたデータセットと適切なインデックス化が必要です。
Postgres のスキーマ設計のほとんどの側面は、Slate とはまったく関係ありません。これらの概念については、ほかのドキュメントで詳しく説明されており、データベース設計の一般的なベストプラクティスは、この説明の範囲外です。さまざまなスキーマパターンや、インデックス化する列の選び方にまだ詳しくない場合は、Google で検索すると、すぐに詳しい情報を見つけられます。
このセクションでは、代わりに Slate と Foundry に特に関連するベストプラクティスに焦点を当てます。
アプリケーション開発プロセスのあらゆる段階で、「この処理を行うのに適切な場所はどこか？」と問いかけ、常に処理をできるだけ上流に移すことを優先します。たとえば、データを集計したりメトリクスを抽出したりするために複雑な JavaScript 関数を書いている場合は、「代わりにクエリでこの処理を行えないか？」と考えます。
ページを読み込むたびにクエリで同じ処理を行っている場合、たとえば SUM() で年間合計を算出したり、DISTINCT() でリストを作成したりしている場合は、「派生データセットでこの処理を行えないか？」と考えます。
Foundry では、クエリやユーザーのブラウザーで行う処理と比べて、分散ストレージと分散コンピューティングの「コストが低い」ため、できるだけ多くの処理を事前に実行します。
Postgate は Postgres または RDS をラップし、PostgreSQL クエリを通じて Foundry データセットに簡単に読み取り専用でアクセスできるようにします。アプリケーションのクエリの制限は、一般的なリレーショナルデータベースの特性と、特に Postgres の特性によって決まることに注意してください。プラットフォームのほかの部分で使われている Spark/HDFS の特性によって決まるわけではありません。
データを取得するクエリを開発する際は、EXPLAIN ANALYZE を使ってクエリのパフォーマンスを測定し、ボトルネックを特定します。Postgres がクエリをどのように解釈するか、および EXPLAIN ANALYZE リクエストの結果の読み方については、こちらの Thoughtbot のブログ記事 ↗をご覧ください。また、Slate 向けに Postgres クエリを最適化する方法についての、より詳しい説明もご覧いただけます。
パーシャルを使うと、モジュール化されたクエリを構築し、コードの再利用を防ぎ、共有ロジックをより適切にカプセル化できます。パーシャルと関数を使い、クエリを簡潔に保つことと、読みやすさのために十分な記述量を確保することのバランスを取ることを推奨します。
Phonograph は、クエリと集計に ElasticSearch 形式の構文を使用する読み書き可能なデータストアを提供し、Foundry データセットに対する CRUD 操作も可能にします。Phonograph の活用方法についてさらに詳しくは、Slate から Foundry にデータをライトバックするセクションをご覧ください。