왜 MySQL DB 캐싱을 사용합니까?

Question

저는 현재 MySQL 데이터베이스를 많이 사용하는 두 개의 iOS 응용 프로그램을 개발하고 있습니다. 그들 각각은 MySQL 데이터베이스로부터 데이터를 요구하는 관련 질의를 실행하는 각각의 애플리케이션에 의해 요구되는 그들 자신의 API를 갖는다.

쿼리는 간단하고 사용자 또는 '객체'를 기반으로되는 변화 : 기반 위치에

SELECT `username`, `id`, `full_name` FROM `users` WHERE `id` = 1 
INSERT INTO `users` (`full_name`, `username`, `email`, `password`, `signup_method`, `latitude`, `longitude`) VALUES (?, ?, ?, ?, ?, ?, ?)" 
SELECT q.*, (SELECT COUNT(a.qid) FROM answers as a WHERE qid=q.id) AS a_count FROM questions as q ORDER BY a_count DESC LIMIT 1, 10 

:

SELECT (6371 * acos(cos(radians(?)) * cos(radians(latitude)) * cos(radians(longitude) - radians(?)) + sin(radians(?)) * sin(radians(latitude)))) AS distance FROM `users` HAVING distance <= 5 ORDER BY points DESC 

SELECT * , (6371 * acos(cos(radians(latitude)) * cos(radians({$values['latitude']})) * cos(radians({$values['longitude']}) - radians(longitude)) + sin(radians(latitude)) * sin(radians({$values['latitude']})))) AS distance FROM `questions` HAVING distance <= ? ORDER by distance LIMIT ?,? 

이러한 쿼리는 분명 시간이 걸립니다. 특히 후자는 성능 강렬 때문에 발생합니다.

많은 서비스에서는 성능 향상을 위해 데이터베이스와 함께 캐싱 계층을 사용합니다. 예컨대 :

• Memcachd
• 레디 스
• 보다.

제 질문은 쿼리와 관련하여 캐싱을 사용해야하며 캐싱을 사용할 때의 이점은 무엇입니까?

감사합니다.

최대!

Answer 1

처음부터 결과를 생성하는 것보다 캐시가 더 저렴할 때 간단하게 캐시해야합니다. 다양한 서버 및 소프트웨어의

• 처리 능력 :

  이 비용은 같은 것들에 따라 달라집니다. db 서버의 용량은 제한적이지만 다른 서버의 용량은 초과 할 수 있습니다.

• 돈 : 캐시 시스템을 구축하는 것보다 더 강력한 하드웨어를 구입하는 것이 저렴합니까?
• 캐시의 RAM 비용 대 스크래치 결과를 생성하는 CPU 비용. 대부분의 경우 DB 서버는 CPU 바운드이지만 캐시 서버는 메모리 바운드입니다. 그것은 당신이 당신의 경우에 업그레이 드하는 것이 저렴 결정할 수 있습니다.
• 캐시에서 검색하는 속도 대 db에서 검색하는 속도. 만약 당신이 말한 것처럼 질의가 시간이 많이 걸리고 캐시에서 가져 오는 것이 더 저렴하다면 캐싱은 요청을 빠르게 할 것입니다.
• 얼마나 자주 캐시 된 항목을 새로 고쳐야합니까? 그들이 단지 몇 초만 지속된다면, 번거 로움을 감당할 가치가 없을 수도 있습니다.
• 에는 캐시 된 항목을 만료하고 새로 고치는 방법이 있습니다. 이것은 종종 매우 어려운 문제입니다.
• 은 기술적 지식과 추가적인 복잡성을 관리 할 시간이 있습니다.

항상 원본에서 시작하십시오. MySQL의 느린 질의 로그를 검토하여 비용이 많이 드는 쿼리를 확인 했습니까? 중요한 색인이 누락 된 곳과 예기치 않게 오래 걸리는 쿼리를 확인할 수 있습니다. Percona-Toolkit의 [pt-query-digest]1은이 로그 파일을 요약하여 도움을 줄 수 있습니다. 캐싱을 시작하기 전에 데이터베이스를 최적화하십시오.

쿼리 유형을 살펴보면 결과 캐싱과 캐시 미리 예열조차도 가치가 있다고 생각됩니다.

캐시 선택은 물론 중요한 과정입니다. MySQL의 내장 쿼리 캐시를 이미 사용하고 있다고 가정합니다. 활성화되어 있고 충분한 메모리가 할당되어 있는지 확인하십시오. 'SELECT username'과 같은 간단한 쿼리는 값이 싸지 만 MySQL 자체에서도 쉽게 캐시됩니다. 그러나 내장 된 쿼리 캐싱에는 많은 한계가 있으며 쿼리가 캐싱되지 않거나 캐시가 플러시되는 많은 이유가 있습니다. 예를 들어 위치 기반 쿼리와 같은 함수가 포함 된 쿼리는 건너 뜁니다. 문서를 읽으십시오.

Redis와 같은 캐시를 사용하면 캐시 할 대상, 기간 및 만료 방법을 훨씬 효과적으로 제어 할 수 있습니다. 이 방법을 구현하는 방법에 대한 많은 아이디어가 있으며 응용 프로그램에 따라 다릅니다. 인터넷을 둘러보십시오.

간단하고 저렴하며 조금 도움이 될 것이기 때문에 query-cache를 사용하도록 제안합니다. 데이터베이스에 대한 캐싱 계층을 구현하는 방법을 살펴 보겠습니다. 어쩌면 위치 기반 쿼리를위한 내장 메서드가있는 Solr과 같은 인덱싱 서버를 고려해 볼 가치가 있습니다. 우리는 MySQL과 함께 사용합니다.

캐싱에는 Memcached와 Redis가 좋습니다. 개인적으로 Redis는 디스크에 더 많은 유스 케이스와 선택적인 지속성을 가지고 있기 때문에 선택 하겠지만, 그것은 전적으로 당신에게 달렸습니다. 어쩌면 선택의 틀에는 응용 프로그램에서 사용할 수있는 기존 구성 요소가있을 수 있습니다.

다른 팁 : 모든 것을 측정하십시오. 무엇이 시간이 걸리는지 알고있는 경우에만 최적화 또는 캐시 할 항목을 알 수 있습니다. 또한 측정을 다시 수행하면 최적화 결과가 명확 해집니다. statsd과 같은 것을 구현하고 응용 프로그램의 다양한 이벤트와 타이밍을 측정하십시오. 충분하지 않은 것보다 훨씬 좋은 것. 결과를 그래프로 나타내고 시간 경과에 따라 분석합니다. 나타나면 놀라게 될 것입니다.

Answer 2

캐싱을 사용하면 매우 시간 집약적이므로 MySQL 쿼리를 사용하는 것보다 훨씬 빠르게 데이터베이스에 액세스 할 수 있습니다. 대부분의 경우 웹 응용 프로그램이 커지면 데이터베이스가 병목 현상이 가장 커서 쿼리 속도 때문에 많은 백업이 발생합니다. 결과적으로 많은 웹 사이트와 회사는 데이터베이스에서 정보에 액세스하는 속도를 높이는 빠르고 간단한 방법으로 캐싱에 의존합니다. 나는 개발 초기 단계에서 걱정하지 말고, 작동하는 알파 웹 사이트가있을 때 사용해보십시오.