ownCloud 10 데이터베이스 인덱스를 안전하게 최적화하는 방법

ownCloud 폴더 목록 표시 속도 저하, 동기화 지연 또는 장시간 실행되는 cron 작업은 데이터베이스 병목 현상을 나타낼 수 있지만, 인덱스를 무턱대고 추가하면 서버의 안정성이 떨어질 수 있습니다. ownCloud Server 10에서는 정확한 버전과 데이터베이스를 확인하고 인스턴스를 백업한 다음 해당 ownCloud 릴리스에 대해 문서화된 스키마 변경 사항만 사용하는 것이 안전한 시작점입니다. 인덱스는 선택적 검색 및 조인을 지원하지만 저장 공간을 사용하고 삽입 및 업데이트 작업에 추가적인 부담을 줍니다.

중요한 버전 차이가 있습니다. 현재 공식 ownCloud Server 10.16 명령어 참조 문서에는 데이터베이스 변환과 같은 데이터베이스 작업에 대한 내용은 있지만, 일반적인 db:add-missing-indices복구 명령어는 포함되어 있지 않습니다. 해당 명령어는 별도의 제품인 Nextcloud 안내 문서에 있습니다. 다른 프로젝트에서 복사한 명령어를 실행하기 전에 자신의 서버에서 해당 명령어를 확인하십시오.

데이터베이스 인덱스가 해결할 수 있는 문제와 해결할 수 없는 문제

데이터베이스 인덱스는 전체 테이블을 스캔하지 않고도 일치하는 행을 찾을 수 있도록 도와주는 보조 구조입니다. 쿼리와 데이터 분포에 따라 인덱스가 유용할 경우, 인덱스가 적용된 열을 기준으로 필터링, 조인 또는 정렬하는 쿼리의 성능을 향상시킬 수 있습니다. 하지만 인덱스 사용이 모든 쿼리의 속도를 자동으로 조절하는 것은 아닙니다. 데이터베이스 최적화 프로그램은 작은 테이블이나 대부분의 행을 반환하는 쿼리의 경우, 테이블 스캔을 사용하는 것이 더 효율적일 수 있습니다.

인덱스에도 비용이 발생합니다. 디스크 공간을 차지하고, 행이 변경될 때마다 유지 관리해야 하며, 쓰기 작업이 많은 경우 속도를 저하시킬 수 있습니다. ownCloud 코어 테이블에 추가 인덱스를 생성하면 스키마 마이그레이션이나 애플리케이션 기대치와 충돌할 수 있습니다. 열 이름이 중요해 보인다는 이유만으로 인덱스를 추가하지 마십시오. 먼저 속도가 느린 요청을 파악하고 실제 쿼리 실행 계획이 비효율적인지 확인해야 합니다.

1. ownCloud 빌드 및 데이터베이스를 확인합니다.

ownCloud 설치 디렉터리에서 웹 서버 계정으로 명령을 실행하세요. 일반적인 Debian 또는 Ubuntu 설치에서 해당 계정은 다음과 같습니다 www-data.

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

호스트에 구성된 경로와 서비스 계정을 사용하십시오. Docker 환경에서는 컨테이너의 공식 명령 형식을 사용하십시오. 예를 들어 ownCloud 설명서에서는 `--config-app`을 사용합니다 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 업그레이드는 코어 및 앱에 필요한 변경 사항을 포함하여 스키마를 발전시키는 데이터베이스 마이그레이션을 실행합니다. 공식 지침에서는 occ웹 요청 시간 초과가 발생할 수 있는 대규모 시스템의 경우 데이터베이스 업그레이드 단계를 완료할 것을 권장합니다.

관리자 개요에서 여전히 인덱스가 누락되었다고 표시되는 경우, sudo -u www-data php occ list사용 중인 ownCloud 빌드에 대한 관련 공식 문서를 확인하십시오. 일부 타사 가이드에서는 db:add-missing-indices해당 명령어를 보여주지만, 이 문서에서 검토한 ownCloud 10.16 데이터베이스 명령어 섹션에는 해당 명령어가 문서화되어 있지 않습니다. 빌드에 해당 명령어가 나열되어 있는 경우, 실행하기 전에 로컬 도움말을 참조하고 해당 빌드의 문서 또는 앱 공급업체에 절차를 확인하십시오. 해당 명령어가 없는 경우, Nextcloud 명령어를 설치하거나 ownCloud의 핵심 테이블을 수동으로 편집하거나 다른 버전의 SQL을 복사하지 마십시오. 경고 메시지, ownCloud 버전, 데이터베이스 유형 및 관련 로그를 ownCloud 또는 앱 관리자에게 공유하십시오.

ownCloud 설명서에 나와 있는 데이터베이스 명령(예: db:convert-type또는 db:convert-mysql-charset)은 특정 변환 작업을 위한 것이며, 일반적인 인덱스 튜닝 명령이 아닙니다. 쿼리 속도를 향상시키기 위해 변환 명령을 사용하지 마십시오.

4. 데이터베이스 기본 도구를 사용하여 느린 쿼리를 조사합니다.

느린 SQL 쿼리를 식별할 수 있다면 데이터베이스에서 제공하는 분석 도구를 사용하십시오. MySQL과 MariaDB는 분석 도구를 제공하며 EXPLAIN, PostgreSQL도 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 서버 10.16 occ 명령어 참조
• ownCloud 서버 10.16 데이터베이스 구성
• ownCloud 서버 10.16 백업 가이드
• ownCloud Classic 업그레이드 가이드
• ownCloud 메모리 캐싱 문서
• MySQL 8.4 EXPLAIN 설명서
• PostgreSQL EXPLAIN 설명서