EOS EOSIO DApp 개발 – '에브리피디아 백서 읽기' 시리즈 10.Database Schema
Database Schema
Collective collaboration requires agreed norms and standards, especially norms in handling the data that is stored, updated, and consumed. Bitcoin’s unspent transaction output (UTXO) database model is only effective because all network participants agree to keep account values stored in such a structure. Otherwise, the same security guarantees would not be possible.
협업은 표준을 요구하지. 데이터 처리를 위해서는 말할 필요도 없고. 비트코인의 UTXO(미사용 트랜잭션 출력) 데이터 모델은 모든 네트워크 참여자가 그러한 구조로 계정 값이 저장되도록 합의했기 때문에 효과적인거지. 그렇지 않다면 동일한 보안 보장은 불가능해.
그래서? 에브리피디아에도 표준 데이터 스키마가 필요하다는 것이지.
The “database schema” refers the structure of on-chain storage in the EOS.IO blockchain inside of the article module (the associated smart contract).
아티클 모듈은 EOS.IO 스마트 컨트랙트로 작성되고, 아티클 모듈에서 사용하는 데이터는 EOS.IO 데이터 저장소에 저장되지. 데이터 저장소에 저장되는 데이터에 대한 "데이터베이스 스키마"가 필요한 거고.
The database for the Everipedia Network will be a 2 column element that pertains to the current hash of the article state. The second element is the immediate preceding hash of the previous state of the article which functions as a pointer.
에브리피디아의 데이터베이스 스키마는 매우 단순해. 글을 처음 작성한 경우와 이전 글이 있는데 이것을 편집하는 경우만 고려하면 돼. 두 개의 컬럼만 있으면 되지. 현재 글을 가르키는 포인터로서의 해시와 이전 글을 가르키는 포인터로서의 해쉬만 있으면 된다는 거지.
This allows for a tree-like structure of the history of IPFS hashes of the article and allows quick querying of the Everipedia Network database to find the current state of an article in relation to some historical snapshot (as well as any forks or merges). This is similar to a git protocol tree of all previous commits to a codebase except the work done to be committed is an encyclopedia article or edit.
글을 작성하고, 작성된 글을 여러 차례에 거쳐 변경한다면 버전 관리는 필수적 이겠지.
여러 사람이 글을 동시에 편집하게 되면 포크나 병합도 일어나겠지. 글 변경 이력은 해시 트리 처럼 될거야. 해시 트리를 통해 글의 특정 버전에 빠르게 접근할 수 있겠지.
깃(git)은 버전 관리의 대명사이니 깃에서 필요한 개념을 가져다 사용하면 되겠지. 깃 프로토콜 트리 개념을 해시 트리로 가져다 사용하자.
This schema has two technical guarantees that make it ideal for distributed ledger storage: 1. Querying for a complete state tree of an article (therefore showing all previous historical edits). 2. Easy branching and merging of articles while keeping a unified history of previous states.
이 스키마는 분산 원장 저장소에 다음 두 가지를 가능하도록 해 줘.
- 글에 대한 모든 상태 트리를 쿼리 할 수 있도록 해 줘. 이전 편집 이력들을 모두 보여줄 수 있지.
- 이전 상태의 통합된 이력을 유지하면서 브랜치와 머지를 쉽게 할 수 있도록 해줘.
Visual schematic of the above database schema showing 4 distinct articles: “University of California, Los Angeles,” “Travis Moore,” “Qajar Dynasty,” and “Barack Obama.” Each article is hashed. The first edit of an article (article creation) points to a null parent hash. Subsequent edits create new content and hence a new hash and point to the article’s immediate previous state. This forms a tree which makes the article history.
위 그림에는 서로 다른 4개의 글이 있지. 각각의 글은 자신의 해시를 가지고 있어. 이전 버전이 있으면 이전 버전을 가르키는 해시도 가지고 있어야 해. 이전 버전이 없는 즉 처음 생성된 글은 이전 버전의 해시로 null을 갖게 돼.
이렇게 작성된 글 이력은 트리 형태가 되겠지.
위 그림의 글 상태 이력을 데이터로 표현하면 아래와 같이 되겠지.
An example database of 10 rows is shown below:
{
[ QmPgLhaXAPYxx9isxGuxnBZA28WoUxhYsiRaPPbMKdvPAm, null],
[ QmSRvE5W6WV4KGRwhttumnamJgGGyiaAGYLEaubRgRreP2,
QmPgLhaXAPYxx9isxGuxnBZA28WoUxhYsiRaPPbMKdvPAm ]
[ QmcmBixvVnzrswZ24BbzjbrkTvi4ZMbxZcZpfqjzkxmLYA, null ]
[ QmeAv3LJo4Kre6dR7GQBqjJFztY9YWZD131W5tYGStUcbM, null ],
[ QmXvHQCbvxp3vQm96VmZDBaTX8Aae6vVcoTvVB6QQsMXnM,
QmeAv3LJo4Kre6dR7GQBqjJFztY9YWZD131W5tYGStUcbM ],
[ QmYP7vvmy1MX7x6QDazd8opK4KB2NuhiLGbwBQWgxR552q,
QmXvHQCbvxp3vQm96VmZDBaTX8Aae6vVcoTvVB6QQsMXnM ]
[ QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco, null ],
[ QmcHn96sJBZY4QaGeDh6vVBDznygqbVCgh7bwHbskxcoaY,
QmeAv3LJo4Kre6dR7GQBqjJFztY9YWZD131W5tYGStUcbM ]
[ QmbtygxuXiQDYn1BWDjsJtHUVYuFzUUV6fdJZg8AL4axVB,
QmSRvE5W6WV4KGRwhttumnamJgGGyiaAGYLEaubRgRreP2]
[ QmYP7vvmy1MX7x6QDazd8opK4KB2NuhiLGbwBQWgxR552q,
QmcHn96sJBZY4QaGeDh6vVBDznygqbVCgh7bwHbskxcoaY ]
}
The first element in each tuple marks some current state, while the second element refers to the previous article state. If the second element is null, this means that the article state has no previous state (meaning the article was just created).
튜플의 첫 번재 요소는 현재 상태를 나타내고 두 번째 요소는 이전 상태를 나타내. 글이 처음 작성되는 경우라면 이전 상태가 없으니 이전 상태는 null이 되겠지.
In the example above, rows 1, 3, 4, and 7 depict the creation of a new article with no previous state. Row 2 simply shows the article in line one being edited. Row 9 shows the article state in row 2 being edited (now with 3 total edits in its history)
Line 5 and 8 demonstrate an article of the same state forking into two different states (perhaps edited by two different communities or telling different narratives of the same topic). Both line 5 and 8 share the previous state of an article created on row 4. Row 6 shows the article in 5 being edited further but the forked off article in row 8 clearly ignores the change because row 9 depicts an edit made to the forked article. Row 10 shows the original forked article in row 8 being merged back into the article that it forked from. The two forked articles are now merged into one again (perhaps due to an edit proposal and community agreement).
위 설명은 그림의 글에 표현된 해시 값을 기준으로 데이터베이스 행이 어떻게 작성되는지를 설명한 거야. 그림을 따라 순서는 상관하지 말고 행을 작성해 보면 알거야.
While the above structure has many advantages, it has several issues that should be directly addressed. For example, concurrent edit proposals can potentially cause issues. If one individual proposes an edit to an article and submits an edit object, then before that object is finalized through consensus, another edit object referencing the same parent hash essentially creates an unintended fork of the article. A potential way to resolve this issue would be to only allow one pending edit proposal referencing the same parent hash at a time in the queue of pending edits.
위 구조는 장점이 많지만 몇 가지 해결해야 할 문제도 있어.
예를 들어 동시 편집 제안은 문제를 일으킬 수 있지. 편집 제안이 제출되었지만 아직 합의를 통해 확정되지 않은 상태에서 같은 버전의 글에 대해 편집 제안을 한다면 문제가 되겠지.
이 문제를 해결하는 가능한 방법 중 하나는 같은 이전 해시 값을 갖는 편집 제안은 하나만 가능하도록 하는 거야.