샤드 (데이터베이스 아키텍처)

**데이터베이스 샤드**(database shard)는 데이터베이스나 웹 검색 엔진의 데이터의 수평 분할이다. 개개의 파티션은 샤드(shard) 또는 데이터베이스 샤드(database shard)로 부른다. 각 샤드는 개개의 데이터베이스 서버 인스턴스에서 부하 분산을 위해 보유하고 있다. 데이터베이스 내의 일부 데이터는 모든 샤드에 존재하지만Typically 'supporting' data such as :en:dimension tables 일부는 하나의 샤드에만 존재한다. 각 샤드(또는 서버)는 이 데이터 부분을 위해 "하나"의 소스로서 동작한다.
# 데이터베이스 아키텍처
**수평 분할**은 데이터베이스 테이블의 행이 열로 분할되는 대신 (이는 정규화 및 수직 분할이 다른 정도로 수행하는 작업이다) 별도로 보관되는 데이터베이스 설계 원칙이다. 각 파티션은 샤드의 일부를 형성하며, 이는 다시 별도의 데이터베이스 서버 또는 물리적 위치에 있을 수 있다. 데이터의 수평 분할에는 수많은 이점이 있다. 테이블이 여러 서버로 나뉘어 분산되므로 각 데이터베이스의 각 테이블에 있는 총 행 수가 줄어든다. 이는 인덱스 크기를 줄여 일반적으로 검색 성능을 향상시킨다. 데이터베이스 샤드는 별도의 하드웨어에 배치될 수 있으며, 여러 샤드는 여러 머신에 배치될 수 있다. 이를 통해 데이터베이스를 많은 머신에 분산시켜 성능을 크게 향상시킬 수 있다. 또한 데이터베이스 샤드가 데이터의 실제 세분화(예: 유럽 고객 대 미국 고객)를 기반으로 하는 경우, 적절한 샤드 멤버십을 쉽고 자동으로 추론하고 관련 샤드만 쿼리할 수 있다.date=July 28, 2008 실제로 샤딩은 복잡하다. 오랫동안 수동 코딩(특히 위 고객 지역 예시와 같이 행이 명확한 그룹화를 가질 때)으로 수행되었지만, 이는 종종 유연하지 못하다. 샤딩에 대한 코드 지원 추가와 별도로 샤딩될 후보 식별 측면에서 샤딩을 자동으로 지원하려는 바람이 있다. 일관된 해싱은 대규모 부하를 여러 개의 작은 서비스 및 서버에 분산시키는 데 사용되는 샤딩 기술이다.url=http://www.startuplessonslearned.com/2009/01/sharding-for-startups.html 분산 컴퓨팅이 여러 서버 간에 부하를 분리하는 데 사용되는 경우(성능 또는 안정성 이유로), 샤드 접근 방식도 유용할 수 있다. 2010년대에는 실행 용량의 샤딩과 더 전통적인 데이터 샤딩이 블록체인의 성능 및 확장성 문제를 극복하기 위한 잠재적인 접근 방식으로 부상했다.s2cid=204749727s2cid=204749727 최근 학술 연구에서는 Cerberus와 같은 프로토콜을 제안하여 여러 샤드 간에 합의를 엮어 교차 샤드 원자성을 해결하고, 전역 잠금 없이 여러 파티션에 동시에 영향을 미치는 트랜잭션을 허용한다.doi=10.5070/SP24360340
# 단점
데이터베이스 테이블을 로컬에서 최적화하기 전에 샤딩하는 것은 성급한 복잡성을 유발한다. 샤딩은 다른 모든 최적화 옵션이 부적절할 때만 사용해야 한다. 데이터베이스 샤딩으로 인해 발생하는 복잡성은 다음과 같은 잠재적인 문제를 야기한다. * SQL 복잡성 - 개발자가 샤딩 로직을 처리하기 위해 더 복잡한 SQL을 작성해야 하므로 버그가 증가한다. * 추가 소프트웨어 - 분할, 균형 조정, 조정 및 무결성 보장을 담당하는 소프트웨어는 실패할 수 있다. * 단일 장애점 - 네트워크/하드웨어/시스템 문제로 인한 하나의 샤드 손상은 전체 테이블의 실패를 야기한다. * 페일오버 서버 복잡성 - 페일오버 서버는 데이터베이스 샤드 집합의 복사본을 가지고 있어야 한다. * 백업 복잡성 - 개별 샤드의 데이터베이스 백업은 다른 샤드의 백업과 조율되어야 한다. * 운영 복잡성 - 인덱스 추가/제거, 컬럼 추가/삭제, 스키마 수정이 훨씬 더 어려워진다.
# 어원
데이터베이스 맥락에서 대부분의 사람들은 "샤드"라는 용어가 다음 두 가지 출처 중 하나에서 유래했을 가능성이 높다고 인식한다. 컴퓨터 코퍼레이션 오브 아메리카의 "고가용성 복제 데이터 시스템(A System for Highly Available Replicated Data)"Sarin, DeWitt & Rosenberg, Overview of SHARD: A System for Highly Available Replicated Data, Technical Report CCA-88-01, Computer Corporation of America, May 1988은 데이터 복제를 용이하게 하기 위해 (수평 분할과는 대조적으로) 중복 하드웨어를 사용했다. 또는 1997년 MMORPG 비디오 게임 울티마 온라인에서 유래했다.access-date=2015-01-17 리처드 개리엇, 울티마 온라인의 제작자는 플레이어가 당시 혁명적인 기술이었던 새로운 인터넷 접근을 활용하여 게임 내 자원을 상호 작용하고 수확할 수 있도록 자체 규제 가상 생태계 시스템을 만들려 할 때 제작 단계에서 이 용어가 만들어졌다고 회상한다.date=21 December 2017 가상 생태계는 사내 테스트 중 의도한 대로 기능했지만, 플레이어가 플레이 가능한 지역 전체의 모든 야생 동물을 스폰 시스템이 작동할 수 있는 속도보다 빠르게 죽여 버렸기 때문에 자연 균형은 "거의 즉시" 무너졌다. 개리엇의 제작팀은 전 세계 플레이어 기반을 별도의 세션으로 분리하고, 울티마 온라인의 가상 세계가 울티마 I: 제1차 암흑기의 끝과 연결되는 부분을 다시 작성하여, 적대자 몬데인의 패배가 다중 우주 "샤드"의 생성을 이끌었다는 허구적인 연결을 제공함으로써 이 문제를 완화하려고 시도했다. 이 수정은 개리엇의 팀에게 가상 환경의 복사본을 생성할 정당성을 부여하는 허구적 기반을 제공했다. 그러나 게임이 비평가들의 극찬을 받으며 급증하면서 새로운 다중 우주 가상 생태계 시스템 또한 빠르게 압도되었다. 몇 달간의 테스트 끝에 개리엇의 팀은 이 기능을 완전히 포기하고 게임에서 그 기능을 제거하기로 결정했다. 오늘날 "샤드"라는 용어는 데이터베이스 시스템 전반에 걸쳐 중복 하드웨어를 배포하고 사용하는 것을 의미한다.
# 수평 분할과의 비교
수평 분할은 일반적으로 단일 스키마 인스턴스 및 데이터베이스 서버 내에서 하나 이상의 테이블을 행 단위로 분할한다. 이는 특정 행이 어떤 파티션에 있는지 인덱스를 먼저 검색할 필요 없이 명확하고 견고하며 암묵적인 방법으로 식별할 수 있다면(예: '`CustomersEast`' 및 '`CustomersWest`' 테이블의 고전적인 예에서 우편번호가 이미 어디에서 찾을 수 있는지 나타내는 경우) 인덱스 크기(따라서 검색 노력)를 줄여 이점을 제공할 수 있다. 샤딩은 이를 넘어선다. 동일한 방식으로 문제의 테이블을 분할하지만, 잠재적으로 여러 스키마 인스턴스에 걸쳐 이를 수행한다. 명백한 이점은 대규모 분할 테이블에 대한 검색 부하가 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버(논리적 또는 물리적)에 분할될 수 있다는 점이다. 여러 고립된 인스턴스에 샤드를 분할하는 것은 단순한 수평 분할 이상의 것을 요구한다. 데이터베이스를 쿼리할 때 간단한 차원 테이블을 검색하기 위해 여러 인스턴스를 쿼리해야 한다면 효율성 향상이라는 기대는 사라질 것이다. 따라서 분할 외에도 샤딩은 큰 분할 가능 테이블을 서버 전체에 분할하는 반면, 작은 테이블은 완전한 단위로 복제된다. 이것이 또한 샤딩이 셰어드-낫씽 아키텍처와 관련이 있는 이유이다. 일단 샤딩되면 각 샤드는 완전히 분리된 논리적 스키마 인스턴스 / 물리적 데이터베이스 서버 / 데이터 센터 / 대륙에 존재할 수 있다. 다른 샤드의 다른 분할되지 않은 테이블에 대한 공유 액세스(샤드 간)를 유지할 필요가 지속적으로 발생하지 않는다.quote=Database shards exemplify a shared-nothing architecture. This means that the shards are autonomous; they don't share any of the same data or resources. 이는 여러 서버에 걸친 복제를 쉽게 만든다(단순한 수평 분할은 그렇지 않다). 또한 데이터 센터 간 통신 링크가 병목 현상이 될 수 있는 전 세계 애플리케이션 배포에도 유용하다. 스키마 인스턴스 간에 일부 알림 및 복제 메커니즘도 필요하여, 분할되지 않은 테이블이 애플리케이션 요구 사항에 따라 최대한 동기화된 상태를 유지해야 한다. 이는 샤드 시스템 아키텍처에서 복잡한 선택이다. 접근 방식은 이러한 테이블을 사실상 읽기 전용으로 만드는 것(업데이트는 드물고 일괄 처리됨)부터 동적으로 복제되는 테이블(샤딩의 분산 이점 중 일부를 줄이는 대가로) 및 그 사이의 많은 옵션에 이른다.
# 저명한 구현체
* 아파치 HBase: 자동 샤딩을 제공한다.url=http://hbase.apache.org/ * Azure SQL Database Elastic Database toolsurl-status= * 카우치베이스 서버: 자동 투명 샤딩, 최고 성능 제공. * CUBRID: 버전 9.0부터 샤딩 지원 * 일래스틱서치url=http://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-allocation.html * eXtreme Scalehttp://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.over.doc%2url=http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.over.doc%2 * 하이버네이트 샤드date=2007-02-08url-status = dead * IBM 인포믹스url-status=deadurl=http://fr.slideshare.net/journalofinformix/informix-no-sql-sept-2013 * Kdb+: 버전 2.0부터 샤딩 지원 * MonetDBdate=31 August 2015 * 몽고DB: 버전 1.6부터 샤딩 지원 * MySQL 클러스터date=2012-11-23 * MySQL 패브릭 (MySQL 유틸리티의 일부)url-status = dead * 오라클 데이터베이스 샤딩http://www.oracle.com/technetwork/database/database-technologies/sharding/overview/index.html * 오라클 NoSQL 데이터베이스 * OrientDB: 버전 1.7부터 샤딩 지원 * Solr 엔터프라이즈 서치 서버url=http://wiki.apache.org/solr/DistributedSearch * Google Cloud Spanneraccessdate =24 February 2014 * SQLAlchemy ORMurl= http://www.sqlalchemy.org/trac/browser/examples/sharding/attribute_shard.py * The DWH of Teradata
# 내용주
group=notes