-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create [CRDT] CRDTs The Hard Parts.md
- Loading branch information
Showing
1 changed file
with
81 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
결국 State를 동시편집 하는 것을 돕는다. | ||
|
||
구글 독스 시트, 노션과 같은 서비스들.. | ||
|
||
# OT | ||
|
||
알고리즘에는 2가지 컨셉이 있다. Operational Transformation 과 CRDT | ||
|
||
이는 전통적인 알고리즘이고, 구글 독스에서도 활용되었다. | ||
|
||
우리는 특정 인덱스로 문자가 삽입되거나 삭제되는 영역을 정확히 결정한다. 이 변경사항들은 네트워크를 통해 전달되고, 중앙 서버에 모아진다. | ||
|
||
예를 들어 두 서버가 Helo라는 글을 가지고 있다고 해보자. 한 서버는 l을 2번 인덱스 뒤에 삽입하고 다른 버서는 !를 3번 인덱스 뒤에 삽입합니다. 이떄 서버 B의 입력은 4번 인덱스 뒤로 바뀌게 된다. | ||
|
||
연산이 변경되었다! 이래서 연산 변경이고 Operation Transformation이다. | ||
|
||
이 알고리즘은 잘 작동하지만 하나의 기본적인가정이 있어야 하는데, 하나의 중앙 서버가 있어야 한다는 점이다. 만약 두 유저가 실제로 같은 공간에 있더라도 블루투스와 같은 다른 연결은 사용하면 안된다. 다면 중앙 서버를 사용해야 한다. | ||
|
||
로컬 통신은 허용되지 않는다. 연산 변환을 제대로 할 수 없음. | ||
|
||
이렇게 변화들을 하나로 합치는 과정을 Conversion 수렴이라고 한다. 우리가 하려는 것은 순서가 다르더라도 최종 결과물은 같도록 만드는 것이다. | ||
|
||
수렴 자체는 최종 상태가 무엇인지 대해 아무 것도 정의하지 않는다. 어떤 상태가 바람직한가 바람직하지 않는가는 정하지 않는다. 어떻게 해야 사람이 볼 때 자연스러운가? 사람이 볼 때 예상 가능한가? | ||
|
||
# Topic | ||
|
||
1. Interleaving anomalies In text editing | ||
2. Moving (reordering) list items | ||
3. Moving subtrees of a tree | ||
4. Reducing metadata overhead of CRDTs | ||
|
||
# 1. Interleaving anomailies | ||
|
||
공동 편집 상황에서 같은 위치에 텍스트를 넣을 수 있을 때 인터리핑이 발생할 수 있다. | ||
|
||
이게 발생하는 이유를 설명하기 위해 어떻게 씨알디티가 동작하는지 말해야 한다. | ||
|
||
앞서 OT에서도 글자를 넣을 때 위치를 식별할 수 있어야 했다. | ||
|
||
CRDT는 모든 캐릭터 하나 하나에 식별자를 정의한다. 그렇게 연산 변환을 피하게 해준다. | ||
|
||
CRDT에서 어떤 글들을 튜플의 집합으로 볼 수 있다. 하나의 튜플에는 인덱스와 글자, Editing한 Node Id 등이 저장되어 있다. 이 ID와 같은 추가저적인 상태가 필요한 이유는 나중에 같은 인덱스가 선택 되었을 때의 판단 기준을 정해주기 위해서이다. | ||
|
||
문자들은 서로 다른 곳에서 삽입되고 삭제되는데 이들은 모두 다른 식별자를 갖는다 (TODO 전 문장이랑 순서 바꿔야) | ||
|
||
새 튜플을 추가하는 연산의 경우 합집합으로 해결 가능하다. | ||
|
||
## 14:45 이때 문제 | ||
|
||
이렇게 구현했을 때 불행한 일이 일어날 수 있는데, | ||
|
||
![image](https://github.com/user-attachments/assets/95071d8c-bd8a-4633-951b-42fa51e373d0) | ||
|
||
|
||
|
||
위 그림 처럼 두 유저가 헬로우 엘리스, 헬로우 찰리라고 적었는데 | ||
|
||
겁나 뒤죽박죽한 이상한 단어가 만들어질 수도 있다. | ||
|
||
6글자 8글자 | ||
|
||
두 인덱스 사이는 95 - 64 = 31인데, 간격이 제각각이다. | ||
|
||
![image](https://github.com/user-attachments/assets/be537646-c691-4a49-a773-770c7742c7a0) | ||
|
||
Alice라는 글씨를 넣기 위해 `o` 64와 `!` 95 사이에 6개의 인덱스 생성 찰리도 8개의 인덱스를 생성한다. | ||
|
||
정확히 같은 인덱스를 선택하는 경우를 줄이기 위해 랜덤 숫자로 인덱스를 선택한다. | ||
|
||
근데 이제 이렇게 생성된 인덱스들은 전부 임의의 숫자이므로 뒤죽박죽쓰 되는거지 | ||
|
||
이게 인터리빙이고 읽을 수 없는 글이 되어버렸음 | ||
|
||
여러 Test Editing CRDTs에서 발생한다. | ||
|
||
1. Logoot : interleaving | ||
2. LSEQ : interleaving | ||
3. RGA : lesser anomaly | ||
4. Treedoc : no interleaving | ||
5. WOOT : no interleaving | ||
6. Astrong : interleaving |