ownCloud 10のデータベースインデックスを安全に最適化する方法

ownCloudのフォルダ一覧表示が遅い、同期が遅れる、またはcronジョブの実行時間が長い場合は、データベースのボトルネックが考えられますが、インデックスを無計画に追加すると、サーバーの信頼性が低下する可能性があります。ownCloud Server 10では、まず正確なバージョンとデータベースを確認し、インスタンスをバックアップしてから、そのownCloudリリース向けにドキュメント化されたスキーマ変更のみを使用するのが安全な出発点です。インデックスは選択的な検索や結合に役立ちますが、ストレージを消費し、挿入や更新の処理負荷も増加させます。

重要なバージョン上の違いがあります。現在の公式ownCloud Server 10.16コマンドリファレンスには、データベース変換などのデータベース操作に関するドキュメントはありますが、一般的なdb:add-missing-indices修復コマンドに関するドキュメントはありません。そのコマンドは、別の製品であるNextcloudのガイダンスに記載されています。他のプロジェクトからコピーしたコマンドを実行する前に、ご自身のサーバーでコマンドを確認してください。

データベースインデックスで解決できることと解決できないこと

データベースインデックスは、データベースがテーブル全体をスキャンすることなく、一致する行を見つけるのに役立つ補助的な構造です。クエリとデータの分布状況によっては、インデックス付き列でフィルタリング、結合、またはソートを行うクエリの効率を向上させることができます。インデックスは一般的な速度スイッチではありません。データベースオプティマイザは、小さなテーブルや、行の大部分を返すクエリに対して、適切なテーブルスキャン方法を選択できます。

インデックスにもコストがかかります。ディスク容量を消費し、行が変更されるたびにメンテナンスが必要となり、書き込み負荷の高い処理を遅くする可能性があります。ownCloudのコアテーブルにインデックスを追加すると、スキーマの移行やアプリケーションの要件と競合する可能性があります。列名が重要そうに見えるからといってインデックスを追加しないでください。まず、処理が遅いリクエストを特定し、実際のクエリプランが非効率であることを確認してください。

1. ownCloudのビルドとデータベースを確認する

ownCloudのインストールディレクトリから、Webサーバーアカウントとしてコマンドを実行します。一般的なDebianまたはUbuntuのインストールでは、そのアカウントは次のとおりですwww-data。

cd /var/www/owncloud
sudo -u www-data php occ status
sudo -u www-data php occ list

ホストに設定されているパスとサービスアカウントを使用してください。Docker では、コンテナのドキュメントに記載されているコマンド形式を使用してください。たとえば、ownCloud のマニュアルでは を使用していますdocker compose exec owncloud occ …。ステータス出力には、ownCloud のバージョンとデータベースの種類が表示されます。コマンド一覧には、このインストールで実際にサポートされている機能が表示されます。データベース修復コマンドが一覧にない場合は、Nextcloud の手順が適用されるとは限りません。

ownCloudの管理者概要で設定に関する警告を確認し、インデックスが見つからないという報告があった場合は、正確なテーブル名とインデックス名をメモしておきましょう。また、どの処理が遅いのか（特定のファイル検索、共有ページ、バックグラウンドジョブ、同期操作など）も記録してください。「ownCloudの動作が遅い」といった漠然とした苦情では、スキーマ変更の正当な理由にはなりません。

2. データベース構造を変更する前にバックアップを取る

インデックスの作成、データベースの移行、または修復を行う前に、データベースとownCloud構成の整合性のあるバックアップを取得し、復元方法を把握しておいてください。ownCloudのバックアップガイドでは、データベースのバックアップを取得する前にメンテナンスモードを有効にすることを推奨しています。正確なデータベースダンプコマンドは、サーバーがMySQL、MariaDB、PostgreSQL、またはSQLiteのいずれを使用しているかによって異なります。対応するデータベースベンダーのツールを使用し、認証情報とバックアップファイルを保護してください。

sudo -u www-data php occ maintenance:mode --on
# Back up the database and ownCloud configuration with your vendor's procedure
# Confirm that the backup can be restored before proceeding

メンテナンスモードでは、メンテナンス中は通常の使用ができなくなります。本番環境のサービスウィンドウを計画してください。稼働中のデータベースファイルを、データベース対応のバックアップの代わりとしてコピーしないでください。作業と基本チェックが完了したら、インスタンスを通常モードに戻してください。

sudo -u www-data php occ maintenance:mode --off

3. ownCloudスキーマの変更には、ownCloudが管理する移行機能を使用する

まず、公式のアップグレード手順とリリースノートに従って、ownCloudとその互換アプリをサポートされているリリースにアップグレードしてください。ownCloudのアップグレードでは、コアとアプリに必要な変更を含むスキーマを進化させるデータベース移行が実行されます。公式ガイダンスでは、occWebリクエストがタイムアウトする可能性がある大規模システムでは、データベースアップグレードの手順を最後まで実行することを推奨しています。

管理者概要でインデックスが見つからないと報告される場合は、sudo -u www-data php occ listownCloud の正確なビルドに関する公式ドキュメントを確認してください。一部のサードパーティ ガイドでは が示されていますdb:add-missing-indicesが、このコマンドは、この記事で確認した ownCloud 10.16 データベース コマンド セクションには記載されていません。ビルドにこのコマンドが記載されている場合は、ローカル ヘルプを読み、実行する前にそのビルドのドキュメントまたはアプリ ベンダーに手順を確認してください。このコマンドがない場合は、Nextcloud コマンドをインストールしたり、ownCloud のコア テーブルを手動で編集したり、別のバージョンから SQL をコピーしたりしないでください。警告、ownCloud のバージョン、データベースの種類、および関連するログを ownCloud またはアプリ メンテナーと共有してください。

ownCloud マニュアルに記載されているデータベースコマンド（例:db:convert-typeや などdb:convert-mysql-charset）は、特定の変換タスクを実行するためのものであり、汎用的なインデックスチューニングコマンドではありません。クエリ速度の向上を目的として変換コマンドを使用しないでください。

4. データベースネイティブツールを使用して、遅いクエリを調査する

遅いSQLクエリを特定できたら、データベースに付属の分析ツールを使用してください。MySQLとMariaDBには分析ツールが用意されており、EXPLAINPostgreSQLにもEXPLAIN独自の出力とオプションを備えた分析ツールが用意されています。まずは、クエリを実行せずにその内容を説明するプランから始めましょう。分析オプションの使用には注意が必要です。データベースによってはステートメントを実行するものがあり、書き込み時には安全でなかったり、負荷の高い本番データベースではコストが高くなったりする可能性があります。

EXPLAIN SELECT ... FROM oc_filecache WHERE ...;

プランがクエリの戻り値よりもはるかに多くの行を読み込んでいるか、想定されるインデックスが考慮されているか、ソートや結合が処理の大部分を占めているかを確認してください。オプティマイザによって選択されなかったインデックスが必ずしも欠落しているわけではありません。クエリが多数の行を返す場合、スキャンの方がコスト効率が良い場合があります。データベース固有の変更を行う前に、代表的なステージングコピーで同じワークロードを比較してください。OwnCloud のコア SQL とテーブルレイアウトはリリースごとに変更される可能性があるため、現在有用と思われるインデックスが、アップグレード後に冗長になったり、安全でなくなったりする可能性があります。

5. 元の症状を再確認する

サポートされている移行または承認済みのインデックス修復が完了したら、ownCloud 管理者概要を再度確認し、サーバーおよびデータベースのログにエラーがないか確認してください。処理が遅かったユーザー操作またはバックグラウンド ジョブを、同様のデータ量と条件で再度実行してください。データベースでこれらの測定値が公開されている場合は、応答時間、データベースの CPU または I/O、および検査対象の行数を比較してください。単一の小規模なテストや無関係なページ読み込みによるパフォーマンス向上を報告しないでください。

警告が消えたにもかかわらず、同じ処理が依然として遅い場合は、ボトルネックは別の場所にある可能性があります。例えば、ストレージの遅延、PHPワーカー、ネットワークの往復、cronのバックログ、ファイルロック、メモリキャッシュなどが考えられます。ownCloudでは、データベースの負荷を軽減するために、メモリキャッシュと外部トランザクションファイルロックの使用を推奨しています。これらの設定はデータベースインデックスとは異なる処理を対象としているため、公式マニュアルとデプロイメント構成に従って設定してください。

クイックチェックリスト

• ownCloudのバージョン、データベースの種類、影響を受けた操作、および正確なセットアップ警告を記録してください。
• インストールされているoccコマンド一覧を確認し、ownCloudのコマンドとNextcloudのコマンドを区別してください。
• スキーマ作業を行う前に、データベースと構成の整合性のあるバックアップを取得し、検証してください。
• サポートされているownCloudのアップグレードおよびアプリ移行の手順に従ってください。リリース固有の手順がない限り、コアテーブルを手動で変更しないでください。
• 実際に処理速度の遅いクエリに対して、データベースベンダーのクエリプラン作成ツールを使用し、その後同じワークロードを繰り返して結果を確認してください。

ownCloud 10 のインストールを全て高速化できるような万能なインデックスセットは存在しません。持続可能なアプローチとしては、サポートされているスキーマを最新の状態に保ち、実際のクエリを診断し、関連するベンダーまたはメンテナーが文書化している内容のみを変更し、その後同じワークロードで検証することです。

公式資料

• ownCloud Server 10.16 occコマンドリファレンス
• ownCloud Server 10.16 データベース構成
• ownCloud Server 10.16 バックアップガイド
• ownCloud Classic アップグレードガイド
• ownCloudのメモリキャッシュに関するドキュメント
• MySQL 8.4 EXPLAIN ドキュメント
• PostgreSQL EXPLAIN ドキュメント