위키원
"동적샤딩"의 두 판 사이의 차이
잔글 |
|||
| (사용자 2명의 중간 판 7개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
[[파일:동적샤딩 구조.PNG|썸네일|400픽셀|'''동적샤딩'''(Dynamic sharding) 구조]] | [[파일:동적샤딩 구조.PNG|썸네일|400픽셀|'''동적샤딩'''(Dynamic sharding) 구조]] | ||
| − | '''동적샤딩'''<!--동적 샤딩,-->(Dynamic sharding)<!--DynamicSharding-->은 [[네트워크]] 거래량에 따라 자동으로 노드 그룹을 쪼개거나 묶어 거래를 처리하도록 하는 방식이다. [[클라이언트]] 속도에 맞춰서 병렬 개수를 조절하고 대기시키므로 대용량의 [[데이터]]를 읽을 때 구현 편리하다. ''' | + | '''동적샤딩'''<!--동적 샤딩,-->(Dynamic sharding)<!--DynamicSharding-->은 [[네트워크]] 거래량에 따라 자동으로 노드 그룹을 쪼개거나 묶어 거래를 처리하도록 하는 방식이다. [[클라이언트]] 속도에 맞춰서 병렬 개수를 조절하고 대기시키므로 대용량의 [[데이터]]를 읽을 때 구현 편리하다. '''다이나믹 샤딩'''<!--다이나믹샤딩-->이나 '''로컬샤딩'''<!--로컬 샤딩-->(Local sharding)<!--LocalSharding-->이라고도 불린다. |
== 개요 == | == 개요 == | ||
| − | 동적샤딩은 샤드 호출 실행과 관련된 모든 장치가 동일한 물리적 호스트에 연결되어 있음을 의미하고, 실행해야 하는 테스트 풀을 생성하고 비어있을 때 예전 각 장치 폴링 테스트(이전 테스트로 수행)를 수행하여 동일한 호스트에 연결된 모든 장치를 활용하여, 결과적으로 장치 활용이 최적화된다. 또한 로컬샤딩 이라고도 한다.<ref>안드로이드 출처 공식 사이트 - https://source.android.com/devices/tech/test_infra/tradefed/architecture/advanced/sharding </ref> | + | 동적샤딩은 샤드 호출 실행과 관련된 모든 장치가 동일한 물리적 호스트에 연결되어 있음을 의미하고, 실행해야 하는 테스트 풀을 생성하고 비어있을 때 예전 각 장치 폴링 테스트(이전 테스트로 수행)를 수행하여 동일한 호스트에 연결된 모든 장치를 활용하여, 결과적으로 장치 활용이 최적화된다. 또한 [[로컬샤딩]] 이라고도 한다.<ref>안드로이드 출처 공식 사이트 - https://source.android.com/devices/tech/test_infra/tradefed/architecture/advanced/sharding </ref> |
동적샤딩은 도움이 필요하지 않은 [[알고리즘 샤딩]]과 달리 동적샤딩에서는 외부 로케이터 서비스를 사용하여 항목의 위치를 결정하는데, 단일 로케이터는 파티션 키의 카디널리티에 따라 하나 이상의 키를 처리할 수 있다. 클라이언트가 로케이터 서비스에 문의한 후 데이터를 읽고 쓰며, 동적 샤딩은 불균일한 데이터 분포로 공명하여, 데이터를 재배포하기 위해 로케이터를 생성, 분할 및 재할당 할 수 있다. 로케이터 서비스는 모든 사람이 액세스해야 하는 집중된 경합 및 실패 지점이 된다. 예를 들어, HDFS는 이름 노드를 사용하여 파일 시스템 메타 데이터를 저장하고, 행 키를 범위로 분할(Apache HBase) 및 [[몽고디비]](MongoDB)는 여기서 파일 시스템 메타 데이터와 같은 널리 사용되는 [[데이터베이스]]에서 사용하는 것은 동적 샤딩의 강점이다. 컨피그서버(ConfigServer)는 동기 복제를 사용하여 샤딩 정보를 저장하여 일관성을 유지하고 몽고는 쿼리에 대한 라우팅을 수행한다.<ref>Hitesh Malviya, 〈[https://www.linkedin.com/pulse/how-scale-blockchain-sharding-explained-hitesh-malviya/ How to scale blockchain : Sharding explained]〉, 《링크드인》, 2018-04-04 </ref> | 동적샤딩은 도움이 필요하지 않은 [[알고리즘 샤딩]]과 달리 동적샤딩에서는 외부 로케이터 서비스를 사용하여 항목의 위치를 결정하는데, 단일 로케이터는 파티션 키의 카디널리티에 따라 하나 이상의 키를 처리할 수 있다. 클라이언트가 로케이터 서비스에 문의한 후 데이터를 읽고 쓰며, 동적 샤딩은 불균일한 데이터 분포로 공명하여, 데이터를 재배포하기 위해 로케이터를 생성, 분할 및 재할당 할 수 있다. 로케이터 서비스는 모든 사람이 액세스해야 하는 집중된 경합 및 실패 지점이 된다. 예를 들어, HDFS는 이름 노드를 사용하여 파일 시스템 메타 데이터를 저장하고, 행 키를 범위로 분할(Apache HBase) 및 [[몽고디비]](MongoDB)는 여기서 파일 시스템 메타 데이터와 같은 널리 사용되는 [[데이터베이스]]에서 사용하는 것은 동적 샤딩의 강점이다. 컨피그서버(ConfigServer)는 동기 복제를 사용하여 샤딩 정보를 저장하여 일관성을 유지하고 몽고는 쿼리에 대한 라우팅을 수행한다.<ref>Hitesh Malviya, 〈[https://www.linkedin.com/pulse/how-scale-blockchain-sharding-explained-hitesh-malviya/ How to scale blockchain : Sharding explained]〉, 《링크드인》, 2018-04-04 </ref> | ||
| 10번째 줄: | 10번째 줄: | ||
네이밍(Naming) 그대로 동적으로 바꿀 수 있는데, 로케이터 서비스를 통해 샤드 키를 얻는다. 클러스터에 [[노드]]가 증가하거나 감소해도 로케이터 스비스에 샤드 키만 추가하면 되며, 기존 데이터의 샤드 키 변경은 없기 때문에 확장에 유연한 구조이다. 데이터를 재배치하게 되면 로케이터 서비스의 샤드 키 테이블도 일치시켜줘야 한다. 로케이터가 성능을 위해 캐시(Cache) 하거나 복제(Replication)를 하면 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생한다. 로케이터에 의존할 수밖에 없는 단점이 있다. 키 값(Key-Value)이 아닌 다양한 객체들로 구성되는 경우도 있다. [[관계형 데이터베이스 관리 시스템]](RDBMS)의 조인(join), 인덱스(index), [[트랜잭션]]을 사용함으로써 애플리케이션의 복잡도를 줄일 수 있다. 이와 유사한 방법으로 샤딩하는 방법이 [[엔티티]](Entity) 그룹이다. 하나의 물리적인 샤드에 쿼리를 진행한다면 효율적이며, 하나의 샤드에서 강한 응집도를 가질 수 있어 데이터는 자연스럽게 사용자별로 분리되어 저장되고, 사용자가 늘어남에 따라 확장성이 좋은 파티셔닝이다. 반대로 크로스 파티션 쿼리는 단일 파티션 쿼리보다 일관성의 보장과 성능을 보장하지 않는다. 그렇기 때문에 이런 쿼리들이 자주 실행하지 않도록 만들어야 한다.<ref>RASTA LION, 〈[http://rastalion.me/archives/778 샤드와 샤딩 (Shard and Sharding)]〉, 《개인블로그》, 2019-08-27 </ref> | 네이밍(Naming) 그대로 동적으로 바꿀 수 있는데, 로케이터 서비스를 통해 샤드 키를 얻는다. 클러스터에 [[노드]]가 증가하거나 감소해도 로케이터 스비스에 샤드 키만 추가하면 되며, 기존 데이터의 샤드 키 변경은 없기 때문에 확장에 유연한 구조이다. 데이터를 재배치하게 되면 로케이터 서비스의 샤드 키 테이블도 일치시켜줘야 한다. 로케이터가 성능을 위해 캐시(Cache) 하거나 복제(Replication)를 하면 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생한다. 로케이터에 의존할 수밖에 없는 단점이 있다. 키 값(Key-Value)이 아닌 다양한 객체들로 구성되는 경우도 있다. [[관계형 데이터베이스 관리 시스템]](RDBMS)의 조인(join), 인덱스(index), [[트랜잭션]]을 사용함으로써 애플리케이션의 복잡도를 줄일 수 있다. 이와 유사한 방법으로 샤딩하는 방법이 [[엔티티]](Entity) 그룹이다. 하나의 물리적인 샤드에 쿼리를 진행한다면 효율적이며, 하나의 샤드에서 강한 응집도를 가질 수 있어 데이터는 자연스럽게 사용자별로 분리되어 저장되고, 사용자가 늘어남에 따라 확장성이 좋은 파티셔닝이다. 반대로 크로스 파티션 쿼리는 단일 파티션 쿼리보다 일관성의 보장과 성능을 보장하지 않는다. 그렇기 때문에 이런 쿼리들이 자주 실행하지 않도록 만들어야 한다.<ref>RASTA LION, 〈[http://rastalion.me/archives/778 샤드와 샤딩 (Shard and Sharding)]〉, 《개인블로그》, 2019-08-27 </ref> | ||
| − | + | [[동적샤딩]]은 네임 스페이스(사용자 이름)의 존재를 중재하고 객체의 데이터가 있는 위치, 샤드를 제공하며 이동하는 동안 객체를 잠글 수 있는 서비스를 도입하여 알고리즘 샤딩의 문제를 해결하는데, 이를 통해 한 그룹의 샤드에서 다른 샤드로 대규모 사용자 그룹과 달리 사용자를 개별적으로 재배치하여 핫스팟을 줄일 수 있다. 임계 경로에서는 이 서비스를 [[로케이터]](Locator) 라고 하고 Six Apart에서는 이를 글로벌 데이터베이스(Global DB)라고 한다. 이전 백과사전 비유에서 확장 된 이 서비스는 인덱스 볼륨과 유사하며, 이 서비스에는 몇 개의 작은 열만 포함되어 있지만, 대량의 사용자 데이터는 [[샤드]]에 보관되고, 데이터베이스 크기의 기본 한계는 기본 파일의 크기이며, 그 한계에 접근하는 방법은 간단한 곱셈이다. 쓰기로드 및 긴 복구 및 테이블 변경 시간과 같은 요소로 인해 실제 크기 제한이 최대 파일 크기보다 훨씬 낮고, 로케이터 또는 글로벌 데이터베이스의 경우 테이블이 너무 단순하여 변경이 필요하지 않으며 샤드에서 데이터를 업데이트하는 활성 사용자에 비해 계정 생성, 삭제, 이동이 드물게 발생한다. 이 서비스에 먼저 연락하면 일부 작업에서 약간의 대기 시간이 발생할 수 있지만, 일반적으로 좋은 거래로 간주하며 mem cached와 같은 캐싱으로 완화 할 수 있으나 정전 이벤트가 발생하면 콜드 캐시 및 스크램블링 엔지니어가 단일 글로벌 데이터베이스를 방해하는 전체 로드를 조절해야 한다.<ref>닐 킨스, 〈[https://www.clustrix.com/bettersql/sharding-theory-algorithmic-sharding/ 샤딩 : 이론과 실습 (2 부)]〉, 《클러스트릭스》, 2013-01-17 </ref> | |
| − | + | ;장점 | |
| − | + | * 네이밍 그대로 동적으로 바꿀 수 있다. | |
| − | + | * 로케이터 서비스를 통해 샤드 키를 얻는다. | |
| − | + | * 클러스터가 포함하는 노드 개수를 늘리면, 로케스터 서비스에 샤드 키를 추가만 하고, 기존의 데이터 샤드 키는 변경이 없으며, 확장에 유연한 구조이다. | |
| − | + | * Example : HDFS - Name Node, MongoDB - ConfigServer<ref name="네소이">nesoy, 〈[https://nesoy.github.io/articles/2018-05/Database-Shard Database의 샤딩(Sharding)이란?]〉, 《개인블로그》, 2018-05-30 </ref> | |
| − | + | ;단점 | |
| − | + | * 데이터를 재배치하게 되면, 로케이터 서비스의 샤드 키 테이블도 일치시켜줘야 한다. | |
| − | + | * 로케이터가 성능을 위해 캐시 하거나 재배치를 하면, 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생하며, 로케이터에 의존할 수밖에 없다.<ref name="네소이"></ref> | |
| − | + | ;동적샤드 등록 | |
| − | + | 동적샤드 등록에서 샤드는 추적 프로세스의 일부로 등록되어 인덱스를 형성하므로 솔러(Solr)노드에서 수동 샤드 분배 패턴을 따를 필요가 없다. 수동샤딩과 달리 동적샤딩에는 샤드 및 인스턴스를 알려진 호스트 집합에 올바르게 분산시킬 필요가 없다. [[퀴리]]는 탄력적이며, [[인스턴스]]에 대해 구성 가능한 지연이 발생한다. 수동샤딩의 경우 모든 인스턴스는 예상 URL의 예상 URK에서 사용 가능해야 한다. 동적 샤드 등록은 샤드마다 다른 수의 인스턴스를 허용하지만 수동샤딩은 그렇지 않다. 동적 샤딩을 사용하려면 ''alfresco-global.properties'' 파일에서 다음 특성을 설정한다. | |
solr . useDynamicShardRegistration = true | solr . useDynamicShardRegistration = true | ||
: 그런다음 속성은 퀴리에 선택된 인스턴스를 제어한다. | : 그런다음 속성은 퀴리에 선택된 인스턴스를 제어한다. | ||
| 51번째 줄: | 51번째 줄: | ||
|align=center|1000건의 거래 | |align=center|1000건의 거래 | ||
|} | |} | ||
| − | + | 상점에 대해 둘 이상의 인덱스가 있는 경우 최신 인덱스, 대부분의 트랜잭션을 인덱스 한 인덱스가 사용된다. 각 샤드에 대해 인스턴스는 적극적으로 추적하고 리드 인스턴스의 1,000개 트랜잭션 내에 있는 모든 샤드에서 임의로 선택된다. 샤드는 다음과 같은 경우에 동일한 색인의 일부로 간주된다. | |
# 같은 매장을 추적 | # 같은 매장을 추적 | ||
# 동일한 템플릿을 사용하므로 솔러 스키마 | # 동일한 템플릿을 사용하므로 솔러 스키마 | ||
2019년 9월 28일 (토) 00:47 기준 최신판
동적샤딩(Dynamic sharding)은 네트워크 거래량에 따라 자동으로 노드 그룹을 쪼개거나 묶어 거래를 처리하도록 하는 방식이다. 클라이언트 속도에 맞춰서 병렬 개수를 조절하고 대기시키므로 대용량의 데이터를 읽을 때 구현 편리하다. 다이나믹 샤딩이나 로컬샤딩(Local sharding)이라고도 불린다.
개요[편집]
동적샤딩은 샤드 호출 실행과 관련된 모든 장치가 동일한 물리적 호스트에 연결되어 있음을 의미하고, 실행해야 하는 테스트 풀을 생성하고 비어있을 때 예전 각 장치 폴링 테스트(이전 테스트로 수행)를 수행하여 동일한 호스트에 연결된 모든 장치를 활용하여, 결과적으로 장치 활용이 최적화된다. 또한 로컬샤딩 이라고도 한다.[1]
동적샤딩은 도움이 필요하지 않은 알고리즘 샤딩과 달리 동적샤딩에서는 외부 로케이터 서비스를 사용하여 항목의 위치를 결정하는데, 단일 로케이터는 파티션 키의 카디널리티에 따라 하나 이상의 키를 처리할 수 있다. 클라이언트가 로케이터 서비스에 문의한 후 데이터를 읽고 쓰며, 동적 샤딩은 불균일한 데이터 분포로 공명하여, 데이터를 재배포하기 위해 로케이터를 생성, 분할 및 재할당 할 수 있다. 로케이터 서비스는 모든 사람이 액세스해야 하는 집중된 경합 및 실패 지점이 된다. 예를 들어, HDFS는 이름 노드를 사용하여 파일 시스템 메타 데이터를 저장하고, 행 키를 범위로 분할(Apache HBase) 및 몽고디비(MongoDB)는 여기서 파일 시스템 메타 데이터와 같은 널리 사용되는 데이터베이스에서 사용하는 것은 동적 샤딩의 강점이다. 컨피그서버(ConfigServer)는 동기 복제를 사용하여 샤딩 정보를 저장하여 일관성을 유지하고 몽고는 쿼리에 대한 라우팅을 수행한다.[2]
특징[편집]
네이밍(Naming) 그대로 동적으로 바꿀 수 있는데, 로케이터 서비스를 통해 샤드 키를 얻는다. 클러스터에 노드가 증가하거나 감소해도 로케이터 스비스에 샤드 키만 추가하면 되며, 기존 데이터의 샤드 키 변경은 없기 때문에 확장에 유연한 구조이다. 데이터를 재배치하게 되면 로케이터 서비스의 샤드 키 테이블도 일치시켜줘야 한다. 로케이터가 성능을 위해 캐시(Cache) 하거나 복제(Replication)를 하면 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생한다. 로케이터에 의존할 수밖에 없는 단점이 있다. 키 값(Key-Value)이 아닌 다양한 객체들로 구성되는 경우도 있다. 관계형 데이터베이스 관리 시스템(RDBMS)의 조인(join), 인덱스(index), 트랜잭션을 사용함으로써 애플리케이션의 복잡도를 줄일 수 있다. 이와 유사한 방법으로 샤딩하는 방법이 엔티티(Entity) 그룹이다. 하나의 물리적인 샤드에 쿼리를 진행한다면 효율적이며, 하나의 샤드에서 강한 응집도를 가질 수 있어 데이터는 자연스럽게 사용자별로 분리되어 저장되고, 사용자가 늘어남에 따라 확장성이 좋은 파티셔닝이다. 반대로 크로스 파티션 쿼리는 단일 파티션 쿼리보다 일관성의 보장과 성능을 보장하지 않는다. 그렇기 때문에 이런 쿼리들이 자주 실행하지 않도록 만들어야 한다.[3]
동적샤딩은 네임 스페이스(사용자 이름)의 존재를 중재하고 객체의 데이터가 있는 위치, 샤드를 제공하며 이동하는 동안 객체를 잠글 수 있는 서비스를 도입하여 알고리즘 샤딩의 문제를 해결하는데, 이를 통해 한 그룹의 샤드에서 다른 샤드로 대규모 사용자 그룹과 달리 사용자를 개별적으로 재배치하여 핫스팟을 줄일 수 있다. 임계 경로에서는 이 서비스를 로케이터(Locator) 라고 하고 Six Apart에서는 이를 글로벌 데이터베이스(Global DB)라고 한다. 이전 백과사전 비유에서 확장 된 이 서비스는 인덱스 볼륨과 유사하며, 이 서비스에는 몇 개의 작은 열만 포함되어 있지만, 대량의 사용자 데이터는 샤드에 보관되고, 데이터베이스 크기의 기본 한계는 기본 파일의 크기이며, 그 한계에 접근하는 방법은 간단한 곱셈이다. 쓰기로드 및 긴 복구 및 테이블 변경 시간과 같은 요소로 인해 실제 크기 제한이 최대 파일 크기보다 훨씬 낮고, 로케이터 또는 글로벌 데이터베이스의 경우 테이블이 너무 단순하여 변경이 필요하지 않으며 샤드에서 데이터를 업데이트하는 활성 사용자에 비해 계정 생성, 삭제, 이동이 드물게 발생한다. 이 서비스에 먼저 연락하면 일부 작업에서 약간의 대기 시간이 발생할 수 있지만, 일반적으로 좋은 거래로 간주하며 mem cached와 같은 캐싱으로 완화 할 수 있으나 정전 이벤트가 발생하면 콜드 캐시 및 스크램블링 엔지니어가 단일 글로벌 데이터베이스를 방해하는 전체 로드를 조절해야 한다.[4]
- 장점
- 네이밍 그대로 동적으로 바꿀 수 있다.
- 로케이터 서비스를 통해 샤드 키를 얻는다.
- 클러스터가 포함하는 노드 개수를 늘리면, 로케스터 서비스에 샤드 키를 추가만 하고, 기존의 데이터 샤드 키는 변경이 없으며, 확장에 유연한 구조이다.
- Example : HDFS - Name Node, MongoDB - ConfigServer[5]
- 단점
- 데이터를 재배치하게 되면, 로케이터 서비스의 샤드 키 테이블도 일치시켜줘야 한다.
- 로케이터가 성능을 위해 캐시 하거나 재배치를 하면, 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생하며, 로케이터에 의존할 수밖에 없다.[5]
- 동적샤드 등록
동적샤드 등록에서 샤드는 추적 프로세스의 일부로 등록되어 인덱스를 형성하므로 솔러(Solr)노드에서 수동 샤드 분배 패턴을 따를 필요가 없다. 수동샤딩과 달리 동적샤딩에는 샤드 및 인스턴스를 알려진 호스트 집합에 올바르게 분산시킬 필요가 없다. 퀴리는 탄력적이며, 인스턴스에 대해 구성 가능한 지연이 발생한다. 수동샤딩의 경우 모든 인스턴스는 예상 URL의 예상 URK에서 사용 가능해야 한다. 동적 샤드 등록은 샤드마다 다른 수의 인스턴스를 허용하지만 수동샤딩은 그렇지 않다. 동적 샤딩을 사용하려면 alfresco-global.properties 파일에서 다음 특성을 설정한다.
solr . useDynamicShardRegistration = true
- 그런다음 속성은 퀴리에 선택된 인스턴스를 제어한다.
search . solrShardRegistry . purgeOnInit = true를 search . solrShardRegistry . shardInstanceTimeoutInSeconds = 300 search . solrShardRegistry . maxAllowedReplicaTxCountDifference = 1000
속 성 기 술 예 search.solrShardRegistry. purgeOnInit
사실인 경우이 특성은 서브 시스템이 시작될 때 데이터베이스에서 지속된 샤드 상태를 제거한다. 사실 search.solrShardRegistry. shardInstanceTimeoutInSeconds
이 시간 내에 샤드가 추적 요청을 하지 않으면 쿼리에 사용되지 않도록 지정한다. 큰 변경 세트를 추적하거나 색인을 다시 빌드할 때 샤드 제한 시간을 늘린다. 예를 들어 이 속성값을 3200 또는 7,200초로 변경한다. 300초 search.solrShardRegistry. maxAllowedReplicaTxCountDifference
샤드가 선행 인스턴스 뒤의 이 트랜잭션 수보다 많은 경우 사용되지 않도록 지정한다. 1000건의 거래
상점에 대해 둘 이상의 인덱스가 있는 경우 최신 인덱스, 대부분의 트랜잭션을 인덱스 한 인덱스가 사용된다. 각 샤드에 대해 인스턴스는 적극적으로 추적하고 리드 인스턴스의 1,000개 트랜잭션 내에 있는 모든 샤드에서 임의로 선택된다. 샤드는 다음과 같은 경우에 동일한 색인의 일부로 간주된다.
- 같은 매장을 추적
- 동일한 템플릿을 사용하므로 솔러 스키마
- 샤드 수가 동일하다.
- 필요한 경우에 도일한 구성으로 동일한 파티션 방법을 사용한다.
- 콘텐츠를 변형하거나 무시하는 동일한 설정
http : // localhost : 8080 / solr4 / admin / cores? action = newCore & storeRef = workspace : // SpacesStore & numShards = 10 & numNodes = 1 & nodeInstance = 1 & property . data . dir . root = < ALFRESCO_HOME > / solr4 / workspace - SpacesStore & shardIds = 0 , 1 , 2 , 3 , 4
- 동적샤딩에서 수동샤딩과 동일한 API를 사용하여 샤드를 만들거나 필요한 샤드를 쉼표로 구분된 목록으로 나열할 수 있다. 샤드 ID. 사용 가능한 모든 인덱스, 샤드 및 인스턴스의 상태는 JMX를 클라이언트를 사용하여 찾을 수 있다. 동적샤딩은 현재 부분 인덱스를 사용하여 쿼리에 응답하고, 예를 들어 샤드 1과 샤드 2의 두 샤드가 있는데 샤드 2에 대한 인스턴스가 없으면 쿼리는 샤드 1만 사용한다.[6]
활용[편집]
로커스체인[편집]
로커스체인(Locus Chain)은 샤드 수 만큼 네트워크 사용량과 스토리지 사용량을 나누고, 고유의 알고리즘으로 샤드 간 균형을 지속해서 유지하는 동적샤딩이다. 계정 단위로 샤드를 재배치하여 샤드의 수와 사이즈, 밸리 데이터 비율 등을 조절하는 동적 샤딩으로, 동적샤딩은 로커스체인이 어카운트별 트랜잭션 체인을 갖는 AWTC 원장 구조이기 때문에 보다 용이하게 구현이 가능하여, 애초에 샤딩을 실현하기 위해 채택한 구조이다. 로커스체인은 모든 사용자가 모바일과 같은 작은 기기로도 네트워크에 노드로 참여하고, 그로 인해 높은 탈중앙화를 이룰 수 있도록 노드가 부담해야 하는 자원요구량 네트워크 대역폭 소모, 원장 용량 차지을 최소한으로 낮추고자 동적샤딩을 적용했다. 이중 네트워크 샤딩은 네트워크를 여러 샤드로 나눠 같은 샤드에 속한 노드들끼리 메시지를 주고받도록 하는 것인데, 메시지를 주고받아야 하는 영역 자체가 쪼개진 셈으로 이때 샤드를 나누는 기준은 물리적 거리가 아니며, 물리적 거리로 하면 보안에 치명적인 문제가 발생하기 때문이다. 그리고 필요한 시 서로 다른 샤드끼리 메시지를 주고받을 수 있는 인터샤드 트랜잭션도 가능하며, 추가적으로데이터베이스 샤딩도 들어간다. 하지만 원장 사이즈 문제는 처음에 말한 대로 원래의 도입 취지를 베리파이어블 프루닝으로 거의 다 해결할 수 있게 되어서 보조적으로 쓰인다고 표현한다. 로커스체인은 샤드 수만큼 네트워크 사용량과 스토리지 사용량을 나누고, 고유의 알고리즘으로 샤드간 균형을 유지하는 동적샤딩으로 계정 단위로 샤드를 재배치하여 샤드의 수와 사이즈, 밸리 데이터 비율 등을 조절하는 동적 샤딩인데, 이것은 로커스체인이 어카운트별 트랜잭션 체인을 갖는 AWTC 원장구조이기 때문에 용이한 방식이다.[7]
로커스체인의 동적샤딩 기술은 노드가 부담해야 하는 네트워크 부하를 샤드 수만큼 나누고 네트워크 전체의 트랜잭션 처리량을 샤드 수만큼 늘리면서 알고리즘으로 샤드를 재배치하여 서로간의 균형을 유지하는 기술이다. 각 샤드는 독립적으로 비잔틴 장애 허용(BFT) 합의알고리즘을 수행하고, 한 어카운트는 한번에 하나의 샤드에서만 처리되는 방식이기 때문에 노드의 네트워크 사용량은 줄어들고 트랜잭션 처리량은 노드 숫자가 늘어날수록 이에 비례하여 늘어난다. 또한 로커스체인은 원장 구조가 어카운트 별(AWTC: Account-wise Transaction Chain)로 되어 있어 샤드간 불균형이 일어났을 경우 계정 단위로 샤드를 재배치하여 샤드의 수와 사이즈, 밸리데이터 비율 등을 조절하는 것이 용이하다. 여기에 추가적으로 원장을 쪼개는 스테이트 샤딩을 더해 스토리지 사용량 역시 샤드 수만큼 나눌 계획이라고 한다. 로커스체인은 DAG상에서 비잔틴 장애 허용 합의알고리즘을 구현[8]해냈기 때문에 일반 샤딩이 가졌던 문제점을 해결했다고 주장한다.
- 동적 상태샤딩
- 로커스체인을 개발 중인 블룸테크놀로지가 AWTC(Account-Wise Transaction Chain)-비잔틴 장애 허용(BFT) 합의 알고리즘을 구현하는 데 성공했다. AWTC-BFT 알고리즘은 블록체인 장부가 일정 크기까지 커질 경우 예전 데이터를 다른 곳에 보관하는 방식으로 확장성을 개선하고, 이전 데이터는 필요하면 언제든지 확인이 가능하며, 이는 로커스체인이 개발 중인 동적 상태 샤딩(Dynamic State Sharding)의 기반이 되는 핵심 요소이기도 하다. 동적 상태 샤딩은 대그(DAG)와 샤딩의 속도를 결합해 실사용에도 문제없을 정도로 확장성을 끌어올리는 기술이다.[9]
- B7 CEO 서밋 콘퍼런스에서는 로커스체인은 블록체인 기술이 전자정부 시스템에 적용되면 투명성을 확보해 정부에 대한 신뢰를 높이고 그로 인해 국민의 편의성 증대에 기여하게 될 것이며, 거래의 수가 많아져도 속도 저하 없이 빠르게 거래 승인이 가능한 AWTC 구조와 원장의 사이즈 문제 해결을 위해 적용된 독자적인 기술인 동적 상태 샤딩(Dynamic State Sharding)을 기반으로 개발되고 있는 로커스체인은 실사용에 있어 불편함이 없는 빠르고 가벼운 차세대 블록체인 플랫폼으로 대규모 확장성을 염두에 두고 설계되었다. 블록체인 기술에 기반한 전자정부 구축에 있어 가장 모범적인 해답이 될 것이다.[10]
로커스체인에 대해 자세히 보기
텔레그램[편집]
텔레그램 오픈 네트워크(TON) 블록체인의 특징은 확장성을 확보하기 위해 동적샤딩 구조를 채택했다. 텔레그램 오픈 네트워크는 로드 변화에 따라 자동으로 분할하고 병합하는 구조를 목표로 하며, 텔레그램은 이런 구조 덕분에 플랫폼을 사용하는 일부 서비스가 인기를 끌어도 새로운 블록이 신속하게 생성되고, 대기가 줄어들어 거래 비용도 낮출 수 있다.[11] 텔레그램 오픈 네트워크의 3세대 블록체인은 높은 수준의 내 결함 성을 갖춘 여러 당사자가 확보한 역동적인 스테이크의 증거를 기반으로 하고, 또한 ID, 지불 및 스마트 계약의 저장을 처리하며, 따라서 통화 증명 작성에 의존하는 대신, 텔레그램은 원래의 비트코인(Bitcoin) 방식보다 에너지 낭비가 적은 새로운 방식의 암호 해독 방식을 사용한다. 클레임은 초당 약 1백만 개의 매우 우수한 거래가 가능할 것이며, 다른 말로 하면, 베를린에서의 폴카도트(Polkadot) 프로젝트의 야심과 비슷하지만, 1억 8천만 명의 인구가 기지로 구축되었다. 이것은 이른바 동적샤딩과의 인터체인(inter chain)으로 만든다.[12]
텔레그램에 대해 자세히 보기
각주[편집]
- ↑ 안드로이드 출처 공식 사이트 - https://source.android.com/devices/tech/test_infra/tradefed/architecture/advanced/sharding
- ↑ Hitesh Malviya, 〈How to scale blockchain : Sharding explained〉, 《링크드인》, 2018-04-04
- ↑ RASTA LION, 〈샤드와 샤딩 (Shard and Sharding)〉, 《개인블로그》, 2019-08-27
- ↑ 닐 킨스, 〈샤딩 : 이론과 실습 (2 부)〉, 《클러스트릭스》, 2013-01-17
- ↑ 5.0 5.1 nesoy, 〈Database의 샤딩(Sharding)이란?〉, 《개인블로그》, 2018-05-30
- ↑ 알프레스코 공식 홈페이지 - https://docs.alfresco.com/5.1/concepts/dynamic-sharding.html
- ↑ 처음처럼, 〈타블록체인 샤딩과 로커스체인의 다이나믹샤딩의 차이?〉, 《코박》, 2019-05-01
- ↑ 여용준, <로커스체인, 세계 최초 'DAG-BFT 확정합의 알고리즘' 블록체인 기술 구현 성공>, 《이뉴스투데이》, 2019-02-21
- ↑ 김혜정 기자, 〈로커스체인, DAG-BFT 접목한 합의 알고리즘 구현〉, 《데일리토큰》, 2019-02-21
- ↑ 김태연 기자, 〈로커스체인 파운데이션, 블록체인 서울 2018 참가 시도되지 않았던 새로운 기술의 가볍고 빠른 차세대 블록체인 로커스체인, 국내 첫 소개〉, 《블록타임스TV닷컴》, 2018-09-21
- ↑ 임유경 기자, 〈블록체인 '태생적 한계' 뛰어넘는다〉, 《지디넷코리아》, 2018-01-12
- ↑ 사회기술의 힘 공식 사이트 - https://kor.powerofsocialtech.com/telegram-plans-multi-billion-dollar-ico
참고자료[편집]
- 알프레스코 공식 홈페이지 - https://docs.alfresco.com/5.1/concepts/dynamic-sharding.html
- 처음처럼, 〈타블록체인 샤딩과 로커스체인의 다이나믹샤딩의 차이?〉, 《코박》, 2019-05-01
- 사회기술의 힘 공식 사이트 - https://kor.powerofsocialtech.com/telegram-plans-multi-billion-dollar-ico
- 안드로이드 출처 공식 사이트 - https://source.android.com/devices/tech/test_infra/tradefed/architecture/advanced/sharding
- RASTA LION, 〈샤드와 샤딩 (Shard and Sharding)〉, 《개인블로그》, 2019-08-27
- 여용준, <로커스체인, 세계 최초 'DAG-BFT 확정합의 알고리즘' 블록체인 기술 구현 성공>, 《이뉴스투데이》, 2019-02-21
- nesoy, 〈Database의 샤딩(Sharding)이란?〉, 《개인블로그》, 2018-05-30
- 임유경 기자, 〈블록체인 '태생적 한계' 뛰어넘는다〉, 《지디넷코리아》, 2018-01-12
- 이일구 교수, 〈(디센터 톺아보기)블록체인, 5G 속도 따라잡을까〉, 《시그널》, 2018-01-12
- 닐 킨스, 〈샤딩 : 이론과 실습 (2 부)〉, 《클러스트릭스》, 2013-01-17
- 김혜정 기자, 〈로커스체인, DAG-BFT 접목한 합의 알고리즘 구현〉, 《데일리토큰》, 2019-02-21
- 김태연 기자, 〈로커스체인 파운데이션, 블록체인 서울 2018 참가 시도되지 않았던 새로운 기술의 가볍고 빠른 차세대 블록체인 로커스체인, 국내 첫 소개〉, 《블록타임스TV닷컴》, 2018-09-21
- 조지훈, 〈Google Cloud Next ’19 참관기 (1부)〉, 《개인블로그》, 2019-08-26 </ref>
- Hitesh Malviya, 〈How to scale blockchain : Sharding explained〉, 《링크드인》, 2018-04-04
같이 보기[편집]
