비정규 화 된 SQL Server 데이터가 잘 작동하는 것처럼 보이는 이유는 무엇입니까?

Question

많은 SKU를 제공하도록 설계된 전자 상거래 웹 사이트에서 작업하고 있습니다. 이러한 제품을 설명하는 SQL Server 스키마는 몇 년 전에 고객에게 필요한 정보를 검색하는 것이 부당하게 느린 정도로 표준화되었습니다. 따라서 우리는 인프라에 대한 데이터를로드하는 비용을 부담하도록 인프라를 변경했습니다. 각 제품을 한 번 저장 한 다음 해당 데이터를 AppFabric 캐시 (이전의 Velocity)에 저장합니다.

시간이 지남에 따라 AppFabric 인프라에 대한 요구 사항의 복잡성이 커져서 캐시에서 데이터 검색, 증분 업데이트를 포함한 데이터 업데이트 등을 처리하는 데 상당한 시간을 투자해야했습니다.

우리는 많은 양의 제품 데이터를 부 데이터베이스의 비정규화된 형식으로 저장하기 때문에 실험을 위해 한 번에 ~ 150K SKU 중 하나를 무작위로 선택하고 레코드를 검색하는 콘솔 앱을 작성했습니다 우리 제품이 비정규 화 된 테이블에서 나온 것입니다.

AppFabric 캐시에서 평균 두 시간 동안 평균 약 2.5ms의 레코드를 선택할 수있는 거의 동일한 평균 시간에 이러한 레코드를 선택할 수 있다는 사실에 놀랐습니다. 두 경우 모두 데이터가 AppFabric 또는 디스크 캐시가 될 수있는 한 종류의 메모리 내 캐시에서 발생하며 2.5 밀리 초가 네트워크 왕복을위한 최소한의 시간 동안 부딪히는 것입니다.

이렇게하면 부하가 높거나 높은 성능을 필요로하는 SQL Server에서 비정규 화 된 데이터를 사용하는 것이 나을 것 같습니다. SQL Server 기반 데이터를위한 관리 도구가 훨씬 뛰어납니다. 우리 팀의 모든 devs는 Management Studio를 사용하는 데 익숙하지만 AppFabric을 사용하면 dev사람이 PowerShell을 사용하여 a) 캐시에 저장된 레코드 수를 제공하고 b) 캐시를 덤프 할 수 있습니다. 우리가 직접 만들어야하는 다른 관리 기능.

이렇게하면 왜 누군가가 AppFabric을 전혀 사용하지 않는지 묻습니다. 우리는 AppFabric 관련 솔루션에 적용해야하는 개발 노력의 비용이 SQL Server 라이선스 비용보다 훨씬 높기 때문에 비용에 신경 쓰지 않습니다.

Google 팀이 앞으로 나아갈 수있는 최상의 방향을 결정하는 데 도움이되는 피드백을 보내 주셔서 감사합니다.

Answer 1

캐싱 메커니즘을 사용하기로 결정하는 것은 매우 신중해야합니다. 실제로 항상 올바른 선택은 아닙니다. 그러나 내구성 지속 모델에서 캐싱을 사용하는 주된 이유는 매우 높은 트랜잭션로드를 관리하기 위해서입니다.

AppFabric 캐시에서 논리적 인 리포지터리 (로드 균형 조정 기능 포함)에서 작동하는 분산 된 서버 집합을 설정할 수 있습니다. 따라서로드 균형 조정을 위해 클러스터 된 인스턴스를 제공 할 수있는 방법이없는 Microsoft SQL Server와는 달리 하루에 50 억에서 1 억 번을 읽고 작성하는 경우 캐시는 이러한 리소스를 공유하는 데보다 실용적인 솔루션입니다. 그런 다음 이러한 쓰기 작업은 시간이 지남에 따라 내구성 지속 모델에 대기시킬 수 있으므로 캐싱 패브릭과 내구성 저장소간에 퍼져 있기 때문에 실제 사용량이 최대치가되지 않습니다.

Answer 2

비정규 스키마가 포함 된 전용 캐시 비공개 데이터베이스가 아닌 AppFabric을 사용하면 캐시 키 만료, 퇴거 및 튜닝 된 영역 정책에 대한 세밀한 제어가 가능합니다. SqlServer를 사용했다면 직접 롤백해야합니다. 또한로드 균형 조정과 높은 트랜잭션 속도 지원에 대한 @ mperrenoud03 의견에 동의합니다. 또한 NHibernate와 같은 좋은 ORM 도구를 사용하는 경우 Appfabric (또는 다른 분산 캐시 플랫폼)을 2 단계 캐시로 사용하도록 구성 할 수 있습니다. 우리는 프로젝트에서이를 활용하고 좋은 결과를 얻고 있습니다.