인덱스를 안전하게 관리하여 ownCloud 10 쿼리 속도를 향상시키세요

ownCloud 10의 경우, 먼저 설치된 코어 및 앱에서 제공하는 스키마 변경 사항을 적용한 다음 실제로 속도가 느린 데이터베이스 쿼리를 확인하십시오. 인덱스를 무턱대고 추가하거나 Nextcloud 명령어가 db:add-missing-indicesownCloud 10 복구 명령어라고 가정하지 마십시오. 현재 ownCloud Server 10.15 OCC 참조 문서에는 해당 명령어가 나와 있지 않습니다. 인덱스는 일치하는 항목을 읽는 속도를 향상시킬 수 있지만, 인덱스를 추가할 때마다 저장 공간이 소모되고 삽입, 업데이트 및 삭제 작업에 추가적인 부담이 발생합니다.

이 접근 방식은 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웹 서버 계정>은 사용 중인 배포판의 웹 서버 계정으로 바꿔야 합니다.
2. 작업 속도가 느려지는 부분을 기록하세요. 영향을 받는 화면이나 앱, 대략적인 시간, 그리고 지연 현상이 반복되는지 여부를 기록해 두세요. ownCloud 로그와 데이터베이스의 느린 쿼리 진단 정보를 검토하세요. 로그에는 민감한 SQL 값이 포함될 수 있고 용량이 빠르게 증가할 수 있으므로, 데이터베이스 공급업체의 지침에 따라서만 쿼리 로깅을 활성화하세요.
3. 데이터베이스와 설정을 백업하십시오. 데이터베이스 일관성 백업 방법을 사용하고 백업 파일이 읽기 가능한지 확인하십시오. ownCloud의 백업 설명서는 mysqldump --single-transactionMySQL 호환 데이터베이스를 예시로 사용하고 있으므로 호스트, 사용자 및 데이터베이스 값을 사용자의 구성에 맞게 조정하십시오. 데이터베이스 암호를 셸 기록이나 프로세스 목록에 직접 저장하지 마십시오.
4. 일정 변경 시 책임감 있게 진행하십시오. 스키마 업그레이드 또는 인덱스 구축은 디스크 I/O, CPU 및 잠금을 사용할 수 있습니다. 사용량이 많거나 대규모 설치 환경에서는 사용자에게 작업 기간을 미리 알리고 데이터베이스 부하를 모니터링하십시오. ownCloud 유지 관리 모드는 해당 업그레이드 또는 유지 관리 절차에서 요구하는 경우에만 사용하십시오. 백업을 대체하는 용도로 활성화하지 마십시오.

먼저 ownCloud에서 관리하는 스키마 업데이트를 적용하세요.

ownCloud 코어 또는 앱 업데이트가 보류 중인 경우 설치 방법에 맞는 문서화된 업그레이드 프로세스를 사용하십시오. 일반적인 Linux 설치 환경에서는 ownCloud 루트 디렉터리에서 HTTP 사용자로 OCC 명령을 실행합니다. 수동 업그레이드 지침을 따르는 경우 명령은 다음과 같습니다.

sudo -u www-data ./occ upgrade

파일이 부분적으로만 업데이트된 설치 환경에서는 이 명령을 실행하지 마십시오. 먼저 해당 릴리스 파일을 스테이징하고 해당 릴리스의 공식 업그레이드 단계를 따르십시오. Docker 배포의 경우, 다른 PHP 환경을 가리키는 호스트 경로 대신 컨테이너에 문서화된 OCC 호출 방식을 사용하십시오.

명령 출력과 로그를 모두 읽으십시오. 명령이 성공적으로 완료되면 마이그레이션 실패 보고가 없어야 합니다. 하지만 모든 느린 쿼리 문제가 해결된다는 보장은 없습니다. 업데이트 중에 마이그레이션 오류가 보고되면 명령을 반복적으로 다시 실행하거나 스키마 테이블을 수동으로 편집하는 대신, 작업을 중지하고 해당 오류를 조사하십시오. 앱 마이그레이션이 관련된 경우, 버전별 ownCloud 업그레이드 문서와 앱 관리자에게 문의하십시오.

ownCloud 10.15 OCC 참조 문서에는 `stdlib` db:convert-type, db:convert-mysql-charset`stdlib`, `stdlib`과 같은 데이터베이스 명령이 나열되어 있지만 db:restore-default-row-format`stdlib`은 나열되어 있지 않습니다 . 명령 사용 가능 여부는 릴리스 및 설치된 코드에 따라 다를 수 있으므로 `stdlib` 또는 ` stdlib` 명령 db:add-missing-indices을 사용하여 인스턴스를 확인할 수 있습니다 . `stdlib`에서 알 수 없는 명령이 보고되는 경우 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_.

인덱스를 생성하기 전에 제안된 열을 쿼리의 필터, 조인 및 정렬 순서와 비교하십시오. 복합 인덱스의 열 순서는 중요하며, 기존 인덱스를 중복 생성하면 실행 계획이 개선되지 않고 비용만 증가할 수 있습니다. 데이터베이스 관리자(DBA)에게 데이터베이스 버전 동작, 온라인 또는 동시 인덱스 생성 지원, 디스크 여유 공간, 잠금 영향 및 롤백 절차를 고려해 달라고 요청하십시오. 이러한 세부 정보는 엔진 및 버전에 따라 다르므로 모든 ownCloud 10 설치 환경에 적용 가능한 단일한 안전한 SQL 문은 없습니다.

이름이 중복된다는 이유만으로 ownCloud 테이블을 변경하거나 인덱스를 삭제하지 마십시오. 이러한 변경 사항은 향후 코어 또는 애플리케이션 마이그레이션과 충돌할 수 있으며, 검토한 쿼리와 다른 쿼리를 사용하는 기능을 손상시킬 수 있습니다. 수동으로 변경한 스키마는 반드시 기록해 두고 복원 또는 마이그레이션 후 다시 생성할 수 있도록 하십시오. 누락된 인덱스가 제품 스키마 결함인 경우, 지원되는 ownCloud 패치 또는 애플리케이션 릴리스를 사용하는 것이 좋습니다.

데이터베이스 수준의 대안을 비교하세요

계획에 이미 적절한 인덱스가 사용되고 있다면, 다른 인덱스를 추가한다고 해서 다른 곳에서 발생한 지연 문제가 해결될 가능성은 낮습니다. 관찰된 병목 현상과 다음 옵션들을 비교해 보세요.

• MySQL 또는 MariaDB: 관리자가 이미 이러한 엔진을 운영하고 있는 환경에 적합한 일반적인 배포 방식입니다. 서버 설정을 변경하기 전에 버퍼 풀 메모리, 디스크 지연 시간, 연결 상태 및 느린 쿼리 실행 계획을 검토하십시오.
• PostgreSQL: ownCloud 10에서 PHP 데이터베이스 커넥터 및 배포가 올바르게 구성된 경우 지원되는 대체 데이터베이스입니다. 쿼리 계획 및 인덱스 유지 관리 도구는 MySQL과 다르므로 PostgreSQL 관련 권장 사항을 따르십시오.
• SQLite는 테스트 또는 소규모 단일 사용자 환경에서 사용하기에는 간편하지만, 여러 사용자가 동시에 접속하는 운영 환경의 프로덕션 워크로드에는 적합하지 않습니다. 인덱스 튜닝으로는 배포 환경의 동시 접속 제한을 해제할 수 없습니다.

데이터베이스 엔진 변경은 간단한 인덱스 수정이 아니라 마이그레이션 프로젝트입니다. ownCloud는 occ db:convert-type지원되는 변환 기능을 제공합니다. 변환에 필요한 조건을 검토하고, 먼저 백업을 수행한 후, 변환된 인스턴스를 테스트한 다음 사용자에게 제공하십시오.

결과를 검증하고 증거와 일치하지 않으면 중단하십시오.

유사한 조건에서 동일한 사용자 작업을 반복하고 쿼리 시간, 실행 계획, 검사된 행 수, 데이터베이스 I/O 및 서버 부하를 비교하십시오. 관련 ownCloud 페이지 또는 앱이 정상적으로 완료되고 로그에 데이터베이스 또는 마이그레이션 오류가 없는지 확인하십시오. 단일 요청에서 더 빠른 결과가 나왔다고 해서 전반적인 개선을 의미하는 것은 아닙니다. 여러 대표적인 요청을 비교하고 캐시 상태도 고려해야 합니다.

적절한 인덱스를 사용하는데도 동일한 쿼리가 계속 느리다면, 잠금, 스토리지, 네트워크 지연 시간, PHP 워커 및 데이터베이스 리소스 제한을 조사하십시오. 쿼리 실행 계획이나 테이블 구조가 불분명한 경우, 수동 DDL을 실행하기 전에 중단하고 DBA 또는 ownCloud 지원 담당자에게 검토를 요청하십시오. 이렇게 하면 설치된 ownCloud 버전 및 측정된 쿼리에 맞춰 스키마가 정렬되고, 추적되지 않은 인덱스 변경 사항이 발생하지 않는 것이 가장 확실한 결과입니다.

공식 참조

• ownCloud 서버 10.15 OCC 명령어 참조
• ownCloud 서버 10.15 수동 업그레이드 절차
• ownCloud Server 10.15 데이터베이스 변환 가이드
• ownCloud Server 10.15 백업 문서
• ownCloud Server 10.15 관리 문서