나는 샤딩이 조각난 데이터 (샤드)를 상황에 맞는 집계를 쉽게 처리 할 수 있도록 되돌려 놓는 것으로 이해한다고 생각합니다. 이 올바른지?
업데이트 : 여기에서 어려움을 겪고있는 것 같습니다. 내 생각에 응용 프로그램 계층에는 데이터를 저장할 위치를 결정하는 비즈니스가 없어야합니다. 기껏해야 일종의 샤드 클라이언트 여야합니다. 두 가지 반응 모두 왜 중요한가에 대한 대답이 되었습니까? 명백한 성능 향상 이외에 어떤 영향을 미칩니 까? 이러한 이익이 MVC 위반을 상쇄하기에 충분합니까? 샤딩은 대규모 응용 분야에서 주로 중요합니까, 아니면 소규모 응용 분야에도 적용됩니까?
답변:
샤딩은 데이터베이스의 "수평 파티셔닝"의 또 다른 이름입니다. 더 명확하게하기 위해 해당 용어를 검색 할 수 있습니다.
에서 위키 백과 :
수평 파티셔닝은 데이터베이스 테이블의 행이 열별로 분할되지 않고 개별적으로 유지되는 설계 원칙입니다 (정규화와 동일). 각 파티션은 샤드의 일부를 형성하며,이 파티션은 별도의 데이터베이스 서버 또는 물리적 위치에있을 수 있습니다. 각 테이블의 행 수가 줄어든다는 장점이 있습니다 (이는 인덱스 크기를 줄여서 검색 성능을 향상시킵니다). 샤딩이 데이터의 실제 측면 (예 : 유럽 고객 대 미국 고객)을 기반으로하는 경우 적절한 샤드 멤버십을 쉽고 자동으로 유추하고 관련 샤드 만 쿼리 할 수 있습니다.
샤딩에 대한 추가 정보 :
먼저, 각 데이터베이스 서버는 동일한 테이블 구조를 갖습니다. 둘째, 데이터 레코드가 샤드 데이터베이스에서 논리적으로 분할됩니다. 파티션 된 데이터베이스와는 달리, 각 전체 데이터 레코드는 해당 데이터베이스에서 수행 된 모든 CRUD 조작과 함께 하나의 샤드에만 존재합니다 (백업 / 중복을위한 미러링이없는 경우). 사용 된 용어는 마음에 들지 않지만 논리 데이터베이스를 더 작은 부분으로 구성하는 다른 방법을 나타냅니다.
업데이트 : MVC를 중단하지 않습니다. 데이터를 저장할 정확한 샤드를 결정하는 작업은 데이터 액세스 계층에 의해 투명하게 수행됩니다. 거기에서 데이터베이스를 샤딩하는 데 사용한 기준에 따라 올바른 샤드를 결정해야합니다. (응용 프로그램의 구체적인 측면에 따라 수동으로 데이터베이스를 다른 샤드로 분할해야하므로) 올바른 샤드를 사용하려면 데이터베이스에서 데이터를로드 및 저장할 때주의해야합니다.
아마도 Java 코드가있는 이 예제 는 실제 시나리오에서 어떻게 작동하는지 다소 명확하게합니다 ( Hibernate Shards 프로젝트 에 관한 것입니다).
" why sharding" 를 해결하려면 : 주로 많은 양 의 데이터가있는 대규모 응용 프로그램에만 해당됩니다 . 첫째, 데이터베이스 쿼리에 대한 응답 시간을 최소화하는 데 도움이됩니다. 둘째, 더 큰 "하위"시스템을 사용하여 더 이상 충분하지 않은 하나의 큰 서버 대신 데이터를 호스팅 할 수 있습니다.
지역성이 상당히 제한된 DBMS에 대한 쿼리가있는 경우 (예 : 사용자가 'where username = $ my_username'으로 만 선택을 실행하면) AM으로 시작하는 모든 사용자 이름을 하나의 서버와 NZ에서 모두 입력하는 것이 좋습니다. 다른쪽에. 이것에 의해 일부 쿼리에 대해 거의 선형 스케일링됩니다.
간단히 말해 샤딩은 기본적으로로드를 두 서버에 균등하게 분산시키기 위해 다른 서버에 테이블을 분배하는 프로세스입니다.
물론 실제로는 훨씬 더 복잡합니다. :)
샤딩은 Normalization 인 vertical ( column wise ) 파티셔닝 과 반대로 수평 ( row wise ) 데이터베이스 파티셔닝 입니다. 매우 큰 데이터베이스를 데이터 샤드라고하는 더 작고 더 빠르고 쉽게 관리되는 부분으로 분리합니다. 분산 시스템을 달성하는 메커니즘입니다.
왜 분산 시스템이 필요합니까?
자세한 내용은 여기를 참조하십시오 : 분산 데이터베이스의 장점
샤딩이 분산 시스템을 달성하는 데 어떻게 도움이됩니까?
검색 인덱스를 N 개의 파티션으로 분할하고 각 인덱스를 별도의 서버에로드 할 수 있습니다. 하나의 서버를 쿼리하면 결과의 1 / N을 얻게됩니다. 따라서 완전한 결과 집합을 얻기 위해 일반적인 분산 검색 시스템 은 각 서버에서 결과를 누적하고 결합 하는 집계 자를 사용 합니다. 애그리 게이터는 또한 각 서버에 쿼리를 분배합니다. 이 어 그리 게이터 프로그램 을 빅 데이터 용어로 MapReduce 라고 합니다. 즉, 분산 시스템 = Sharding + MapReduce (다른 것들도 있지만).
아래의 시각적 표현. 
샤딩은 대규모 응용 분야에서 주로 중요합니까, 아니면 소규모 응용 분야에 적용됩니까?
샤딩은 단일 데이터베이스 서버가 제공 할 수있는 것 이상으로 요구가 확장되는 경우에만 문제가됩니다. 샤딩 가능한 데이터가 있고 확장 성과 성능 요구 사항이 엄청나게 높으면 확장 도구입니다. 나는 12 년 동안 소프트웨어 전문가로 일했으며 샤딩의 이점을 누릴 수있는 한 가지 상황에 직면했다고 생각합니다. 적용 성이 매우 제한된 고급 기술입니다.
게다가 미래는 아마도 모든 잠재적 인 성능 제한을 지우는 거대한 객체 "클라우드"처럼 재미 있고 흥미 진진 할 것입니다. :)
Sharding은 원래 Google 엔지니어가 만든 것으로 Google App Engine에서 애플리케이션을 작성할 때 상당히 많이 사용 된 것을 볼 수 있습니다. 쿼리에서 사용할 수있는 리소스 양에 대한 제한이 많고 쿼리 자체에는 엄격한 제한이 있으므로 샤딩은 권장 될뿐만 아니라 아키텍처에 의해 거의 시행됩니다.
샤딩을 사용할 수있는 또 다른 장소는 데이터 엔터티에 대한 경합을 줄이는 것입니다. 확장 가능한 시스템을 구축 할 때는 항상 병목 현상이 발생하기 때문에 자주 작성되는 데이터를 감시하는 것이 특히 중요합니다. 좋은 해결책은 특정 엔터티를 분할하고 여러 복사본에 쓴 다음 합계를 읽는 것입니다. 이 "파편 카운터 wrt GAE의 예 : http://code.google.com/appengine/articles/sharding_counters.html
샤딩은 단순한 수평 분할 이상을 수행합니다. 에 따르면 위키 피 디아 기사 ,
수평 파티셔닝은 일반적으로 스키마 및 데이터베이스 서버의 단일 인스턴스 내에서 하나 이상의 테이블을 행별로 분할합니다. 인덱스를 먼저 검색 할 필요없이 특정 행을 찾을 파티션을 식별 할 수있는 명확하고 강력하며 암시적인 방법이있는 경우 인덱스 크기를 줄임으로써 (따라서 검색 노력) 이점을 제공 할 수 있습니다. 'CustomersEast'및 'CustomersWest'테이블의 예. 우편 번호는 이미 찾을 위치를 나타냅니다.
샤딩 (Shading)은 문제를 뛰어 넘습니다. 문제가있는 테이블을 같은 방식으로 분할하지만 잠재적으로 여러 스키마 인스턴스에서이를 수행합니다. 큰 분할 된 테이블에 대한 검색로드를 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버 (논리적 또는 물리적)로 나눌 수 있다는 것이 명백한 이점입니다.
또한,
여러 개의 격리 된 인스턴스에서 샤드를 분할하려면 단순한 수평 분할 이상이 필요합니다. 데이터베이스를 쿼리 할 때 단순한 차원 테이블을 검색하기 위해 두 인스턴스를 모두 쿼리해야하는 경우 효율성의 기대치가 사라집니다. 분할 외에도 샤딩은 서버에서 큰 분할 가능한 테이블을 분할하는 반면 작은 테이블은 완전한 단위로 복제됩니다.
내 생각에 응용 프로그램 계층에는 데이터를 저장할 위치를 결정하는 비즈니스가 없어야합니다.
이것은 좋은 규칙이지만 대부분의 것처럼 항상 올바른 것은 아닙니다.
아키텍처를 수행 할 때는 책임과 협업으로 시작해야합니다. 기능적 아키텍처를 결정하면 비 기능적 힘의 균형을 맞춰야합니다.
이러한 비 기능적 힘 중 하나가 대규모 확장 성인 경우 데이터 스토리지 추상화가 이제 애플리케이션 계층으로 누출되는 경우에도이 힘을 수용하도록 아키텍처를 조정해야합니다.