sns나 커뮤니티처럼 날짜, 텍스트 정도의 데이터만 들어가는 (금융처럼 집계가 필요없는) 성격의 테이블


게시판이라고 치면 이 게시판 이용률이 높아서 1년에 1천억건씩 데이터가 쌓이고 댓글을 1조개씩 쌓인다고 가정하자.


이러면 sql은 파티셔닝이니 샤딩이니 온갖 편법 동원하고, dc처럼 구table, 신table 이런 짓도 할 수도 있고 많이 고민해야 하잖아?


다양한 nosql 제품들 검색해보면 테이블의 데이터 무제한, 수 십, 수 백 테라 이상이상이어도 하나의 테이블에 디자인 가능하고 일관된 한자리 수 밀리세컨드 단위로 쿼리 가능


이렇게 광고하던데 nosql은 Count같은 집계 함수들 없으니 따로 필요한 것들만 직접 데이터 관리하고, 게시물은 번호, 텍스트, 글쓴이 이 정도의 텍스트 정도로 인덱싱만 되면 되니 확장성 생각하면 nosql로 쓰면 고민할 게 많이 줄고 편할 거 같은데


어때?


sql로 게시판 쓰다가 nosql 쓰면 뭐가 안되어서 구현하기 엄청 힘들다더라 뭐 그런 게 또 있으려나?


당장 생각나는 것은 count같은 함수가 없으니 기존 sql처럼 페이지 숫자 번호로 offset 방식 페이징 구현하기 어려울 거 같고


예를 들자면 검색어는 xxx, 바로 105번 페이지로 이동해서 목록 보기 같은 거 (sql도 뒷페이지로 갈 수록 읽어야하는 행 수가 늘어나서 성능 문제가 있겠지만 되긴 되니까)


nosql도 중간에 삭제될 경우가 없다면 따로 n회마다 중간중간 키값 따로 보관해서 이걸로 바로 원하는 번호의 페이지로 이동하는 페이징 흉내를 낼 수야 있겠지만...


INSERT, UPDATE 많은 게시판이면 nosql이 뒤로 갈수록 더 편하지 않을까 해서... 맞나?