안녕하세요, @tmkor 입니다. 오늘은 공간 DB가 무엇인지에 대해 살펴보도록 하겠습니다.
공간 DB란?
공간 DB는 맛집, 자동차, 도로, 택지등과 같이 공간에 존재하는 자료를 저장하고 관리하는 특수 데이터베이스 입니다.
특수 데이터베이스인 이유는, 공간 자료를 담기 위한 특수한 데이터구조를 사용하기 때문입니다.
공간 DB가 왜 필요한가요?
빠르고 편리해서 기존에 하지 못했던 일을 할 수 있게 해주기 때문입니다.
먹스팀과 같이 맛집 위치를 관리하는 DB를 생각해 봅시다.
[먹스팀, 아마도 백 단에서 공간 DB를 사용하고 있을 것입니다.]
예를 들어, 맛집의 위치는 (위도, 경도)으로 구성되는 2차원 점(point)으로 표현할 수 있습니다. 이를 전통적인 자료형으로 관리한다면..
맛집 이름(varchar) | 위도(real) | 경도(real) |
---|---|---|
Sushi Way | 37.4690803 | 126.8659046 |
이렇게 위도와 경도를 별도로 관리하는 형식 표현할 수 있습니다.
관계형 DB에서 각 열(column)은 독립적인 관계를 가집니다. 즉, 위도와 경도는 서로 관계가 없는 별도의 자료인 것이지요.
하지만, 어떤 지점의 위도와 경도는 서로 관계가 없는 데이터 필드일까요? 아니지요, 우리는 위도와 경도 2개를 동시에 사용해서 특정한 지점을 가르킵니다. 앞선 예제처럼 별도로 관리하면 나중에 검색할 때에도 성능 측면에서 애로사항이 생기고, 여러모로 힘들어집니다.
그래서 컴돌이들은 공간 자료형(spatial datatype)을 개발하고, 이를 사용하는 공간 DB를 만들기 시작했습니다.
점(POINT) 자료형을 사용해서 위 예제를 표현하면 다음과 같습니다.
맛집 이름(varchar) | 위치(geography) |
---|---|
Sushi Way | POINT(37.4690803 126.8659046) |
또한, 공간 자료형을 사용하면 특정 위치에서 가장 가까운 맛집을 찾아줘(knn)라던지, 서울시 성동구(polygon)에 들어 있는(contain) 맛집을 찾아줘! 라던지의 공간 질의를 사용할 수 있습니다.
차회 예고
다음 시간에는 무료로 사용할 수 있는 관계형 공간DB인 MySQL과 PostgreSQL의 성능 비교를 해보도록 하겠습니다.
Cheer Up!
지도 api를 써보면 익숙하지 않을까 싶네요. 예전부터 퍼포먼스 비교에 대한 글은 한번씩 보기는 했지만 넌 커며설 버전의 비교는 더욱 궁금하네요. ㅎㅎ
예, 지도 API의 경우 wkt나 geo-json으로 왔다갔다 하는데, 모두 공간 데이터타입 입니다. 아마 지도 다뤄보신 분들은 익숙할 것입니다. ^^
성능 비교 조만간 올리도록 하겠습니다!