2022년 8월 정보들

이 정보는 이전에 봤던 정보다 하지만 어딘가에 저장해야 할 것 같아서 다시 가져왔다.

DBA 였던 개발자가 SQLite를 메인 디비로 구축하는 이야기다. 그리고 비동기적으로 write를 맞춘다. Postgresql 을 이용하여 동기적으로 맞출 수도 있다는 것 같다.

Postgresql 의 엄청난 기능들을 다 쓰기에는 어려움이 있다. (복잡)

SQLite는 백엔드 프로젝트 바로 옆에서 사용하기 때문에 쿼리도 편하고 우리에게 필요한 기능만이 있다.

TailScale을 예로들자.

TailSacle은 처음에 DB를 사용하지 않았다. 텍스트파일에 JSON 객체를 쓴다는 것이다. 업데이트는 싱글 프로세스로 락을 걸고 수행했다고 한다. (2020년 기준, 참고문헌 https://tailscale.com/blog/an-unlikely-database-migration/)

이런 행위는 사실 엉클밥에게서도 이야기가 나오는데 (클린 아키텍처) 'Database를 뭘로 할까요?' 라는 질문에 일반적인 사람이라면 개발을 시작하기 전에 필수적으로 정해야 하는 아키텍처이지만, '나중에 정합시다' 라는 답변으로 사내 위키서비스를 만들었다고 한다. 처음에는 해시맵으로만 구현했으며, 테스트하기 적당했다. 나중에 '이제 정말 저장해야합니다. DB를 뭘로쓸까요?' 라는 질문에 파일에 적었다고 한다. 파일에 html을 저장해서 가져오기만 하면 되는 것이었다. 결국 개발이 끝나고 DB를 사용하지 않아도 될 것으로 결정하고 시간이 지나도 잘 쓰고 있다는 글이 있다.

TailScale도 마찬가지인 것이다. 문제를 해결하는 것만을 본 것. 여하튼, 스케일이 잘 안되는 것은 문제이지만, 중요한 것은 스케일이 문제될만한 서비스를 만드는 것일 것이다. TailScale은 성공하여 스케일이 필요해진 순간에 Database를 선택한다. etcd 라는 키벨류 DB를 선택한 듯 하다. mysql같은 것이 거론되었지만, 테스트가 느려지는 점 등을 문제점 삼았나보다. Go로 작성되어 있어 본인들의 테스트에 연결하여 직접사용할 수 있었다고한다. 도커, 목 따위는 없어도 됨. (뭔지 모르지만 본인들 언어가 Go라는 말인가?)

2022년 SQLite로 마이그레이션을 시도한다. (https://tailscale.com/blog/database-for-2022/) 내용을 보면서 많은 생각을 하게 된다. 어떤 기술에 대한 우위를 생각하지말고, 무엇을 해결할 것인지에 더 집중하는 내가 되어야겠다.

바로 SQLite를 선택한다. 그리고 데이터를 마이그레이션 한다. (https://tailscale.com/blog/database-for-2022/)