db.md

db설계

노션과 같이 flexible하고 CRM 목적 데이터베이스 만들어야만 함 Local-First일수도 있고 아닐수도 있고. Collaborative 해야 할 수도 있고 아닐수도 있고 User-Friendly, Developer-Friendly 일수도 있고 아닐수도 있고

이름 정의

Collection, Document, Field.

• Collection: 데이터베이스의 테이블과 같은 개념
• Document: 데이터베이스의 레코드와 같은 개념
• Field: 데이터베이스의 컬럼과 같은 개념

조건

• central 서버와 서로 sync 할 수 있어야 함. 또한 서버에서 싱크에 대한 수락/거부를 할 수 있어야 함
• 오프라인/P2P 환경에서 동작해야 함. 서로간 데이터베이스에 대하여 1:1 완전 복제할 수 있어야 함.
• 클라이언트는 용량 문제처럼 모든 데이터를 가져올수도 있고, 안가져올 수도 있음.
  • 온라인 전용으로만 사용 가능하게 설계할 수도 있음
• 사용자가 자신만의 데이터베이스를 만들 수 있어야 함. 개발자 친화적이지 않아도 됨
  • 이 경우 schema를 바꾸면 모든 데이터 싹다 바꿔야 하는데 싱크하는데 문제가 발생할 수 있음
    • 마이그레이션?
• 일반적인 Relational Database에 대응할 수 있어야 함
  • 그러면 연동하기 쉬워짐
• 과거 기록에 대해 시점 고정 등을 위해 모든 operation이 정교하게 설계되어야만 함; reversible etc.
• 기존 데이터의 위치를 잘 트래킹해야함. document의 id가 바뀌었다면 연관된 놈도 잘 바뀌어야 함
• 오래된 데이터를 유기하는 방법도 생각해야함 (Storage Tiering)
• 각종 데이터를 캐싱해야 함
• BLOB 데이터를 별도로 저장할 수 있어야 함.
  • Loro와 같은 CRDT를 사용할 경우 각 파일을 비교해서 Merge 해야 함

Graph, Document database

Schemaless한 데이터베이스니까 결국 Document Database임 별개로 Graph Database에서 Node는 Document랑 걍 똑같고, Edge를 눈여겨볼 수 있는데, Document의 id 등이 뭐였는지 알 수 있을수도 있음

구현

스토리지

• SQLite(한 파일 혹은 여러 기능으로 나누기)
• FileSystem(directory에 json 쑤셔넣기) 양쪽다 히스토리 쓰던지 뭐 할수는 있는데 FS의 경우 git으로 트래킹할 수 있음

영역: Collections, Documents, Relations, Blob, History

ID

서버에서 생성하는 ID가 있고, 클라이언트가 생성하는 ID가 있음 서로 구별해야함. 서버와 싱크할때 서버에서 생성한 ID를 사용해야함 그럼 기존 ID는 어떻게 해야하나? 따로 별도 처리해야함 (known_for?)

싱크

일단 기본적으로 LWW (Last Writer Wins)로 처리해야함

서버<->클라이언트

• 클라이언트 발신, 서버 수신
  • 만약 특정 필드에 대해 수정했다면 이를 거절해야 함
  • 새로 생긴 Document는 서버에서 생성한 ID를 사용해야 함
• 서버 발신, 클라이언트 수신
  • 앵간하면 모두 받는다.
  • 만약 겹치는 처리가 있다면 사용자의 의도에 따라 처리해야 함

클라이언트<->클라이언트

싱크 시 완벽하게 복제해야함 어케하지

Notes

• CRDT: Fractional Indexing https://madebyevan.com/algos/crdt-fractional-indexing/
• Graph Database over SQLite: https://github.com/dpapathanasiou/simple-graph
• Document Database over SQLite:
  • https://github.com/stefanbielmeier/doculite (typescript implementation)
  • https://github.com/litedb-org/LiteDB (8.9k stars, worth it)