요즘 사용하는 stack 은 Python Flask + SQLAlsqlalchemy + Postgresql(+postgis) 이다. 기존 구현이 RubyOnRails + Mysql + elasticsearch 였다. 내가 지금 회사로 와서 Python 기반으로 변경 했다. (솔직히 내 처음 생각은 내가 그냥 Ruby 를 배우는 것이었다. ). 기존 구현들이 yaml 을 사용해서 Text Column 에 값을 저장한 경우가 많았다. 내가 이 것을 Postgresql 에서 지원하는 Jsonb 데이터 형으로 변경했다.  Yaml 내부 값 검색과 GIS 좌표의 거리 계산을 위해 elasticsearch  를 사용했는데, Jsonb 와 postgis 때문에 elasticsearch  를 사용할 필요가 없어졌다.

 이 이후 꽤 많은 구현이 Jsonb 를 이용했다. 뭔가 복잡한 데이터가 있을 때는 json 의 dictionary 형태를 그리고 array 형태가 필요할 때는 json 의 list 형태를 사용했다. 

그리고 오늘 Many to Many relationship 을 표시하기 위해 foreign key 형태의 Jsonb 를 사용했다. 그리고 깨달았다. 이건 좀 위험한 구현인 것 같다고. relationship  구현에는 기존 처럼 associative table 을 이용하는 형태로 구현해야 안전할 것 같다. 

  요즘 엑셀 비슷한 CSV Viewer + 엑셀함수 가능한 스프레드 시트 를 개발 중이다. 

우선 1차 목표가 엄청나게 큰 (1GB 이상) CSV 파일을 편집할 수 있는 기능을 우선적으로 개발중이다. 이를 위해 levelDB를 이용하려고 한다. 메모리의 한계로 엄청나게 큰 CSV 파일을 열게 되면 파일 크기몇 배의 메모리를 사용하게 된다. 이 때문에 일시적으로 데이터를 저장하려고 하는데 이 때 levelDB를 사용하려고 하는데 snappy 압축을 적용할 수 있다. 그러다 snappy 자체에 대해 관심을 가지고 되면서 여러 압축을 찾게 되었다. 

https://quixdb.github.io/squash-benchmark/ 에 가보면 압축속도, 압축해제 속도, 압축률을 비교해 볼 수 있다.


snappy : 압축속도과 압축해제속도를 중심으로 만들어진 압축알고리즘으로 Google 에서  압축률은 보통 원본의 50% 정도로 줄어든다. 

brotli : 이것도 구글에서 만들었는데, 웹사이트 content를 다운받을 때 사용하는 gzip 이나 deflate 의 대용으로 만든 것으로 보인다. 압축레벨을 지정할 수 있다.

zstd : 저 위 링크에 들어가서 오늘 처음으로 알게된 압축 알고리즘으로 facebook에서 만들었다. snappy 에 비해 속도가 늦은 감이 있지만 압축률이 높다. 




 github 가 MS 에 인수된 후, 사람들에게 선물을 하나 제공했다. 이젠 private repository를 무료로 제공하기로 했다. 

https://github.com/pricing

약간의 제한(3명까지 협업가능, Advanced code review tools 제공안함)이 있긴 하지만 개인 프로젝트를 하기에는 매우 좋은 plan 이다. 기존에 무료로 private repository 를 사용하기 위해서는 보통 Bitbucket 를 사용했었다.  

회사에서 github 를 많이 사용하고 많은 오픈소스들이 github web ui 가 손에 참 익었는데 이제는 github 로 개인 프로젝트를 옮겨야 할 것 같다.