왜 DB 테이블 파티셔닝을 도입했나프롭테크 회사에서 부동산 중개사들이 사용하는 솔루션, 내부 부동산 투자 개발팀이 사용하는 솔루션을 만들고 운영주입니다. 이러한 솔루션을 위해 부동산 공공데이터 베이스를 구축, 운영중인데 아직 경험이 부족하여 더 나은 서비스를 제공하기 위해 DB 에 대해 공부하고 있습니다. 고작  1+a 년동안 부동산 데이터를 다룬 제가 파악한 특성은 (1) 데이터 양(Volume)이 많다, (2) 그렇게 양이 많은 데이터가 다양하다는 점입니다.얼핏보면 빅데이터의 3V(Volume, Velocty,  Variety) 가 생각나는 특징이죠? 하지만 엄연히 말하자면 다릅니다. 양이 많은 것은 맞지만 TB 단위로 많은 것은 또 아니고, 다양하지만 데이터의 형태(정형, 반정형, 비정형) 가 다양..

프롭테크 회사를 다니다보니 지도 서비스를 자주 다룹니다.당연히 클라이언트 개발자가 지도 서비스를 더 많이 다루고 고생하는 분야이지만 필지, 행정동, 법정동의 모양정보(이하 공간데이터)를 뿌려주는 역할은 백엔드에서도 해야할 일이 있습니다. 백엔드 개발자라면 공간데이터 타입을 어떻게 DB 에 보관할지 궁금하는지, 내부 처리 성능은 어떠한지 궁금할 것입니다.이것 역시 다루고 싶은 주제지만 이 글에서는 공간데이터를 지도에 뿌리는 정도가 관심사이기 때문에 어떻게 보관하든 큰 문제는 아니겠죠.  Geometry 정보를 전달하는 방식그렇다면 DBMS 에 보관된 공간데이터를 어떤식으로 뿌릴까를 이야기해보겠습니다.여러 부동산 서비스의 클라이언트-서버 통신을 분석해보면 공간데이터를 뿌리는 방식은 크게 두가지로 나뉘는것 같..