위키원
"샤드"의 두 판 사이의 차이
hangyuwon95 (토론 | 기여) (→참고자료) |
잔글 (92.118.234.18(토론)의 편집을 Asadal의 마지막 판으로 되돌림) |
||
| (사용자 3명의 중간 판 11개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | + | '''샤드'''(shard)란 [[샤딩]]을 통해 나누어진 블록들의 구간(혹은 Epoch)을 말한다. 샤드는 [[지분증명]]과 관련이 있는 것이 아니라 [[확장성]] 개선과 관련된 개념이다. [[샤딩]](sharding)의 아이디어는 가능한 계정(계약도 계정)의 공간을 숫자 주소의 첫 번째 숫자를 기준으로 하위 공간으로 분할하는 것이다. 샤드에 포함된 정보는 여전히 다른 [[노드]]와 공유할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다. | |
| + | |||
| + | ==어원== | ||
| + | [[데이터베이스]] 컨텍스트에서 "샤드"라는 용어는 다음 두 가지 소스 중 하나에서 파생될 가능성이 높다. Computer Corporation of America의 "고 가용성 복제 데이터 시스템" , 중복 하드웨어를 사용하여 데이터 복제를 용이하게 함 (수평 분할과는 대조적으로) 또는 비평가의 찬사를 받은 1997 년 MMORPG 비디오 게임 Ultima Online 은 기네스 세계 기록 8 개를 획득했으며 모든 시간 동안 제작된 100 대 비디오 게임 중 하나로 Time에 의해 지정되었다. | ||
| + | Ultima Online의 제작자인 Richard Garriott는 생산 단계에서 자체 규제 가상 생태 시스템을 만들려고 할 때 생성된 용어를 회상한다. 이를 통해 플레이어는 새로운 인터넷 액세스 (당시의 혁신적인 기술)를 활용하여 게임 자원. 사내 테스트에서 가상 생태가 의도 한대로 기능했지만, 플레이어가 산란 시스템이 작동할 수 있는 것보다 더 빠르게 재생 가능한 지역에서 살아있는 모든 야생 생물을 죽이는 것으로 인해 자연 균형이 "거의 즉시"실패했다. Garriott의 프로덕션 팀은 글로벌 플레이어 기반을 별도의 세션으로 분리하고 Ultima Online의 가상 연결 부분을 다시 작성하여 이 문제를 완화하려고 시도했다. 울티마 1 세 : 어둠의 첫 번째 시대. 길항제 몬 다인의 패배로 인해 다중 우주 "파편"이 만들어졌다. 이 수정 사항은 Garriott 팀에 가상 환경의 사본 작성을 정당화하는 데 필요한 가상의 기초를 제공했다. 그러나 이 게임이 비판적인 호평을 받으면서 새로운 다중 우주 가상 생태 시스템도 빠르게 압도되었다는 것을 의미했다. 몇 달간의 테스트 끝에 Garriott의 팀은 이 기능을 모두 포기하기로 결정하고 그 기능에 대한 게임을 제거했다. | ||
| + | 현재 "샤드"라는 용어는 데이터베이스 시스템에서 중복 하드웨어를 배포하고 사용하는 것을 말한다. | ||
| + | |||
==특징== | ==특징== | ||
| − | *각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 | + | *각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 요소임) 이러한 유효성 검사기는 일반적으로 모든 샤드의 유효성을 검사할 필요는 없다. |
*동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동한다. | *동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동한다. | ||
| − | *여러 샤드를 통해 | + | *여러 샤드를 통해 통신하고자 하는 계약은 거래 수령 개념에 따라 특별한 기술을 사용해야 한다. 계약을 직접 호출하고 영수증을 확인하는 것의 중요한 차이점은 직접 전화를 하려면 호출하는 계약 코드를 실행해야 하지만 영수증을 확인하려면 다른 방법으로는 영수증을 만들 수 없다는 것만 확인하면 된다. |
| − | *샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 | + | *샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 않아도 되기 때문에 Ethereum을 확장할 수 있다. |
| − | *샤드에 | + | *샤드에 포함된 정보는 여전히 다른 노드와 공유할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다. |
| − | ===수평 분할과 | + | |
| − | 수평 파티셔닝 은 일반적으로 스키마 및 데이터베이스 | + | ===수평 분할과 비교한 샤드=== |
| − | 샤딩 ( | + | 수평 파티셔닝 은 일반적으로 스키마 및 데이터베이스 서버의 단일 인스턴스 내에서 하나 이상의 테이블을 행별로 분할 한다. 인덱스를 먼저 검색할 필요 없이 특정 행음 찾을 파티션을 식별할 수 있는 명확하고 강력하며 암시적인 방법이 있는 경우 인덱스 크기를 줄임으로써 (따라서 검색 노력) 이점을 제공할 수 있다. ' '및 ' '테이블의 예. 우편 번호는 이미 찾을 위치를 나타낸다. |
| − | 따라서 여러 서버에서 쉽게 | + | |
| − | 또한 분할되지 않은 테이블이 응용 프로그램의 요구에 따라 밀접하게 동기화되도록 스키마 | + | 샤딩(shading)은 문제를 뛰어넘는다. 문제가 있는 테이블을 같은 방식으로 분할하지만 잠재적으로 여러 스키마 인스턴스에서 이를 수행한다. 큰 분할된 테이블에 대한 검색 로드를 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버 (논리적 또는 물리적)로 나눌 수 있다는 것이 명백한 이점이다. 여러 개의 격리된 인스턴스에서 샤드를 분할하려면 단순한 수평 분할 이상이 필요하다. 데이터베이스를 쿼리 할 때 단순한 차원 테이블 만 검색하기 위해 두 인스턴스를 모두 쿼리 해야 하는 경우 효율성의 기대치가 사라 진다. 분할 외에도 샤딩은 서버에서 분할 가능한 큰 테이블을 분할하는 반면 작은 테이블은 완전한 단위로 복제된다. 이것이 또한 샤딩이 공유 비 아키텍처와 관련이 있는 이유이다. 일단 샤드되면 각 샤드는 완전히 별도의 논리적 스키마 인스턴스 / 물리적 데이터베이스 서버 / 데이터 센터 / 대륙에 살 수 있다. 샤드 사이에서 다른 샤드의 다른 파티션 되지 않은 테이블에 대한 공유 액세스를 계속 유지할 필요가 없다. |
| + | |||
| + | 따라서 여러 서버에서 쉽게 복제할 수 있다. (간단한 수평 분할은 불가능). 또한 데이터 센터 간의 통신 링크가 병목 현상이 발생하는 전 세계 응용 프로그램 배포에 유용하다. | ||
| + | 또한 분할되지 않은 테이블이 응용 프로그램의 요구에 따라 밀접하게 동기화되도록 스키마 인스턴스 간에 일부 알림 및 복제 메커니즘이 필요하다. 이는 샤드 시스템 아키텍처에서 복잡한 선택이다. 접근 방식은 효과적으로 읽기 전용 (업데이트는 드물고 배치됨), 동적으로 복제된 테이블 (샤딩의 일부 분배 이점을 줄임) 및 다양한 옵션에 이르기까지 다양하다. | ||
| + | |||
===데이터베이스 아키텍처=== | ===데이터베이스 아키텍처=== | ||
| − | 수평 파티셔닝은 데이터베이스 테이블의 행 이 열로 분할되지 않고 개별적으로 | + | 수평 파티셔닝은 데이터베이스 테이블의 행 이 열로 분할되지 않고 개별적으로 유지되는 데이터베이스 설계 원칙이다. ( 정규화 및 수직 파티셔닝이 수행하는 범위가 다르다). 각 파티션은 샤드의 일부를 형성하며 ,이 파티션 은 별도의 데이터베이스 서버 또는 물리적 위치에 있을 수 있다. |
| − | 수평 분할 방식에는 여러 가지 장점이 있다. 테이블이 여러 서버로 분할되어 분산되므로 각 데이터베이스의 각 | + | 수평 분할 방식에는 여러 가지 장점이 있다. 테이블이 여러 서버로 분할되어 분산되므로 각 데이터베이스의 각 테이블에 있는 총 행 수가 줄어듭니다. 이렇게 하면 인덱스 크기가 줄어들어 일반적으로 검색 성능이 향상된다. 데이터베이스 샤드는 별도의 하드웨어에 배치할 수 있으며 여러 샤드는 여러 시스템에 배치할 수 있다. 이를 통해 많은 수의 컴퓨터에 데이터베이스를 배포할 수 있으므로 성능이 크게 향상된다. 또한 데이터베이스 샤드가 데이터의 실제 세그먼테이션 (예 : 유럽 고객 대 미국 고객)을 기반으로 하는 경우 적절한 샤드 멤버십을 쉽고 자동으로 추론하고 관련 샤드 만 쿼리 할 수 있다. |
==활용== | ==활용== | ||
| − | *[[Devvio]]의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 | + | *[[Devvio]]의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 처리할 수 있다고 주장한다. 예를 들어, 각 샤드는 최대 3,000 개의 트랜잭션을 처리할 수 있는 Devv 분산 원장의 독립적인 블록체인 노드이다. Devvio CEO Tom Anderson에 따르면 다른 노드를 추가하면 처리할 수 있는 트랜잭션 수가 두 배가 된다. |
| − | 각 샤드 (암호 지갑이기도 함)는 더 큰 네트워크에서 | + | 각 샤드 (암호 지갑이기도 함)는 더 큰 네트워크에서 입력이 되고 Devvio는 T1 네트워크를 호출한다. 개별 샤드는 T2라는 별도의 트랜잭션 네트워크를 통해 다른 사람과 통신할 수 있다. |
| − | *유효성 검사기 파티셔닝 및 | + | |
| − | + | *유효성 검사기 파티셔닝 및 [[비콘체인]] | |
| − | + | 첫번째 과제는 각 샤드에 자체 유효성 검사기가 있으면 각 샤드가 전체 체인보다 10배 덜 안전하다는 것이다. 따라서 X 검증자가 있는 비샤드체인이 샤드체인으로 하드 포크를 하고 10 개의 샤드로 X 검증자를 분할하면 각 샤드에는 X / 10 검증 기가 있고 하나의 샤드가 손상되면 5.1 %만 손상하면 된다. | |
| + | |||
| + | (51%) / 10) 총 유효성 검사기 수 | ||
| + | |||
| + | 두번째 요점은 다음과 같다. "누가 각 샤드에 대해 유효성 검사기를 선택할까? "이다. 유효성 검사기의 5.1 %를 제어하는 것은 유효성 검사기의 5.1 % 가 모두 동일한 샤드에 있는 경우에만 피해를 준다. 검증자가 검증할 샤드를 선택할 수 없는 경우, 검증 자의 5.1 %를 제어하는 참가자는 모든 검증자를 동일한 샤드에 넣을 가능성이 거의 없으므로 시스템을 손상시킬 수 있는 능력이 크게 줄어든다. | ||
| + | |||
*크로스 샤드 거래 | *크로스 샤드 거래 | ||
| − | 모델로서의 | + | 모델로서의 [[빈스토크]](Beanstalk)는 샤딩에 매우 유용한 접근 방식이 아니다. 개별 샤드가 서로 통신할 수 없는 경우 여러 개의 독립적인 블록체인보다 낫지 않기 때문이다. 오늘날에도 샤딩을 사용할 수 없는 경우 다양한 블록체인만에 상호 운용성이 요구된다. |
| − | 각 참가자가 정확히 하나의 샤드를 차지하는 간단한 결제 거래 만 고려해 보자. 동일한 샤드 내에서 한 계정에서 다른 계정으로 돈을 이체하려는 경우 해당 샤드의 유효성 검증자가 트랜잭션을 완전히 | + | 각 참가자가 정확히 하나의 샤드를 차지하는 간단한 결제 거래 만 고려해 보자. 동일한 샤드 내에서 한 계정에서 다른 계정으로 돈을 이체하려는 경우 해당 샤드의 유효성 검증자가 트랜잭션을 완전히 처리할 수 있다. 그러나 샤드 # 1에 있는 Alice가 샤드 # 2에 있는 Bob에게 돈을 보내려면 샤드 # 1의 유효성 검사자 (Bob의 계정을 신용 할 수 없음) 나 샤드 # 2의 유효성 검사기 ( Alice의 계정에서 인출할 수 없음) 전체 거래를 처리할 수 있다. |
| + | |||
크로스 샤드 트랜잭션에 대한 두 가지 접근 방식이 있다. | 크로스 샤드 트랜잭션에 대한 두 가지 접근 방식이 있다. | ||
| − | 동기식 : 크로스 샤드 트랜잭션을 실행해야 할 때마다 트랜잭션과 관련된 상태 전이가 | + | * 동기식 : 크로스 샤드 트랜잭션을 실행해야 할 때마다 트랜잭션과 관련된 상태 전이가 포함된 여러 샤드의 블록이 동시에 생성되며 여러 샤드의 유효성 검사기가 이러한 트랜잭션을 실행하기 위해 협업한다. 나에게 알려진 가장 상세한 제안은 여기에 설명된 병합 블록이다. |
| − | + | ||
| + | * 비동기식 : 여러 샤드에 영향을 미치는 크로스 샤드 트랜잭션은 해당 샤드에서 비동기 적으로 실행된다.“신용”샤드는“직불”샤드가 그 부분을 실행했다는 충분한 증거가 있으면 절반을 실행한다. 이 접근 방식은 단순성과 조정 용이성으로 인해 더 널리 사용되는 경향이 있다. 이 시스템은 오늘 [[코스모스코인]], [[이더리움]] 세레니티, 니어, 카데나 등에서 제안된다. 이 접근법의 문제점은 블록이 독립적으로 생성되는 경우 여러 블록 중 하나가 분리될 가능성이 0이 아니므로 트랜잭션이 부분적으로 만 적용된다는 것이다. 포크와 마주친 두 개의 샤드와 그에 따라 블록 A와 X '에 기록된 크로스 샤드 트랜잭션을 나타내는 아래 그림을 고려하십시오. 체인 AB와 V'-X'-Y'-Z '가 해당 샤드에서 정식인 경우, 거래가 완료되었다. A'-B'-C'-D '및 VX가 정식이 되면 트랜잭션이 완전히 포기되므로 허용된다. 그러나 예를 들어 AB와 VX가 정식이 되면 트랜잭션의 한 부분이 완료되고 한 부분이 중단되어 원 자성 오류가 발생한다. 우리는 샤드 프로토콜에 제안된 포크 선택 규칙과 합의 알고리즘에 대한 변경 사항을 다룰 때 두 번째 부분에서 제안된 프로토콜에서 이 문제가 어떻게 해결되는지 다룰 것이다. | ||
| + | |||
*Altibase : 클라이언트 애플리케이션에 투명한 조합 (클라이언트 측 및 서버 측) 샤딩 아키텍처를 제공한다. | *Altibase : 클라이언트 애플리케이션에 투명한 조합 (클라이언트 측 및 서버 측) 샤딩 아키텍처를 제공한다. | ||
| − | *Apache HBase : | + | *Apache HBase : HBase는 자동 샤딩을 제공한다. |
| − | *Azure SQL Database Elastic Database 도구 : 응용 프로그램의 데이터 계층이 업계 표준 샤딩 사례를 통해 | + | *Azure SQL Database Elastic Database 도구 : 응용 프로그램의 데이터 계층이 업계 표준 샤딩 사례를 통해 확장할 수 있다. |
*Couchbase : 자동 투명 샤딩 및 최고의 성능을 제공한다. | *Couchbase : 자동 투명 샤딩 및 최고의 성능을 제공한다. | ||
*CUBRID : 버전 9.0에서 샤딩 허용 | *CUBRID : 버전 9.0에서 샤딩 허용 | ||
*Elasticsearch : 엔터프라이즈 검색 서버는 샤딩 기능을 제공한다. | *Elasticsearch : 엔터프라이즈 검색 서버는 샤딩 기능을 제공한다. | ||
| − | *eXtreme Scale : 크로스 | + | *eXtreme Scale : 크로스 프로세스인 메모리 키 / 값 데이터 저장소 (다양한 NoSQL 데이터 저장소). 샤딩을 사용하여 데이터 및 MapReduce 스타일 병렬 처리에 대한 프로세스 전체의 확장 성을 달성한다. |
*최대 절전 모드 샤드 : 2007 년 이후 활동이 거의 없었지만 샤드를 제공한다. | *최대 절전 모드 샤드 : 2007 년 이후 활동이 거의 없었지만 샤드를 제공한다. | ||
| − | *IBM Informix : IBM 은 MACH11 기술의 일부로 버전 12.1 xC1 이후 | + | *IBM Informix : IBM 은 MACH11 기술의 일부로 버전 12.1 xC1 이후 Informix에서 샤딩을 허용했다. Informix 12.10 xC2는 MongoDB 드라이버와의 완전한 호환성을 추가하여 NoSQL 컬렉션과 일반 관계형 테이블을 혼합하면서 샤딩, 페일 오버 및 ACID 특성을 계속 허용한다. |
*Kdb + : 버전 2.0에서 샤딩을 허용한다. | *Kdb + : 버전 2.0에서 샤딩을 허용한다. | ||
| − | *MonetDB : 오픈 소스 열 저장소 | + | *MonetDB : 오픈 소스 열 저장소 MonetDB는 2015 년 7 월 릴리스로 읽기 전용 샤딩을 허용한다. |
*MongoDB : 버전 1.6에서 샤딩을 허용한다. | *MongoDB : 버전 1.6에서 샤딩을 허용한다. | ||
| − | *MySQL 클러스터 : 자동 샤딩 : 데이터베이스는 저렴한 범용 노드에서 자동으로 투명하게 분할되므로 애플리케이션을 변경하지 않고도 읽기 및 쓰기 쿼리를 | + | *MySQL 클러스터 : 자동 샤딩 : 데이터베이스는 저렴한 범용 노드에서 자동으로 투명하게 분할되므로 애플리케이션을 변경하지 않고도 읽기 및 쓰기 쿼리를 확장할 수 있다. |
*MySQL Fabric (MySQL 유틸리티의 일부)에는 샤딩 기능이 포함되어 있다. | *MySQL Fabric (MySQL 유틸리티의 일부)에는 샤딩 기능이 포함되어 있다. | ||
| − | *Oracle Database Sharding : Oracle RDBMS12c Release 2 및 하나의 라이너에 새로운 기능으로 도입되었다. Sharding은 | + | *Oracle Database Sharding : Oracle RDBMS12c Release 2 및 하나의 라이너에 새로운 기능으로 도입되었다. Sharding은 독립적인 데이터베이스 간에 데이터를 수평으로 분할하는 데이터 계층 아키텍처이다. |
*Oracle NoSQL Database : 클러스터의 자동 샤딩 및 온라인 확장 기능 (샤드 추가)이 있다. | *Oracle NoSQL Database : 클러스터의 자동 샤딩 및 온라인 확장 기능 (샤드 추가)이 있다. | ||
*OrientDB : 버전 1.7에서 샤딩 허용 | *OrientDB : 버전 1.7에서 샤딩 허용 | ||
*Solr 엔터프라이즈 검색 서버 : 샤딩 기능을 제공한다. | *Solr 엔터프라이즈 검색 서버 : 샤딩 기능을 제공한다. | ||
| − | *스패너 : Google의 글로벌 규모의 분산 데이터베이스로, 여러 Paxos 상태 머신에 걸쳐 데이터를 | + | *스패너 : Google의 글로벌 규모의 분산 데이터베이스로, 여러 Paxos 상태 머신에 걸쳐 데이터를 분할하여 "수백 개의 데이터 센터와 수십억 개의 데이터베이스 행에 걸쳐 수백만 개의 머신"으로 확장한다. |
*SQLAlchemy ORM : 샤딩 기능을 제공하는 Python 프로그래밍 언어의 데이터 맵퍼. | *SQLAlchemy ORM : 샤딩 기능을 제공하는 Python 프로그래밍 언어의 데이터 맵퍼. | ||
*Teradata의 DWH : 대규모 병렬 데이터베이스 | *Teradata의 DWH : 대규모 병렬 데이터베이스 | ||
| − | *Vault : 사용자가 네트워크에 가입하고 거래를 확인하는 데 필요한 데이터를 대폭 감소시키는 암호 | + | *Vault : 사용자가 네트워크에 가입하고 거래를 확인하는 데 필요한 데이터를 대폭 감소시키는 암호 화폐입니다. 이것은 훨씬 확장 가능한 네트워크로 변환됩니다. MIT 연구원이 설계했다. 샤딩은 그 기능의 중심이다.<ref>알렉산더 스키 다 노프, 〈[https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060 블록체인 샤딩에 대한 권위있는 가이드, 1 부]〉, 《미디움》, 2018-12-06</ref><ref>〈[https://en.wikipedia.org/wiki/Shard_(database_architecture) 샤드]〉, 《위키피디아》</ref> |
| − | 알렉산더 스키 다 노프 | ||
| − | , 〈[https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060 | ||
| − | 〈[https://en.wikipedia.org/wiki/Shard_(database_architecture) 샤드]〉, 《위키피디아》</ref> | ||
==단점== | ==단점== | ||
| − | 로컬로 최적화되기 전에 데이터베이스 테이블을 | + | 로컬로 최적화되기 전에 데이터베이스 테이블을 쉐딩 하면 조기 복잡성이 발생한다. 샤딩은 최적화를 위한 다른 모든 옵션이 부적합한 경우에만 사용해야 합니다. 데이터베이스 샤딩의 도입된 복잡성으로 인해 다음과 같은 잠재적인 문제가 발생한다. |
| − | *SQL의 복잡성 증가 -개발자가 샤딩 논리를 처리하기 위해 더 복잡한 SQL을 | + | |
| + | *SQL의 복잡성 증가 -개발자가 샤딩 논리를 처리하기 위해 더 복잡한 SQL을 작성해야 하기 때문에 버그가 증가했다. | ||
*샤딩은 복잡성을 소개합니다 -분할, 균형 조정, 조정 및 무결성 실패를 보장하는 샤딩 소프트웨어. | *샤딩은 복잡성을 소개합니다 -분할, 균형 조정, 조정 및 무결성 실패를 보장하는 샤딩 소프트웨어. | ||
*단일 실패 지점 -네트워크 / 하드웨어 / 시스템 문제로 인해 하나의 샤드가 손상되면 전체 테이블이 실패한다. | *단일 실패 지점 -네트워크 / 하드웨어 / 시스템 문제로 인해 하나의 샤드가 손상되면 전체 테이블이 실패한다. | ||
*보다 복잡한 장애 조치 서버-장애 조치 서버 자체에는 데이터베이스 샤드 집합의 사본이 있어야 한다. | *보다 복잡한 장애 조치 서버-장애 조치 서버 자체에는 데이터베이스 샤드 집합의 사본이 있어야 한다. | ||
| − | *보다 복잡한 백업 -개별 샤드의 데이터베이스 백업은 다른 샤드의 백업과 | + | *보다 복잡한 백업 -개별 샤드의 데이터베이스 백업은 다른 샤드의 백업과 조정되어야 한다. |
| − | *운영상의 복잡성 추가 -인덱스 추가 / 제거, 열 추가 / 삭제, 스키마 수정이 훨씬 더 | + | *운영상의 복잡성 추가 -인덱스 추가 / 제거, 열 추가 / 삭제, 스키마 수정이 훨씬 더 어려워진다. |
자체 샤딩의 이러한 복잡한 문제는 자동 샤딩을 제공 한 독립 소프트웨어 공급 업체가 해결했다. | 자체 샤딩의 이러한 복잡한 문제는 자동 샤딩을 제공 한 독립 소프트웨어 공급 업체가 해결했다. | ||
| − | |||
| − | |||
| − | |||
| − | |||
==전망== | ==전망== | ||
| − | 오늘날 얼마나 많은 샤드를 사용할 수 있는지에 대한 정확한 측정을 제공하기는 어렵지만, 예측 가능한 미래에 | + | 오늘날 얼마나 많은 샤드를 사용할 수 있는지에 대한 정확한 측정을 제공하기는 어렵지만, 예측 가능한 미래에 블록체인 사용자의 처리량 요구가 2 차 샤딩의 한계를 넘어설 가능성은 거의 없다. 이러한 양의 샤드를 안전하게 운영하는 데 필요한 수많은 노드는 오늘날 결합된 모든 블록체인을 운영하는 노드의 수보다 훨씬 높다. 그러나 미래의 증거 프로토콜을 구축하려는 경우 오늘날이 문제에 대한 솔루션을 연구하는 것이 좋다. 현재 가장 발전된 제안은 지수 샤딩으로, 샤드 자체가 나무를 형성하고 있으며 각 상위 샤드는 일련의 하위 샤드를 조율하는 반면 자체는 다른 샤드의 하위가 될 수 있다. |
| + | |||
{{각주}} | {{각주}} | ||
==참고자료== | ==참고자료== | ||
| − | *알렉산더 스키 다 노프, 〈[https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060 | + | * 알렉산더 스키 다 노프, 〈[https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060 블록체인 샤딩에 대한 권위있는 가이드, 1 부]〉, 《미디엄》, 2018-12-06 |
| − | * | + | * 〈[https://en.wikipedia.org/wiki/Shard_(database_architecture) 샤드]〉, 《위키피디아》 |
| + | |||
| + | == 같이 보기 == | ||
| + | * [[샤딩]] | ||
| + | |||
| + | {{블록체인 기술|검토 필요}} | ||
2020년 7월 15일 (수) 20:45 기준 최신판
샤드(shard)란 샤딩을 통해 나누어진 블록들의 구간(혹은 Epoch)을 말한다. 샤드는 지분증명과 관련이 있는 것이 아니라 확장성 개선과 관련된 개념이다. 샤딩(sharding)의 아이디어는 가능한 계정(계약도 계정)의 공간을 숫자 주소의 첫 번째 숫자를 기준으로 하위 공간으로 분할하는 것이다. 샤드에 포함된 정보는 여전히 다른 노드와 공유할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
어원[편집]
데이터베이스 컨텍스트에서 "샤드"라는 용어는 다음 두 가지 소스 중 하나에서 파생될 가능성이 높다. Computer Corporation of America의 "고 가용성 복제 데이터 시스템" , 중복 하드웨어를 사용하여 데이터 복제를 용이하게 함 (수평 분할과는 대조적으로) 또는 비평가의 찬사를 받은 1997 년 MMORPG 비디오 게임 Ultima Online 은 기네스 세계 기록 8 개를 획득했으며 모든 시간 동안 제작된 100 대 비디오 게임 중 하나로 Time에 의해 지정되었다. Ultima Online의 제작자인 Richard Garriott는 생산 단계에서 자체 규제 가상 생태 시스템을 만들려고 할 때 생성된 용어를 회상한다. 이를 통해 플레이어는 새로운 인터넷 액세스 (당시의 혁신적인 기술)를 활용하여 게임 자원. 사내 테스트에서 가상 생태가 의도 한대로 기능했지만, 플레이어가 산란 시스템이 작동할 수 있는 것보다 더 빠르게 재생 가능한 지역에서 살아있는 모든 야생 생물을 죽이는 것으로 인해 자연 균형이 "거의 즉시"실패했다. Garriott의 프로덕션 팀은 글로벌 플레이어 기반을 별도의 세션으로 분리하고 Ultima Online의 가상 연결 부분을 다시 작성하여 이 문제를 완화하려고 시도했다. 울티마 1 세 : 어둠의 첫 번째 시대. 길항제 몬 다인의 패배로 인해 다중 우주 "파편"이 만들어졌다. 이 수정 사항은 Garriott 팀에 가상 환경의 사본 작성을 정당화하는 데 필요한 가상의 기초를 제공했다. 그러나 이 게임이 비판적인 호평을 받으면서 새로운 다중 우주 가상 생태 시스템도 빠르게 압도되었다는 것을 의미했다. 몇 달간의 테스트 끝에 Garriott의 팀은 이 기능을 모두 포기하기로 결정하고 그 기능에 대한 게임을 제거했다. 현재 "샤드"라는 용어는 데이터베이스 시스템에서 중복 하드웨어를 배포하고 사용하는 것을 말한다.
특징[편집]
- 각 샤드는 고유 한 유효성 검사기 집합을 얻으므로 (따라서 PoS는 필수 구성 요소임) 이러한 유효성 검사기는 일반적으로 모든 샤드의 유효성을 검사할 필요는 없다.
- 동일한 샤드 내 계정 간의 메시지 (트랜잭션)는 오늘날과 같은 방식으로 작동한다.
- 여러 샤드를 통해 통신하고자 하는 계약은 거래 수령 개념에 따라 특별한 기술을 사용해야 한다. 계약을 직접 호출하고 영수증을 확인하는 것의 중요한 차이점은 직접 전화를 하려면 호출하는 계약 코드를 실행해야 하지만 영수증을 확인하려면 다른 방법으로는 영수증을 만들 수 없다는 것만 확인하면 된다.
- 샤딩은 네트워크의 모든 노드가 모든 트랜잭션을 실행하지 않아도 되기 때문에 Ethereum을 확장할 수 있다.
- 샤드에 포함된 정보는 여전히 다른 노드와 공유할 수 있으며, 모든 사람이 여전히 모든 원장 항목을 볼 수 있기 때문에 원장을 분산하고 안전하게 유지할 수 있다. 그들은 단지 모든 정보를 처리하고 저장하지 않는다.
수평 분할과 비교한 샤드[편집]
수평 파티셔닝 은 일반적으로 스키마 및 데이터베이스 서버의 단일 인스턴스 내에서 하나 이상의 테이블을 행별로 분할 한다. 인덱스를 먼저 검색할 필요 없이 특정 행음 찾을 파티션을 식별할 수 있는 명확하고 강력하며 암시적인 방법이 있는 경우 인덱스 크기를 줄임으로써 (따라서 검색 노력) 이점을 제공할 수 있다. ' '및 ' '테이블의 예. 우편 번호는 이미 찾을 위치를 나타낸다.
샤딩(shading)은 문제를 뛰어넘는다. 문제가 있는 테이블을 같은 방식으로 분할하지만 잠재적으로 여러 스키마 인스턴스에서 이를 수행한다. 큰 분할된 테이블에 대한 검색 로드를 이제 동일한 논리 서버의 여러 인덱스뿐만 아니라 여러 서버 (논리적 또는 물리적)로 나눌 수 있다는 것이 명백한 이점이다. 여러 개의 격리된 인스턴스에서 샤드를 분할하려면 단순한 수평 분할 이상이 필요하다. 데이터베이스를 쿼리 할 때 단순한 차원 테이블 만 검색하기 위해 두 인스턴스를 모두 쿼리 해야 하는 경우 효율성의 기대치가 사라 진다. 분할 외에도 샤딩은 서버에서 분할 가능한 큰 테이블을 분할하는 반면 작은 테이블은 완전한 단위로 복제된다. 이것이 또한 샤딩이 공유 비 아키텍처와 관련이 있는 이유이다. 일단 샤드되면 각 샤드는 완전히 별도의 논리적 스키마 인스턴스 / 물리적 데이터베이스 서버 / 데이터 센터 / 대륙에 살 수 있다. 샤드 사이에서 다른 샤드의 다른 파티션 되지 않은 테이블에 대한 공유 액세스를 계속 유지할 필요가 없다.
따라서 여러 서버에서 쉽게 복제할 수 있다. (간단한 수평 분할은 불가능). 또한 데이터 센터 간의 통신 링크가 병목 현상이 발생하는 전 세계 응용 프로그램 배포에 유용하다. 또한 분할되지 않은 테이블이 응용 프로그램의 요구에 따라 밀접하게 동기화되도록 스키마 인스턴스 간에 일부 알림 및 복제 메커니즘이 필요하다. 이는 샤드 시스템 아키텍처에서 복잡한 선택이다. 접근 방식은 효과적으로 읽기 전용 (업데이트는 드물고 배치됨), 동적으로 복제된 테이블 (샤딩의 일부 분배 이점을 줄임) 및 다양한 옵션에 이르기까지 다양하다.
데이터베이스 아키텍처[편집]
수평 파티셔닝은 데이터베이스 테이블의 행 이 열로 분할되지 않고 개별적으로 유지되는 데이터베이스 설계 원칙이다. ( 정규화 및 수직 파티셔닝이 수행하는 범위가 다르다). 각 파티션은 샤드의 일부를 형성하며 ,이 파티션 은 별도의 데이터베이스 서버 또는 물리적 위치에 있을 수 있다. 수평 분할 방식에는 여러 가지 장점이 있다. 테이블이 여러 서버로 분할되어 분산되므로 각 데이터베이스의 각 테이블에 있는 총 행 수가 줄어듭니다. 이렇게 하면 인덱스 크기가 줄어들어 일반적으로 검색 성능이 향상된다. 데이터베이스 샤드는 별도의 하드웨어에 배치할 수 있으며 여러 샤드는 여러 시스템에 배치할 수 있다. 이를 통해 많은 수의 컴퓨터에 데이터베이스를 배포할 수 있으므로 성능이 크게 향상된다. 또한 데이터베이스 샤드가 데이터의 실제 세그먼테이션 (예 : 유럽 고객 대 미국 고객)을 기반으로 하는 경우 적절한 샤드 멤버십을 쉽고 자동으로 추론하고 관련 샤드 만 쿼리 할 수 있다.
활용[편집]
- Devvio의 "Devv"프로토콜에서 각 샤드는 별도의 블록체인 원장을 나타낸다. 이 회사는 시간이 지남에 따라 수천 개의 샤드를 글로벌 퍼블릭 블록체인에 추가하여 궁극적으로 초당 수천만 건의 트랜잭션을 처리할 수 있다고 주장한다. 예를 들어, 각 샤드는 최대 3,000 개의 트랜잭션을 처리할 수 있는 Devv 분산 원장의 독립적인 블록체인 노드이다. Devvio CEO Tom Anderson에 따르면 다른 노드를 추가하면 처리할 수 있는 트랜잭션 수가 두 배가 된다.
각 샤드 (암호 지갑이기도 함)는 더 큰 네트워크에서 입력이 되고 Devvio는 T1 네트워크를 호출한다. 개별 샤드는 T2라는 별도의 트랜잭션 네트워크를 통해 다른 사람과 통신할 수 있다.
- 유효성 검사기 파티셔닝 및 비콘체인
첫번째 과제는 각 샤드에 자체 유효성 검사기가 있으면 각 샤드가 전체 체인보다 10배 덜 안전하다는 것이다. 따라서 X 검증자가 있는 비샤드체인이 샤드체인으로 하드 포크를 하고 10 개의 샤드로 X 검증자를 분할하면 각 샤드에는 X / 10 검증 기가 있고 하나의 샤드가 손상되면 5.1 %만 손상하면 된다.
(51%) / 10) 총 유효성 검사기 수
두번째 요점은 다음과 같다. "누가 각 샤드에 대해 유효성 검사기를 선택할까? "이다. 유효성 검사기의 5.1 %를 제어하는 것은 유효성 검사기의 5.1 % 가 모두 동일한 샤드에 있는 경우에만 피해를 준다. 검증자가 검증할 샤드를 선택할 수 없는 경우, 검증 자의 5.1 %를 제어하는 참가자는 모든 검증자를 동일한 샤드에 넣을 가능성이 거의 없으므로 시스템을 손상시킬 수 있는 능력이 크게 줄어든다.
- 크로스 샤드 거래
모델로서의 빈스토크(Beanstalk)는 샤딩에 매우 유용한 접근 방식이 아니다. 개별 샤드가 서로 통신할 수 없는 경우 여러 개의 독립적인 블록체인보다 낫지 않기 때문이다. 오늘날에도 샤딩을 사용할 수 없는 경우 다양한 블록체인만에 상호 운용성이 요구된다. 각 참가자가 정확히 하나의 샤드를 차지하는 간단한 결제 거래 만 고려해 보자. 동일한 샤드 내에서 한 계정에서 다른 계정으로 돈을 이체하려는 경우 해당 샤드의 유효성 검증자가 트랜잭션을 완전히 처리할 수 있다. 그러나 샤드 # 1에 있는 Alice가 샤드 # 2에 있는 Bob에게 돈을 보내려면 샤드 # 1의 유효성 검사자 (Bob의 계정을 신용 할 수 없음) 나 샤드 # 2의 유효성 검사기 ( Alice의 계정에서 인출할 수 없음) 전체 거래를 처리할 수 있다.
크로스 샤드 트랜잭션에 대한 두 가지 접근 방식이 있다.
- 동기식 : 크로스 샤드 트랜잭션을 실행해야 할 때마다 트랜잭션과 관련된 상태 전이가 포함된 여러 샤드의 블록이 동시에 생성되며 여러 샤드의 유효성 검사기가 이러한 트랜잭션을 실행하기 위해 협업한다. 나에게 알려진 가장 상세한 제안은 여기에 설명된 병합 블록이다.
- 비동기식 : 여러 샤드에 영향을 미치는 크로스 샤드 트랜잭션은 해당 샤드에서 비동기 적으로 실행된다.“신용”샤드는“직불”샤드가 그 부분을 실행했다는 충분한 증거가 있으면 절반을 실행한다. 이 접근 방식은 단순성과 조정 용이성으로 인해 더 널리 사용되는 경향이 있다. 이 시스템은 오늘 코스모스코인, 이더리움 세레니티, 니어, 카데나 등에서 제안된다. 이 접근법의 문제점은 블록이 독립적으로 생성되는 경우 여러 블록 중 하나가 분리될 가능성이 0이 아니므로 트랜잭션이 부분적으로 만 적용된다는 것이다. 포크와 마주친 두 개의 샤드와 그에 따라 블록 A와 X '에 기록된 크로스 샤드 트랜잭션을 나타내는 아래 그림을 고려하십시오. 체인 AB와 V'-X'-Y'-Z '가 해당 샤드에서 정식인 경우, 거래가 완료되었다. A'-B'-C'-D '및 VX가 정식이 되면 트랜잭션이 완전히 포기되므로 허용된다. 그러나 예를 들어 AB와 VX가 정식이 되면 트랜잭션의 한 부분이 완료되고 한 부분이 중단되어 원 자성 오류가 발생한다. 우리는 샤드 프로토콜에 제안된 포크 선택 규칙과 합의 알고리즘에 대한 변경 사항을 다룰 때 두 번째 부분에서 제안된 프로토콜에서 이 문제가 어떻게 해결되는지 다룰 것이다.
- Altibase : 클라이언트 애플리케이션에 투명한 조합 (클라이언트 측 및 서버 측) 샤딩 아키텍처를 제공한다.
- Apache HBase : HBase는 자동 샤딩을 제공한다.
- Azure SQL Database Elastic Database 도구 : 응용 프로그램의 데이터 계층이 업계 표준 샤딩 사례를 통해 확장할 수 있다.
- Couchbase : 자동 투명 샤딩 및 최고의 성능을 제공한다.
- CUBRID : 버전 9.0에서 샤딩 허용
- Elasticsearch : 엔터프라이즈 검색 서버는 샤딩 기능을 제공한다.
- eXtreme Scale : 크로스 프로세스인 메모리 키 / 값 데이터 저장소 (다양한 NoSQL 데이터 저장소). 샤딩을 사용하여 데이터 및 MapReduce 스타일 병렬 처리에 대한 프로세스 전체의 확장 성을 달성한다.
- 최대 절전 모드 샤드 : 2007 년 이후 활동이 거의 없었지만 샤드를 제공한다.
- IBM Informix : IBM 은 MACH11 기술의 일부로 버전 12.1 xC1 이후 Informix에서 샤딩을 허용했다. Informix 12.10 xC2는 MongoDB 드라이버와의 완전한 호환성을 추가하여 NoSQL 컬렉션과 일반 관계형 테이블을 혼합하면서 샤딩, 페일 오버 및 ACID 특성을 계속 허용한다.
- Kdb + : 버전 2.0에서 샤딩을 허용한다.
- MonetDB : 오픈 소스 열 저장소 MonetDB는 2015 년 7 월 릴리스로 읽기 전용 샤딩을 허용한다.
- MongoDB : 버전 1.6에서 샤딩을 허용한다.
- MySQL 클러스터 : 자동 샤딩 : 데이터베이스는 저렴한 범용 노드에서 자동으로 투명하게 분할되므로 애플리케이션을 변경하지 않고도 읽기 및 쓰기 쿼리를 확장할 수 있다.
- MySQL Fabric (MySQL 유틸리티의 일부)에는 샤딩 기능이 포함되어 있다.
- Oracle Database Sharding : Oracle RDBMS12c Release 2 및 하나의 라이너에 새로운 기능으로 도입되었다. Sharding은 독립적인 데이터베이스 간에 데이터를 수평으로 분할하는 데이터 계층 아키텍처이다.
- Oracle NoSQL Database : 클러스터의 자동 샤딩 및 온라인 확장 기능 (샤드 추가)이 있다.
- OrientDB : 버전 1.7에서 샤딩 허용
- Solr 엔터프라이즈 검색 서버 : 샤딩 기능을 제공한다.
- 스패너 : Google의 글로벌 규모의 분산 데이터베이스로, 여러 Paxos 상태 머신에 걸쳐 데이터를 분할하여 "수백 개의 데이터 센터와 수십억 개의 데이터베이스 행에 걸쳐 수백만 개의 머신"으로 확장한다.
- SQLAlchemy ORM : 샤딩 기능을 제공하는 Python 프로그래밍 언어의 데이터 맵퍼.
- Teradata의 DWH : 대규모 병렬 데이터베이스
- Vault : 사용자가 네트워크에 가입하고 거래를 확인하는 데 필요한 데이터를 대폭 감소시키는 암호 화폐입니다. 이것은 훨씬 확장 가능한 네트워크로 변환됩니다. MIT 연구원이 설계했다. 샤딩은 그 기능의 중심이다.[1][2]
단점[편집]
로컬로 최적화되기 전에 데이터베이스 테이블을 쉐딩 하면 조기 복잡성이 발생한다. 샤딩은 최적화를 위한 다른 모든 옵션이 부적합한 경우에만 사용해야 합니다. 데이터베이스 샤딩의 도입된 복잡성으로 인해 다음과 같은 잠재적인 문제가 발생한다.
- SQL의 복잡성 증가 -개발자가 샤딩 논리를 처리하기 위해 더 복잡한 SQL을 작성해야 하기 때문에 버그가 증가했다.
- 샤딩은 복잡성을 소개합니다 -분할, 균형 조정, 조정 및 무결성 실패를 보장하는 샤딩 소프트웨어.
- 단일 실패 지점 -네트워크 / 하드웨어 / 시스템 문제로 인해 하나의 샤드가 손상되면 전체 테이블이 실패한다.
- 보다 복잡한 장애 조치 서버-장애 조치 서버 자체에는 데이터베이스 샤드 집합의 사본이 있어야 한다.
- 보다 복잡한 백업 -개별 샤드의 데이터베이스 백업은 다른 샤드의 백업과 조정되어야 한다.
- 운영상의 복잡성 추가 -인덱스 추가 / 제거, 열 추가 / 삭제, 스키마 수정이 훨씬 더 어려워진다.
자체 샤딩의 이러한 복잡한 문제는 자동 샤딩을 제공 한 독립 소프트웨어 공급 업체가 해결했다.
전망[편집]
오늘날 얼마나 많은 샤드를 사용할 수 있는지에 대한 정확한 측정을 제공하기는 어렵지만, 예측 가능한 미래에 블록체인 사용자의 처리량 요구가 2 차 샤딩의 한계를 넘어설 가능성은 거의 없다. 이러한 양의 샤드를 안전하게 운영하는 데 필요한 수많은 노드는 오늘날 결합된 모든 블록체인을 운영하는 노드의 수보다 훨씬 높다. 그러나 미래의 증거 프로토콜을 구축하려는 경우 오늘날이 문제에 대한 솔루션을 연구하는 것이 좋다. 현재 가장 발전된 제안은 지수 샤딩으로, 샤드 자체가 나무를 형성하고 있으며 각 상위 샤드는 일련의 하위 샤드를 조율하는 반면 자체는 다른 샤드의 하위가 될 수 있다.
각주[편집]
- ↑ 알렉산더 스키 다 노프, 〈블록체인 샤딩에 대한 권위있는 가이드, 1 부〉, 《미디움》, 2018-12-06
- ↑ 〈샤드〉, 《위키피디아》
참고자료[편집]
- 알렉산더 스키 다 노프, 〈블록체인 샤딩에 대한 권위있는 가이드, 1 부〉, 《미디엄》, 2018-12-06
- 〈샤드〉, 《위키피디아》
같이 보기[편집]
