여러 데이터베이스 액세스 또는 하나의 대규모 액세스?

25

만 필요, 또는 모든 정보를 보유하는 객체 검색하기 위해 하나의 액세스를 수행 할 때 필요한 정확한 정보를 얻을에 AJAX를 통해 데이터베이스 여러 번 접근 : 그것은 성능과 최적의 자원 활용에 관해서 어떻게 더 나은 방법입니다 수있는 필요를 실제로 모든 것이 필요 하지는 않을 가능성이 높은가 ?

실제 쿼리를 벤치마킹하는 방법을 알고 있지만 수천 명의 사용자가 데이터베이스에 동시에 액세스하고 연결 풀링이 어떻게 작동하는지 데이터베이스 성능과 관련하여 최상의 결과를 테스트하는 방법을 모르겠습니다.

performance sql

— DudeOnRock
소스

어떤 플랫폼을 사용합니까? 램프를 사용하는 경우 memcaching을 사용하는 경우

— ravi404

다른 성능 최적화와 동일하게 측정합니다.

— Telastyn

2

@ Telastyn : 나는 기본적인 디자인을 결정하고 준비 서버가 없습니다. 내 모든 DB 호출은 PHP가 실행되는 동일한 컴퓨터에있는 DB에 대한 것입니다. 나는 내가 가기로 결정한 길은 모든 것이 현지에있을 때 좋았지 만 생방송에서는 차선책이라는 것을 깨닫기 전에 다른 사람들의 경험에서 배우기를 바랐습니다.

— DudeOnRock

1

@DudeOnRock - 고개를 끄덕 일반적으로는 데이터 변경하여 사용 패턴에 얼마나 의존한다. 하나의 쿼리가 사람들이 필요로하는 것의 80 %를 제공하고 데이터가 자주 변경되지 않는 경우 그에 따라 진행하십시오. 캐시하기 쉽고 최적화하기 쉽습니다. 하나의 쿼리가 일반적으로 사용자가 필요로하는 것의 5 %를 반환하면 그렇지 않을 수 있습니다. 나는 적은 것보다 더 많은 쿼리를 선호합니다. 서버에 도착하기 전에 항상 서버에서 잘라낼 수 있습니다. '모든 것이 하나의 쿼리를 만듭니다'를 실행 취소하기가 더 어렵습니다.

— Telastyn

@ravz : 재미있는 소리!

— DudeOnRock

27

이에 대한 정답은 없습니다. 다른 최적화와 마찬가지로 컨텍스트 / 사용법에 크게 의존합니다.

그러나 경험 상으로는 다음을 고려하십시오.

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

— 에드 헤이스팅스
소스

24

최적화의 첫 번째 규칙을 기억하십시오. 측정, 추측하지 마십시오 . 두 가지를 모두 시도하고 일종의 스톱워치 코드로 계측하고 더 오래 걸리는 것을 확인하십시오.

또한 컴퓨터 공학에는 두 가지 어려운 문제가있다 : 캐시 무효화와 이름 지정 문제가 있다는 오래된 농담을 명심해야한다. DB에서 모든 것을 한 번에 가져 와서 메모리에 보관하면 캐시가 있습니다. 이제 새로운 문제가 발생합니다. 시스템의 어느 곳에서든 변경 될 때마다 데이터베이스와 캐시의 두 위치에서 동일한 변경을 수행해야합니다. DB와 통신하는 서버가 두 대 이상이거나 서버를 통해 데이터를 수정하도록 여러 API를 사용하는 경우 매우 까다로울 수 있습니다.

— 메이슨 휠러
소스

그리고 당신이 무엇 을 측정 하는지 확인하십시오 . 예를 들어 결과는 데이터베이스 연결 대역폭 및 대기 시간에 따라 달라질 수 있습니다.

— SpaceTrucker

4

이 질문에 대한 은 총알 솔루션 은 없습니다 . 가능한 트레이드 오프 를 시도하고 서버를 최대한 조정하여 서버를 최대한 활용 해야한다고 생각 합니다.

첫 번째 요점 : 개선을 시작하기 전에 현재 성능 벤치 마크 를 설정하고 , 측정하고 , 개선 할 수있는 가능한 솔루션을 비교 하여 기준선 으로 삼아야합니다.

두 번째는 응용 프로그램 사용 을 추적해야한다는 것입니다. 최종 사용자가 응용 프로그램을 활용하는 방법. 아래로 절단 반환 된 데이터 원시 숫자 최종 사용자에게 필요하지 않습니다 (들) 수 당신에게 많은 귀중한 서버 자원을 절약 . 예를 들어, 사용자가 처음 50 개에 관심이있는 동안 5000 개의 레코드를 반환 할 필요가 없습니다.

세 번째 요점 : 통화 빈도와 가능한 영향을 이해해야합니다. 예를 들어 대부분의 호출이 조회 값 테이블 쿼리 인 경우 이러한 호출 을 캐시 할 인프라를 만들 수 있습니다 . 즉, 데이터가 자주 변경되지 않으면 캐싱 옵션을 고려하십시오. 물론 통화 수를 최소화하면 항상 성능을 향상시키는 데 도움이됩니다.

— 엘 유수 보프
소스

2

"모든 것"에 BLOB 또는 이와 유사한 대용량 데이터 객체가 포함되지 않는 한 모든 것을 한 번에 가져 오면 성능이 향상됩니다. 모든 것을 직렬화하고 유선으로 이동 한 다음 다른 쪽에서 직렬화를 해제하는 성능 오버 헤드는 네트워크 대기 시간이 큰 부분을 차지하므로 상당히 중요합니다. 메모리는 네트워크 대역폭보다 저렴하며 한동안 남아있을 것입니다. 당신의 유일한 대답은 벤치 마크에서 나올 것입니다. 그러나 당신이 다른 것을 측정하려고한다면, 그것이 내가 기대는 방법입니다.

— TMN
소스

의견에 따르면, 이것은 로컬 데이터베이스를 사용하고 있으므로 여기서는 "전선"대기 시간이 없습니다.

— 메이슨 휠러

1

그 의견에 따르면, 그는 "모든 것이 현지에있을 때는 좋지만, 생방송에 대해서는 차선책"이 될 수있는 전략을 찾고 있었다.

— TMN

1

아키텍처 결정을 내리는 경우 REST가 하나의 옵션입니다. REST를 사용하면 항상 리소스를 여러 번 요청합니다. 즉, 각 객체마다 고유 한 URL이 있기 때문에 2 개의 객체를 가져 오기위한 요청을 보내지 않습니다. 이 스타일을 수행 할 때의 성능 문제는 HTTP / 2.0이 나오면 해결 될 것입니다. 그렇지 않으면 가능한 한 빨리 만들도록 최적화하면됩니다. 많은 회사들이 이런 식으로하고 있습니다.

— imel96
소스