데이터베이스 캐시
Database caching |
데이터베이스 캐싱은 백엔드 데이터베이스에 액세스하여 주문형(동적으로) 웹 페이지를 생성하는 컴퓨터 응용 프로그램 설계에 포함된 프로세스입니다.
이러한 애플리케이션을 브라우저 기반 클라이언트, 웹 애플리케이션 서버 및 백엔드 [1][2]데이터베이스를 포함하는 다중 계층 환경에 도입할 경우 중간 계층 데이터베이스 캐싱을 사용하여 높은 확장성과 [2]성능을 실현합니다.
3계층 아키텍처에서는 애플리케이션 소프트웨어 계층과 데이터 스토리지 계층이 서로 다른 호스트에 있을 수 있습니다.애플리케이션의 throughput은 네트워크 속도에 의해 제한될 수 있습니다.이 제한은 데이터베이스를 애플리케이션 계층에 배치함으로써 최소화할 수 있습니다.상용 데이터베이스 소프트웨어는 시스템 리소스를 광범위하게 사용하기 때문에 애플리케이션과 데이터베이스를 동일한 호스트에 두는 것이 항상 실용적인 것은 아닙니다.이 경우 보다 가벼운 데이터베이스 애플리케이션을 사용하여 상용 데이터베이스 관리 시스템에서 데이터를 캐시할 수 있습니다.
혜택들
데이터베이스 캐싱은 백엔드에서 여러 개의 저렴한 프론트 엔드 시스템으로 쿼리 워크로드를 분산하여 확장성을 향상시킵니다.예를 들어 Platinum 고객의 데이터는 캐싱할 수 없지만 일반 고객의 데이터는 캐싱할 수 있습니다.캐싱은 백엔드 서버를 사용할 수 없는 경우에도 캐시된 테이블에만 의존하는 애플리케이션에 지속적인 서비스를 제공함으로써 데이터 가용성을 향상시킬 수 있습니다.또 다른 이점은 데이터의 인접성을 통해 데이터 액세스 속도가 향상되고 중간 계층과 데이터 [3]계층 간의 라운드 트립을 방지하여 로드 피크를 완화하는 것입니다.
잠재적인 설계 요소
- 업데이트 가능한 캐시 테이블:많은 캐시 시스템은 읽기 전용으로 되어 있기 때문에, 애플리케이션의 소규모 세그먼트(비실시간 애플리케이션)로 사용이 제한됩니다.
- 양방향 업데이트:업데이트 가능한 캐시의 경우 캐시에서 발생하는 업데이트는 타깃 데이터베이스로 전파되어야 하며 타깃 데이터베이스에서 직접 발생하는 업데이트는 자동으로 캐시에 도착해야 합니다.
- 동기 및 비동기 업데이트 전파:캐시 테이블의 업데이트는 두 가지 모드로 타깃 데이터베이스에 전파되어야 합니다.동기화 모드에서는 데이터베이스 작업이 완료된 후 대상 데이터베이스에도 업데이트가 적용됩니다.비동기 모드의 경우 업데이트는 대상 데이터베이스로 지연됩니다.동기 모드는 높은 캐시 일관성을 제공하며 실시간 애플리케이션에 적합합니다.비동기 모드는 높은 throughput을 제공하며 실시간에 가까운 애플리케이션에 적합합니다.
- 다중 캐시 입도 - 데이터베이스 수준, 테이블 수준 및 결과 세트 캐싱: 기업 데이터베이스의 주요 부분은 과거 기록으로 접근 빈도가 낮습니다.단, 프리미엄 고객의 데이터 등 즉시 접근할 수 있는 정보가 있습니다.
- 캐시된 테이블의 복구:시스템 또는 전원 장애 시 캐시 플랫폼 재시작 시 캐시된 테이블에서 커밋된 트랜잭션을 모두 복구해야 합니다.
- 캐시의 일관성을 검증하는 도구:업데이트 전파의 비동기 모드의 경우 서로 다른 캐시 노드와 대상 데이터베이스의 캐시가 분산될 수 있습니다.이 문제는 수동으로 해결해야 하며, 불일치를 식별하고 필요에 따라 수정 조치를 취해야 합니다.
- 수평 확장 가능:클러스터 컴퓨팅은 가용성을 높이고 로드 밸런싱을 실현할 수 있습니다.클러스터 환경에서 캐슁은 여러 노드에 걸쳐 캐슁된 데이터를 노드 간에 일관되게 유지합니다.
- 캐시되지 않은 테이블에 대한 투과적 접근은 대상 데이터베이스에 있습니다.데이터베이스 캐시는 쿼리를 추적하고 애플리케이션 코드를 변경하지 않고 데이터 인접성을 기반으로 데이터베이스 캐시 또는 원본 데이터베이스에 지능적으로 라우팅할 수 있어야 합니다.
- 투과적 페일오버:캐싱 플랫폼 장애 시 서비스 중단이 발생하지 않아야 합니다.클라이언트 연결은 대상 데이터베이스로 라우팅되어야 합니다.
- 응용 프로그램 변경 없음 또는 극히 일부:표준 인터페이스 JDBC, ODBC 등을 지원하여 애플리케이션 코드를 변경하지 않고 애플리케이션을 심리스하게 동작시킵니다.저장 프로시저 콜을 모두 타깃 데이터베이스로 라우팅하여 이행할 필요가 없습니다.
구현에 있어서의 함정
- 삭제 또는 비활성화 이벤트 캐시 워킹:Redis 또는 Hazelcast와 같은 외부 캐시 엔진을 활용하는 캐시 설계는 종종 비활성화된 개체에 대해 삭제를 발행하여 비활성화를 트리거합니다.이로 인해 단일 쓰기 작업이 수천 건의 삭제를 트리거하여 성능에 영향을 미칠 수 있습니다.
- 키 추적 부족:다시 말하지만 외부 캐시 엔진을 사용하는 경우 캐시 계층에서 키 검색이 트리거되는 경우가 많습니다.이 오류가 발생하면 추가 RTT를 트리거하여 요청의 전체 지연 시간을 늘릴 수 있습니다.단, Redis 및 Hazelcast 등의 엔진은 키 변경 알림을 지원하므로 원격 캐시 계층에서 키가 변경되었을 때 로컬 캐시 계층을 업데이트할 수 있습니다.이러한 키를 로컬로 추적하는 것으로, 캐시 미스에서의 리모트 룩업을 회피할 수 있어 캐시 히트 패널티를 회피할 수 있습니다.
- 시간 범위가 아닌 즉각적인 이벤트로 무효화:트랜잭션의 일부로 테이블을 변경하는 경우 다른 연결에 대한 쿼리가 변경 내용을 확인할 수 있는지 여부에 따라 SQL 모드가 영향을 받을 수 있습니다.따라서 트랜잭션이 아직 커밋되거나 롤백되지 않은 상태에서 트랜잭션 중에 테이블을 변경하면 트랜잭션이 완료될 때까지 테이블이 휘발성으로 간주됩니다.캐시 엔진은 쿼리 실행 전 또는 실행 후에만 결과를 무효화하는 경우가 많습니다.
- 분산 캐시(통신 부족):캐시 설계가 기본 스토리지 계층을 사용하는 경우 분산 캐쉬로 사용할 경우 지정된 시간에 기록되는 테이블을 기준으로 로컬에서 유효성 검사가 수행됩니다.안타깝게도 다른 노드가 동일한 테이블에 대해 캐시 개체를 썼을 수 있으며 이러한 개체는 비활성화되지 않습니다.업스트림클라이언트 퍼시스텐스를 가진 로컬세션 데이터에 사용할 경우 이는 허용할 수 있지만 세션 간에 일관성을 유지해야 하는 공유 데이터의 경우 데이터 일관성 문제가 발생할 수 있습니다.
레퍼런스
- ^ Larson, Per-åke; Goldstein, Jonathan (2004). "MTCache: Transparent mid-tier database caching". CiteSeerX 10.1.1.95.875.
{{cite journal}}:Cite 저널 요구 사항journal=(도움말) - ^ a b Altinel, Mehmet; Luo, Qiong; Krishnamurthy, Sailesh; Mohan, C.; Pirahesh, Hamid; Lindsay, Bruce G.; Woo, Honguk; Brown, Larry (2002). "DBCache: Database Caching For Web Application Servers" (PDF). CiteSeerX 10.1.1.104.8991.
{{cite journal}}:Cite 저널 요구 사항journal=(도움말) - ^ "Middle-tier Database Caching for e-Business". CiteSeerX 10.1.1.140.8455.
{{cite journal}}:Cite 저널 요구 사항journal=(도움말)
