mysql을 최적화하거나 캐시를 사용하시겠습니까?

구체적으로 비교하고 싶은 두 가지 최적화 전략은 MySQL 최적화와 캐싱입니다. 이러한 최적화는 직교적이며, 둘 중 하나를 선택해야 하는 유일한 이유는 둘 다 리소스, 즉 개발 시간이 소요된다는 점을 미리 지적하세요.

장점

1. 모든 애플리케이션 사용자에게 최적화된 쿼리가 빠릅니다. 인덱스는 로그 복잡도 속도(분할화, 전화번호부를 검색할 때 검색 범위가 점차 좁아짐)로 데이터를 검색하고, 데이터 양이 증가함에 따라 좋은 성능을 유지하기 때문입니다. 인덱싱되지 않은 쿼리 결과를 캐싱하면 데이터가 증가함에 따라 성능이 저하되는 경우가 있습니다. 데이터가 증가함에 따라 캐시를 놓친 사용자는 좋지 않은 경험을 하고 애플리케이션을 사용할 수 없게 될 수 있습니다.

2. MySQL을 최적화하는 데에는 캐시 무효화나 캐시된 데이터 만료에 대해 걱정할 필요가 없습니다.

3. MySQL을 최적화하면 기술 아키텍처가 단순화되어 개발 환경에서 복사 및 작업이 더 쉬워집니다.

단점

1. 일부 쿼리는 인덱싱만으로는 성능을 향상시킬 수 없으며 경우에 따라 모드를 변경해야 할 수도 있습니다. 이는 일부 애플리케이션에서는 매우 번거로울 수 있습니다.

　2. 일부 스키마 변경은 비정규화(데이터 백업)를 위해 사용될 수 있습니다. 이는 DBA에게 일반적인 기술이지만 애플리케이션에서 모든 것을 업데이트하려면 소유권이 필요하며, 그러한 변경을 보장하려면 트리거를 설치해야 합니다.

3. 일부 최적화 방법은 MySQL에만 고유할 수 있습니다. 즉, 기본 소프트웨어가 여러 데이터베이스에서 작동하도록 포팅된 경우 인덱스 추가 이외의 더 복잡한 최적화 기술 중 일부가 보편적인지 확인하기가 어렵습니다.

캐싱 사용

이러한 최적화를 위해서는 애플리케이션의 실제 상황을 분석한 후 비용이 많이 드는 처리 부분을 MySQL에서 분리하고 이를 memcached와 같은 타사 캐시로 교체해야 합니다. 또는 레디스.

장점

1. 대규모 집계 또는 그룹화 쿼리와 같이 MySql 자체적으로 최적화하기 어려운 일부 쿼리에는 캐싱이 잘 작동합니다.

　2. 캐싱은 시스템의 처리 속도를 향상시키는 좋은 솔루션이 될 수 있습니다. 예를 들어, 여러 사람이 동시에 애플리케이션에 액세스하면 응답 속도가 매우 느립니다.

3. 다른 애플리케이션 위에 캐시를 구축하는 것이 더 쉬울 수 있습니다. 예를 들어, 귀하의 애플리케이션은 MySQL을 사용하여 데이터를 저장하는 다른 소프트웨어 패키지의 프런트 엔드일 수 있으며, 이 소프트웨어 패키지에 데이터베이스를 변경하는 것은 매우 어렵습니다.

단점

1. 데이터가 여러 외부 액세스 패러다임을 제공하는 경우(예: 다른 페이지에 다른 형식으로 표시됨) 캐시를 만료하거나 업데이트하기 어려울 수 있습니다. 만료된 데이터를 허용해야 할 수도 있습니다. 가능한 대안은 보다 정교한 캐싱 메커니즘을 설계하는 것입니다. 물론 캐시를 여러 번 얻으면 대기 시간이 길어진다는 단점도 있습니다.

2. 값비싼 객체를 캐싱하면 캐시를 놓친 사용자에게 성능 차이가 발생할 수 있습니다(MySQL 최적화의 장점 #1 참조). 일부 좋은 성능 사례에서는 단순히 평균을 내는 것(캐시가 하는 경향이 있음)보다는 사용자 간의 차이를 최소화하도록 노력해야 한다고 제안합니다.

3. 순진한 캐시 구현은 눈사태 효과와 같은 일부 미묘한 취약점에 대처할 수 없습니다. 바로 지난주에 나는 동일한 캐시된 콘텐츠를 동시에 재생성하려는 여러 사용자 요청으로 인해 데이터베이스 서버가 압도되는 한 사람을 도왔습니다. 올바른 전략은 캐시 재생성 요청을 직렬화하기 위해 특정 수준의 잠금을 도입하는 것입니다.

요약

일반적으로 사용자들에게 MySQL을 먼저 최적화하는 것이 좋습니다. 처음에는 이것이 제 생각에 가장 적합한 솔루션이기 때문입니다. 그러나 장기적으로 대부분의 애플리케이션에는 위의 솔루션을 어느 정도 동시에 구현해야 하는 일부 사용 사례가 있을 것입니다.