무엇이 단편적이고 왜 중요합니까?

무엇이 단편적이고 왜 중요합니까?

분할된 데이터(샤드)를 상황에 맞는 쉬운 Aggregate로 되돌리는 것이 어렵다는 것을 이해한다고 생각합니다.이거 맞는건가요?

업데이트: 저는 여기서 고생하고 있는 것 같습니다.제 생각에 애플리케이션 계층은 데이터를 저장할 위치를 결정하는 업무를 수행하지 않아야 합니다.기껏해야 어떤 종류의 공유 고객이어야 합니다.두 응답 모두 무엇이라고 대답했지만 왜 중요한 측면인지는 답하지 않았습니다.명백한 성능 향상 외에 어떤 의미가 있습니까?이러한 이득은 MVC 위반을 상쇄하기에 충분합니까?샤딩은 매우 큰 규모의 애플리케이션에서 대부분 중요합니까, 아니면 더 작은 규모의 애플리케이션에서도 중요합니까?

샤딩은 데이터베이스의 "수평 분할"의 다른 이름일 뿐입니다.해당 용어를 검색하여 더 명확하게 표시할 수 있습니다.

위키피디아에서:

수평 분할은 데이터베이스 테이블의 행을 열로 분할하는 것이 아니라 별도로 고정하는 설계 원리입니다(정규화의 경우).각 파티션은 샤드의 일부를 구성하며, 샤드는 별도의 데이터베이스 서버 또는 물리적 위치에 위치할 수 있습니다.장점은 각 테이블의 행 수가 감소된다는 것입니다(이렇게 하면 인덱스 크기가 줄어 검색 성능이 향상됩니다).공유가 데이터의 실제 측면에 기반을 둔 경우(예: 유럽 고객 대 유럽 고객).미국 고객) 그러면 해당 샤드 멤버십을 쉽고 자동으로 추론하고 해당 샤드만 조회할 수 있습니다.

공유에 대한 추가 정보:

첫째, 각 데이터베이스 서버는 동일한 테이블 구조를 가지고 있습니다.둘째, 데이터 기록은 공유 데이터베이스에서 논리적으로 분할됩니다.분할된 데이터베이스와 달리 각 전체 데이터 레코드는 하나의 샤드(백업/중복을 위한 미러링이 없는 경우)에만 존재하며, 모든 CRUD 작업은 해당 데이터베이스에서만 수행됩니다.사용되는 용어가 마음에 들지 않을 수도 있지만, 이는 논리적 데이터베이스를 더 작은 부분으로 구성하는 다른 방식을 의미합니다.

업데이트: MVC를 깨지 않습니다.데이터를 저장할 정확한 샤드를 결정하는 작업은 데이터 액세스 계층에 의해 투명하게 수행됩니다.데이터베이스 공유에 사용한 기준에 따라 올바른 공유를 결정해야 합니다.(응용프로그램의 몇 가지 구체적인 측면에 따라 데이터베이스를 수동으로 여러 조각으로 공유해야 하기 때문입니다.그런 다음 올바른 샤드를 사용하기 위해 데이터베이스에서 데이터를 로드하고 저장할 때 주의해야 합니다.

자바 코드를 사용한 이 예는 실제 시나리오에서 어떻게 작동하는지를 다소 명확하게 해줍니다(동면 샤즈 프로젝트에 관한 것입니다).

"을(를) 해결하기 위해"why sharding": 주로 데이터가 많은 매우 큰 규모의 애플리케이션에만 사용됩니다.첫째, 데이터베이스 쿼리에 대한 응답 시간을 최소화하는 데 도움이 됩니다.둘째, 더 이상 충분하지 않을 수도 있는 하나의 대형 서버 대신 더 저렴한 "저사양" 머신을 사용하여 데이터를 호스팅할 수 있습니다.

로컬리티가 상당히 제한된 DBMS에 대한 쿼리가 있는 경우(예: 사용자가 'where username = $my_username'로 선택한 경우만 실행), 한 서버에 A-M으로 시작하는 모든 사용자 이름을 넣고 다른 서버에 N-Z로 시작하는 모든 사용자 이름을 입력하는 것이 합리적입니다.이를 통해 일부 쿼리에 대해 선형 스케일링에 가까운 값을 얻을 수 있습니다.

간단히 말하면, 샤딩은 기본적으로 테이블을 서로 다른 서버에 분배하여 부하의 균형을 똑같이 맞추기 위한 프로세스입니다.

물론 현실은 훨씬 더 복잡합니다.:)

샤딩은 Normalization인 수직(열별) 파티셔닝과 반대로 수평(행별) 데이터베이스 파티셔닝입니다.매우 큰 데이터베이스를 데이터 샤드라고 하는 더 작고, 더 빠르고, 더 쉽게 관리할 수 있는 부분으로 분리합니다.이것은 분산 시스템을 달성하기 위한 메커니즘입니다.

분산형 시스템이 필요한 이유는 무엇입니까?

• 가용성 향상.
• 확장이 용이합니다.
• 경제성:단일 대형 컴퓨터의 힘으로 더 작은 컴퓨터의 네트워크를 만드는 것은 비용이 적게 듭니다.

자세한 내용은 여기에서 확인할 수 있습니다: 분산형 데이터베이스의 장점

분산 시스템을 달성하는 데 얼마나 많은 도움이 됩니까?

검색 인덱스를 N개의 파티션으로 분할하고 각 인덱스를 별도의 서버에 로드할 수 있습니다.하나의 서버에 쿼리를 하면 1/N의 결과를 얻을 수 있습니다.따라서, 일반적인 분산 검색 시스템은 각 서버의 결과를 축적하고 이를 결합하는 집계기를 사용합니다.집계기는 쿼리를 각 서버에 배포하기도 합니다.이 애그리게이터 프로그램은 빅데이터 용어로 맵리듀스(MapReduce)라고 불립니다.즉, Distributed Systems = Sharding + MapReduce (다른 것들도 있지만)입니다.

아래의 시각적 표현.

샤딩은 매우 큰 규모의 애플리케이션에서 대부분 중요합니까, 아니면 더 작은 규모의 애플리케이션에서도 중요합니까?

샤딩은 요구사항이 단일 데이터베이스 서버가 제공할 수 있는 범위를 초과하는 경우에만 우려되는 문제입니다.공유 가능한 데이터를 보유하고 있고 매우 높은 확장성과 성능 요구사항을 가지고 있다면 훌륭한 도구가 될 것입니다.소프트웨어 전문가로 일하던 12년 내내 샤딩을 통해 얻을 수 있었던 한 가지 상황에 직면했을 것입니다.적용 가능성이 매우 제한적인 진보된 기술입니다.

게다가 미래는 모든 잠재적인 성능 제한을 제거하는 거대한 객체 "클라우드"처럼 재미있고 흥미로운 것이 될 것입니다. 그렇죠? :)

샤딩은 원래 구글 엔지니어들에 의해 만들어졌으며 구글 앱 엔진에서 애플리케이션을 작성할 때 꽤 많이 사용되는 것을 볼 수 있습니다.쿼리가 사용할 수 있는 리소스의 양에 대해 엄격한 제한이 있고 쿼리 자체에도 엄격한 제한이 있기 때문에 공유가 권장될 뿐만 아니라 아키텍처에 의해 거의 강제됩니다.

공유를 사용할 수 있는 또 다른 방법은 데이터 엔티티에 대한 경합을 줄이는 것입니다.확장 가능한 시스템을 구축할 때는 항상 병목 현상이 발생하기 때문에 자주 작성되는 데이터를 주의해야 합니다.좋은 해결책은 해당 개체를 잘라내고 여러 복사본에 쓴 다음 전체를 읽는 것입니다.이 "sharded counterwrt GAE"의 예: http://code.google.com/appengine/articles/sharding_counters.html

샤딩은 단순히 수평 분할 이상의 역할을 합니다.위키피디아 기사에 의하면,

수평 분할은 보통 스키마와 데이터베이스 서버의 단일 인스턴스 내에서 하나 이상의 테이블을 행 단위로 분할합니다.인덱스를 먼저 검색할 필요 없이 특정 행의 파티션을 식별할 수 있는 명백하고 강력하며 암묵적인 방법이 있다면 인덱스 크기를 줄임으로써 이점을 제공할 수 있습니다(예: 'Customers East' 및 'Customers East'의 전형적인 예).서쪽 테이블, 우편번호가 어디에 있는지를 이미 알려주고 있습니다.

샤딩은 이 문제가 있는 테이블을 같은 방식으로 파티션을 분할하지만, 잠재적으로 여러 스키마 인스턴스에 걸쳐 이 작업을 수행합니다.큰 분할 테이블에 대한 검색 부하를 동일한 논리 서버의 여러 인덱스가 아닌 여러 서버(논리적 또는 물리적)로 분산할 수 있다는 장점이 분명합니다.

또한.

여러 분리된 인스턴스 간에 샤드를 분할하려면 단순한 수평 분할 이상의 작업이 필요합니다.데이터베이스를 쿼리하려면 두 인스턴스를 모두 쿼리해야 하고 간단한 차원 테이블을 검색해야 하는 경우에는 기대했던 효율성 향상이 손실됩니다.샤딩은 파티셔닝 이외에도 서버 전체에 걸쳐 큰 파티셔닝 테이블을 분할하는 동시에 작은 테이블은 완전한 단위로 복제됩니다.

애플리케이션 계층은 데이터를 저장할 위치를 결정하는 업무를 수행하지 않아야 한다고 생각합니다.

이것은 좋은 규칙이지만 대부분의 것들이 항상 정확하지는 않습니다.

아키텍처를 수행할 때 책임과 협업으로 시작합니다.기능적 아키텍처를 결정한 후에는 비기능적인 힘의 균형을 맞춰야 합니다.

이러한 비기능적인 요인 중 하나가 대규모 확장성이라면 데이터 스토리지 추상화가 애플리케이션 계층으로 유출되더라도 이에 대응하기 위해 아키텍처를 조정해야 합니다.

여기서 자세히 설명하지 못해서 죄송합니다만, 이 두 기사는 제가 발견한 샤딩 중 가장 좋은 기사이고 이 패턴을 어떻게 구현할 수 있는지에 대한 다른 전략입니다.

https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding

데이터 저장소를 수평 파티션 또는 조각으로 나눕니다.각 샤드는 동일한 스키마를 갖지만, 데이터의 고유한 부분 집합을(subset of data)을 보유합니다.샤드는 스토리지 노드 역할을 하는 서버에서 실행되는 자체 데이터 저장소(다양한 유형의 여러 엔티티에 대한 데이터를 포함할 수 있음)입니다.

https://www.mongodb.com/features/database-sharding-explained

샤딩(sharding)은 수평 스케일링 또는 스케일 아웃이라고 하는 스케일링의 한 형태로, 부하를 공유하기 위해 추가적인 노드가 도입됩니다.수평적 확장을 통해 빅데이터와 집중적인 워크로드를 처리할 수 있는 거의 무한한 확장성을 제공합니다.이와 달리 수직 스케일링은 보다 강력한 CPU, RAM 증가 또는 스토리지 용량 증가를 통해 단일 시스템 또는 단일 서버의 전력을 증가시키는 것을 말합니다.

언급URL : https://stackoverflow.com/questions/992988/what-is-sharding-and-why-is-it-important