ownCloud 10のクエリを安全にインデックス管理することで高速化

ownCloud 10 の場合、まずインストール済みのコアとアプリによって提供されるスキーマ変更を適用し、次に実際にどのデータベースクエリが遅いかを確認してください。インデックスを無闇に追加したり、Nextcloud コマンドがdb:add-missing-indicesownCloud 10 でサポートされている修復コマンドであると想定したりしないでください。現在の ownCloud Server 10.15 OCC リファレンスには、Nextcloud コマンドに関するドキュメントがありません。インデックスを使用すると、一致する読み取りが高速化されますが、インデックスを追加するたびにストレージが消費され、挿入、更新、削除の処理が増加します。

この方法は、ownCloudのページ、ファイル一覧、またはアプリの動作が遅い場合で、サーバーとデータベースにアクセスできる管理者に適しています。インスタンス全体が遅い場合、または複数のアクティブユーザーがいるSQLite上で動作している場合は、インデックスが原因と判断する前に、データベースとデプロイメントの設定全体を確認してください。

証拠に合致する変更を選択してください。

データベースインデックスは、データベースがテーブル全体をスキャンすることなく行を特定するのに役立つ補助的な構造です。ownCloudとそのアプリは、スキーマの一部としてテーブル、列、インデックスを定義します。コアおよびアプリのアップデートには、これらのインデックスを作成または調整するスキーマ移行が含まれる場合があります。したがって、アプリケーションのスキーマを最新の状態に保つことが、最も安全な最初のステップです。

変更を加える前に、以下の点に注意してください。

• 管理者警告または既知のアップグレードの問題：通常のownCloudアップグレード手順を実行し、その出力を確認してください。アップグレード移行は、ownCloudまたはアプリによって提供されるスキーマ変更をサポートする方法です。
• 実行プランが非効率的な、実行速度の遅いクエリの例としては、データベース管理者にクエリと実行プランを検査してもらうことが挙げられます。ターゲットインデックスが有効な場合もありますが、提案する列と順序はクエリとテーブル定義に一致している必要があります。
• アップロード速度の低下、ロック、または広範囲にわたる競合が発生した場合は、トランザクション、ストレージの遅延、データベースの容量、およびファイルロックについて調査してください。これらの症状だけでは、インデックスの欠落を証明するものではありません。
• 小規模なSQLite環境をマルチユーザー環境にする場合： MySQL/MariaDBまたはPostgreSQLへの移行を検討してください。ownCloudは、SQLiteはテストや小規模なシングルユーザーワークロードに適していると説明していますが、本番環境のマルチユーザー環境では、サポートされているサーバーデータベースを使用する必要があります。

インデックスは万能の速度向上スイッチではありません。インデックスを増やすことで、特定の検索処理は改善される可能性がありますが、データベースのサイズと書き込みレイテンシが増加する場合があります。結果は、クエリ構造、テーブルサイズ、データ分布、データベースエンジン、キャッシュの状態によって異なります。

安全なメンテナンス期間を準備する

1. 正確なバージョンとデータベースを記録します。ownCloudのインストールディレクトリから、を実行しますsudo -u www-data ./occ status。から、ownCloud のバージョン、インストールされているアプリのバージョン、データベースの種類、およびテーブルプレフィックスをメモしconfig/config.phpます。を、www-dataディストリビューションの Web サーバーアカウントに置き換えます。
2. 動作が遅くなった箇所を記録してください。影響を受けた画面またはアプリ、おおよその時間、および遅延が繰り返されるかどうかをメモしてください。ownCloudのログとデータベースの低速クエリ診断を確認してください。ログには機密性の高いSQL値が含まれる可能性があり、またログサイズが急速に大きくなる可能性があるため、データベースベンダーの指示に従ってのみクエリログを有効にしてください。
3. データベースと設定をバックアップしてください。データベース整合性のあるバックアップ方法を使用し、バックアップが読み取り可能であることを確認してください。ownCloudのバックアップに関するドキュメントではmysqldump --single-transaction、MySQL互換データベースの例としてを使用しています。ホスト、ユーザー、データベースの値は、ご自身の設定に合わせて変更してください。データベースのパスワードをシェル履歴やプロセス一覧に直接入力しないでください。
4. スケジュール変更は責任を持って行ってください。スキーマのアップグレードやインデックスの構築では、ディスクI/O、CPU、およびロックが使用される場合があります。負荷の高い環境や大規模なインストール環境では、ユーザーに変更期間を通知し、データベースの負荷を監視してください。ownCloudのメンテナンスモードは、該当するアップグレードまたはメンテナンス手順で要求された場合にのみ使用し、バックアップの代わりとして有効にしないでください。

ownCloudが管理するスキーマの更新を最初に適用してください。

ownCloudのコアまたはアプリのアップデートが保留中の場合は、インストール方法に応じたドキュメントに記載されているアップグレード手順を使用してください。通常のLinuxインストールでは、OCCコマンドはownCloudのルートディレクトリからHTTPユーザーとして実行されます。手動アップグレード手順に従う場合、コマンドは次のとおりです。

sudo -u www-data ./occ upgrade

ファイルが部分的にしか更新されていないインストール環境に対しては実行しないでください。まず、対応するリリースファイルを準備し、そのリリースの公式アップグレード手順に従ってください。Docker デプロイメントの場合は、別の PHP 環境を指すホスト パスではなく、コンテナのドキュメントに記載されている OCC 呼び出しを使用してください。

コマンドの出力とログをすべて確認してください。コマンドが正常に完了すれば、移行失敗の報告はありません。ただし、すべての低速クエリが修正されるとは限りません。更新中に移行エラーが報告された場合は、コマンドを繰り返し実行したり、スキーマテーブルを手動で編集したりするのではなく、処理を停止してエラーを調査してください。アプリの移行が関係する場合は、バージョン固有のownCloudアップグレードドキュメントとアプリメンテナーを参照してください。

ownCloud 10.15 OCC リファレンスにはdb:convert-type、、、などのデータベースコマンドが記載されていますdb:convert-mysql-charsetがdb:restore-default-row-format、は記載されていません。コマンドの利用可否はリリースやインストールされているコードによって異なる場合があるため、またはをdb:add-missing-indices使用してインスタンスを検査できます。後者が不明なコマンドを報告する場合は、Nextcloud チュートリアルのコマンドを ownCloud にコピーしないでください。正確な ownCloud リリースのドキュメントを確認し、サポートされているアップグレードまたはアプリ移行パスを使用してください。sudo -u www-data ./occ list dbsudo -u www-data ./occ help db:add-missing-indices

手動索引はどのような場合に適切か？

手動 SQL は、検証済みのクエリの問題に対するデータベース管理者のオプションであり、ownCloud のルーチン最適化ではありません。まず、正確な遅いクエリをキャプチャし、EXPLAINMySQL/MariaDB や PostgreSQL などのエンジンのプラン検査ツールを実行します。プランが不必要に多くの行をスキャンしていないか、既存のインデックスが無視されていないかを確認します。ownCloud のテーブルプレフィックスは設定可能なので、テーブル名が で始まると想定しないでくださいoc_。

インデックスを作成する前に、提案された列をクエリのフィルタ、結合、およびソート順と比較してください。複合インデックスの列の順序は重要です。既存のインデックスを複製すると、プランが改善されないままコストが増加する可能性があります。データベース管理者に、データベースのバージョン動作、オンラインまたは同時インデックス構築のサポート、ディスク容量、ロックの影響、およびロールバック手順について検討してもらうようにしてください。これらの詳細はエンジンとバージョンに固有のものであるため、すべてのownCloud 10インストールに対して安全な単一のSQLステートメントは存在しません。

名前が重複しているように見えるという理由だけで、ownCloud テーブルを変更したり、インデックスを削除したりしないでください。このような変更は、後続のコアまたはアプリの移行と競合する可能性があり、検査したクエリとは異なるクエリを使用する機能を壊してしまう可能性があります。手動でスキーマを変更した場合は、必ず記録を残し、復元または移行後に再現できることを確認してください。インデックスの欠落が製品スキーマの欠陥である場合は、サポートされているownCloud パッチまたはアプリのリリースを優先してください。

データベースレベルの代替案を比較する

プランが既に適切なインデックスを使用している場合、別のインデックスを追加しても、他の場所で発生した遅延が解消される可能性は低い。以下のオプションを、観測されたボトルネックと比較してください。

• MySQLまたはMariaDB：管理者が既にこれらのデータベースエンジンを運用している環境において、よく選ばれる選択肢です。サーバー設定を変更する前に、バッファプールメモリ、ディスクレイテンシ、接続数、および低速クエリプランを確認してください。
• PostgreSQL： PHPデータベースコネクタとデプロイメントが正しく構成されている場合、ownCloud 10でサポートされている代替手段です。クエリプランとインデックスメンテナンスツールはMySQLとは異なるため、PostgreSQL固有のアドバイスに従ってください。
• SQLite：テストや小規模なシングルユーザー利用には操作が簡単ですが、同時実行されるマルチユーザーの運用ワークロードにはデフォルトの選択肢ではありません。インデックスのチューニングによって、デプロイメントの同時実行制限を解消することはできません。

データベースエンジンの変更は、簡単なインデックス調整ではなく、移行プロジェクトです。ownCloudはocc db:convert-typeサポートされている変換機能を提供していますが、前提条件を確認し、事前にバックアップを取り、変換後のインスタンスをテストしてからユーザーに提供してください。

結果を確認し、証拠と矛盾する場合は中止する。

同様の条件下で同じユーザー操作を繰り返し、クエリの実行時間、実行プラン、検査対象行数、データベースI/O、サーバー負荷を比較してください。関連するownCloudページまたはアプリが正常に完了し、ログにデータベースエラーや移行エラーが記録されていないことを確認してください。1つのリクエストで結果が速くなったからといって、全体的な改善が証明されるわけではありません。複数の代表的なリクエストを比較し、ウォームキャッシュの影響を考慮してください。

適切なインデックスを使用しているにもかかわらず、同じクエリの実行速度が遅い場合は、ロック、ストレージ、ネットワーク遅延、PHPワーカー、およびデータベースのリソース制限を調査してください。クエリプランまたはテーブル構造が不明瞭な場合は、手動でDDLを発行する前に作業を中止し、DBAまたはownCloudサポート担当者に確認を依頼してください。確実な結果は、インストールされているownCloudのバージョンと測定されたクエリに整合したスキーマであり、追跡されていないインデックスの変更がない状態です。

公式資料

• ownCloud Server 10.15 OCC コマンドリファレンス
• ownCloud Server 10.15 手動アップグレード手順
• ownCloud Server 10.15 データベース変換ガイド
• ownCloud Server 10.15 バックアップに関するドキュメント
• ownCloud Server 10.15 管理ドキュメント