DOI QR코드

DOI QR Code

Information Service of Real-time Emergency Room Location using MongoDB

MongoDB를 활용한 실시간 응급실 위치 정보 서비스

  • 신동진 (안양대학교 컴퓨터공학과) ;
  • 황승연 (안양대학교 컴퓨터공학과) ;
  • 장석우 (안양대학교 소프트웨어학과)
  • Received : 2022.10.24
  • Accepted : 2022.12.09
  • Published : 2022.12.31

Abstract

Currently, there are a total of 68 emergency rooms based on Seoul, South Korea, and there is a portal site that allows you to inquire the location of the emergency room, but it is difficult to use in an actual emergency situation because it consists of selecting a gu and a self-governing dong. In addition, it may be more efficient to go to the emergency room directly because you may miss the golden time necessary for survival in a situation where you call 119 and wait for the rescue team. Therefore, in this paper, we propose a service that can quickly search the location of the emergency room based on a specific location through various functions supported by MongoDB. After downloading emergency room location data based on Seoul Metropolitan City, storing it in MongoDB, processing the data through various processing techniques, and applying a spatial index, you can query the emergency room based on distance from a specific location in real time.

현재 대한민국의 서울특별시를 기준으로 응급실은 총 68개가 있으며, 응급실의 위치를 조회할 수 있는 포털 사이트가 존재하지만, 구와 자치동을 선택하는 방법으로 구성되어 실제 응급 상황에서는 활용하기가 어렵다. 또한, 119 구조대를 요청하고, 기다리는 상황에서 생존에 필요한 골든타임을 놓칠 수 있기 때문에 직접 응급실로 이동하는 방안이 더 효율적일 수도 있다. 따라서 본 논문에서는 MongoDB에서 지원되는 다양한 기능을 통해 특정 위치를 기준으로 빠르게 응급실의 위치를 조회할 수 있는 서비스를 제안한다. 서울특별시를 기준으로 응급실 위치 데이터를 다운로드하고, MongoDB에 저장한 후 다양한 처리 기술을 통해 데이터를 처리하고, 공간 인덱스를 적용하여 특정 위치에서 거리를 기준으로 응급실을 실시간으로 조회할 수 있다.

Keywords

Ⅰ. 서론

현재 대한민국의 서울을 기준으로 운영되고 있는 응급실의 개수는 총 68개로 25개의 구에 나누어져 운영되고 있다[1]. 이러한 응급실의 위치를 나타내주는 사이트인 중앙응급의료센터인 e-gen 웹사이트가 존재하여 검색하고자 하는 구와 자치동을 선택하면, 응급실의 위치를 알려준다[2]. 하지만, 실제 응급 상황이 발생하면, 은 응급 상황에 따른 당혹스러움으로 인해 적절히 판단을 할 수 없어 사이트에서 제공되는 메뉴들을 선택하여 응급실의 위치를 찾는 과정에 불필요한 시간이 소요될 가능성이 있다. 또한, 119 응급센터를 이용하여 구조대를 기다릴 수도 있지만, 골든 타임을 놓칠수도 있는 상황이 발생할 수 있다. 따라서 응급 상황이 발생할 경우 현재 위치를 기반으로 거리를 계산하여 가장 가까운 응급실의 위치를 파악하는 방안이 필요하다.

본 논문에서는 이런 문제점들을 해결하기 위해 실시간 처리가 가능하고, 공간 인덱스를 제공하는 MongoDB를 활용하여 현재 위치를 기반으로 빠르게 응급실의 위치를 조회할 수 있는 시스템을 제안한다. 1장 서론을 시작으로 2장에서는 관련된 기술과 이론들을 살펴보고, 3장에서는 구현된 시스템과 특정 위치를 기준으로 공간 인덱스를 활용하여 실제 응급실 위치를 검증한다. 마지막으로 4장에서 결론으로 마무리된다.

Ⅱ. 관련 기술 및 이론

1. MongoDB

MongoDB는 C++ 프로그래밍 언어로 작성된 오픈소스 데이터베이스이다. NoSQL(Not only SQL) 중 하나로 지원하는 데이터 모델은 문서로 정의된다. 문서형 모델이기 때문에 키와 해당된 값들의 집합인 필드들이 모여 하나의 문서를 구성한다[3]. 표 1은 MongoDB에서 사용하는 데이터 모델 형태를 보여준다.

표 1. 문서형 데이터 모델 포맷 예시

OTNBBE_2022_v22n6_63_t0001.png 이미지

Table 1. Example Format of a Documentary Data Model

표 1에서 보여준 것처럼 “name” 키와 해당하는 값이 “Anyang University”로 정의되어 하나의 필드가 구성되어 있으며, “address” 키의 값들은 배열 형태로 구성되고, “telephone” 키의 값도 문자열 형태로 작성되어 3개의 필드를 가지는 하나의 문서로 정의될 수 있다. RDBMS에서 사용하는 데이터베이스의 의미는 동일하고, 테이블은 컬렉션으로 정의되며, 컬럼과 해당하는 튜플의 데이터는 하나의 필드로 정의된다.

MongoDB는 JSON 기반의 Binary 형태로 저장되는 BSON 구조를 사용하기 때문에 스키마가 없다. 예를 들어 RDBMS에서 특정 컬럼과 해당하는 튜플의 데이터가 필요하다면, Alter Table 명령어로 테이블의 스키마를 우선적으로 수정하여야 하지만, MongoDB는 단순히 키와 값의 필드만 추가하면 되기 때문에 유연하게 스키마를 구성할 수 있다[4].

2. Geospatial Queries

MongoDB에서 지원하는 공간 인덱스는 2가지로 2dsphere 인덱스와 2d 인덱스가 존재한다. 2dsphere 인덱스는 WGS84 좌표계를 기준으로 위칫값들을 받으며, 구면기하학이 적용되어 3차원의 위칫값들을 내부적으로 2D 형태로 사용할 수 있다. 내부적인 알고리즘은 Google에서 제작한 S2 Geometry으로 쿼드 트리(Quad Tree)와 힐베트르 곡선(Hirbert Curve)를 사용한다[5,6].

2d 인덱스는 완전 평면상의 2차원 위칫값들을 받아 x, y축의 평면 지형을 기반으로 계산된다. 내부적인 알고리즘은 이진 트리(Binary Tree)를 기반으로 동작하여 Geo Hash가 적용되어 Base32 문자열 인코딩을 통해 위칫값들이 인코딩되고, 관련 공간 인덱스 쿼리를 하면, 디코딩되어 사용된다[7,8]. 표 2는 2dsphere 인덱스와 2d 인덱스에서 사용되는 예시 포맷을 보여준다.

표 2. 공간 인덱스 포맷 예시

OTNBBE_2022_v22n6_63_t0002.png 이미지

Table 2. Example of Geospatial Index Format

표 2와 같이 2dsphere 인덱스는 GeoJSON 형태를 따르며, 사용하는 type에는 Point, LineString, Polygon등 다양하게 지원한다. 특히, GeoJSON은 2015년 Internet Engineering Task Force (IETF)에서 정의한 포맷으로 RFC 7946 인증을 따르고 있어 표 2에서 보여주는 “geometry” 키의 값 형태(“name”, “location”)를 무조건 따라야 한다. 2d 인덱스는 Legacy 포맷으로 단순 JSON 형태이며, 해당 위치값들의 경도, 위도를 의미하는 “location” 키와 해당 위치값들의 이름을 의미하는 “name” 키로 정의된다.

Ⅲ. 시스템 소개

본 논문에서 개발된 MongoDB를 활용한 실시간 응급실 위치 정보 시스템 구조는 그림 1과 같다.

OTNBBE_2022_v22n6_63_f0001.png 이미지

그림 1. MongoDB를 활용한 실시간 응급실 위치 정보 시스템

Fig. 1. Real-time emergency room location information system using MongoDB

첫 번째, 공공데이터포털(www.data.go.kr)에서 제공되는 서울특별시 응급실 위치 정보 데이터를 다운로드한다. 두 번째, 다운로드된 데이터를 MongoDB로 입력하며, aggregate 함수를 통해 데이터를 처리하고, 2d 인덱스를 적용한다. 세 번째, 2d 인덱스가 적용된 컬렉션에 \(\begin{aligned}$geoWithin\end{aligned}\)\(\begin{aligned}$box\end{aligned}\) 연산자를 활용하여 데이터를 검증한다. 마지막으로, 처리가 완료된 컬렉션에 특정 위치(위도, 경도)의 좌표를 중심으로 \(\begin{aligned}$near\end{aligned}\) 연산자를 활용하여 거리순으로 쿼리를 실행한다. 쿼리 실행 결과를 구글맵을 활용하여 데이터가 정확하게 쿼리되었는지 최종 검증으로 마무리된다.

1. 데이터 수집

실시간 응급실 위치 정보 시스템을 구현하기 위해서는 데이터가 필요하며, 데이터는 공공데이터포털을 이용하여 다운로드한다. 서울특별시를 기준으로 다운로드하였으며, 제공되는 포맷은 JSON과 CSV 형태 두 가지를 지원한다. 그중 CSV 형태로 제공되는 데이터를 다운로드 받고, MongoDB로 데이터를 임포트한다.

2. 데이터 처리

그림 2는 수집된 서울특별시 응급실의 위치 데이터를 MongoDB로 데이터를 입력하는 과정을 보여준다.

OTNBBE_2022_v22n6_63_f0011.png 이미지

그림 2. MongoDB로 데이터를 입력하는 과정

Fig. 2. The process of entering data into MongoDB

그림 2는 파일로 구성된 데이터를 MongoDB로 입력 할 수 있는 mongoimport 명령어의 모습을 보여준다. “-- db” 옵션을 통해 데이터베이스는 seoul로 지정, “--collection” 옵션을 통해 컬렉션명은 emergency로 지정, “--host” 옵션을 통해 MongoDB가 설치된 곳의 주소와 포트 번호인 localhost:27017로 지정, “--type” 옵션을 통해 CSV 포맷으로 지정, “--file” 옵션을 통해 입력하고자 하는 파일명을 지정했다. 그림 3은 명령어를 통해 입력된 데이터의 구조와 값들을 보여준다.

OTNBBE_2022_v22n6_63_f0002.png 이미지

그림 3. 입력된 데이터의 키와 값 표현

Fig. 3. Representation of key and value of data entered

그림 3은 mongoimport 명령어를 통해 입력한 데이터 중 limit(1) 연산자를 활용해 하나의 문서만 조회한 결과로 병원의 이름, 위치, 전화번호, 주소 등 다양한 정보가 존재한다. 모든 키와 값의 출력은 가독성이 좋지 않기 때문에 특정 필드만 추출하는 처리 과정을 수행한다. 그림 3에서 소개된 다양한 필드 중 이름(name), 위치(location), 주소(address), 전화번호(telephone) 필드를 aggregate 함수를 통해 처리한다. aggregate 함수의 구성은 첫 번째로 \(\begin{aligned}$project\end{aligned}\) 연산자를 활용하여 출력하고자 하는 필드인 name, location, address, telephone 만 1로 설정하고, _id 필드는 0으로 설정하여 출력이 되지 않도록 지정한다. 두 번째로 \(\begin{aligned}$out\end{aligned}\) 연산자를 활용하여 refined_collections 컬렉션으로 처리 결과를 내보내게 된다. 처리 결과를 내보내고 show collections 명령어를 통해 컬렉션을 조회하면, refined_collections 컬렉션이 새롭게 생성된 것을 확인할 수 있다. 마지막으로 refined_collections 컬렉션에 limit(2) 연산자를 활용하여 2개의 문서를 조회하면, 정상적으로 처리가 되어 새로운 컬렉션으로 문서들이 가공되어 처리된 모습을 볼 수 있다. 그림 4는 데이터 처리에 사용된 명령어 모습을 보여준다.

OTNBBE_2022_v22n6_63_f0003.png 이미지

그림 4. 입력된 데이터의 키와 값 표현

Fig. 4. Data processing using aggregate functions

그림 5는 처리가 완료된 refined_collections 컬렉션에 createIndex() 함수를 통해 2d 인덱스를 적용하고, 인덱스가 정상적으로 적용되었는지 확인하는 getIndexes() 함수를 사용한 모습을 보여준다.

OTNBBE_2022_v22n6_63_f0004.png 이미지

그림 5. 2d 인덱스 적용 및 확인

Fig. 5. Apply and verify 2d indexes

3. 인덱스 검증

적용한 2d 인덱스가 정상적으로 동작하는지 확인하기 위해 특정 위칫값을 통해 문서 조회를 수행한다. 수행 방법은 \(\begin{aligned}$seoWithin\end{aligned}\)\(\begin{aligned}$box\end{aligned}\) 연산자를 통해 2개의 위칫값으로부터 사각형을 그렸을 때 해당 영역 내부에 존재하면 결과를 반환한다. 그림 6은 연산자를 활용했을 때 쿼리되는 실제 영역을 구글맵으로 표현한 모습이다.

OTNBBE_2022_v22n6_63_f0005.png 이미지

그림 6. \(\begin{aligned}$geoWithin\end{aligned}\)과 \(\begin{aligned}$box\end{aligned}\) 연산자를 활용한 구글맵 표현

Fig. 6. Google Maps representation using \(\begin{aligned}$geoWithin\end{aligned}\) and \(\begin{aligned}$box\end{aligned}\) operators

그림 7은 그림 6에서 표현된 점선 사각형의 위칫값 2개를 \(\begin{aligned}$box\end{aligned}\) 연산자의 입력값으로 지정하고, \(\begin{aligned}$geoWithin\end{aligned}\) 연산자를 통해 내부에 포함되어있는 문서가 어떤 것이 있는지 조회한 인덱스 검증을 수행하기 위한 쿼리문이다. 결과로는 사각형 내부에 위치하는 고려대학교안암병원 응급실의 관련 문서가 조회된다. 그림 6에서 표현한 사각형 내부에는 고려대학교안암병원이 위치하고 있으며, 해당 문서가 반환되었기 때문에 정상적으로 2d 인덱스와 관련 연산자들이 동작했음을 알 수 있다.

OTNBBE_2022_v22n6_63_f0006.png 이미지

그림 7. 인덱스 검증 수행 쿼리문

Fig. 7. Query statements to perform index validation

4. 최종 검증

2d 인덱스와 관련 연산자가 정상적으로 동작한 것을 확인했기 때문에 이제는 실제 위치 거리를 기준으로 2d 인덱스를 활용한 최종 검증을 수행한다. 3절 인덱스 검증에서 수행한 방법과 유사한 \(\begin{aligned}$near\end{aligned}\) 연산자를 사용한다. \(\begin{aligned}$near\end{aligned}\) 연산자는 거리를 기준으로 가장 가까운 문서부터 멀리 있는 문서 순서로 반환한다. 즉, 거리를 기준으로 오름차순으로 정렬하여 거리가 가장 짧은 문서부터 순차적으로 반환한다. 그림 8은 $near 연산자를 활용했을 때 쿼리되는 실제 영역을 구글맵으로 표현한 모습이다.

OTNBBE_2022_v22n6_63_f0007.png 이미지

그림 8. 최종 검증을 위한 강남구 중심 위칫값 구글맵 표현

Fig. 8. Google Maps representation of Gangnam-gu's central location for final verification

그림 9는 그림 8에서 표현된 중심 위칫값인 위도 37.4967, 경도 127.0629를 \(\begin{aligned}$near\end{aligned}\) 연산자의 입력값으로 지정하여 해당 위칫값으로부터 거리가 가장 가까운 순서에서 멀리 있는 순서의 오름차순으로 문서가 정렬되는 최종 검증을 수행하기 위한 쿼리문이다. 응급실 위치는 65개가 있기 때문에 전부 출력하지 않고 limit(3) 연산자를 활용하여 3개의 문서만 조회한다.

OTNBBE_2022_v22n6_63_f0008.png 이미지

그림 9. 최종 검증 수행 쿼리문

Fig. 9. Query statements to perform final validation

그림 8은 서울특별시 강남구 중심의 위칫값을 기준으로 베스티안서울병원, 강남세브란스병원, 삼성서울병원의 순서로 문서가 조회된 모습이다. 결과는 \(\begin{aligned}$near\end{aligned}\) 연산자를 활용했기 때문에 거리가 가까운 순서에서 멀리 있는 순서로 해석된다. 그림 10, 11, 12는 구글맵을 통해 중심 위칫값에서 실제로 거리가 가까운 순서로 반환된 것이 정확한지에 대한 최종 검증을 수행한 모습이다.

OTNBBE_2022_v22n6_63_f0009.png 이미지

그림 10. 쿼리문에 의해 반환된 첫 번째 병원의 응급실 거리

Fig. 10. Emergency room distance from the first hospital returned by the query statement

OTNBBE_2022_v22n6_63_f0010.png 이미지

그림 11. 쿼리문에 의해 반환된 두 번째 병원의 응급실 거리

Fig. 11. Emergency room distance from the second hospital returned by the query statement

OTNBBE_2022_v22n6_63_f0012.png 이미지

그림 12. 쿼리문에 의해 반환된 세 번째 병원의 응급실 거리

Fig. 12. Emergency room distance from the third hospital returned by the query statement

그림 10은 그림 9에서 반환된 3개의 문서 중 첫 번째 문서에 해당하는 베스티안서울병원의 응급실 실제 위치를 구글맵을 통해 측정한 모습으로 524.32m로 표현된다.

그림 11은 그림 9에서 반환된 3개의 문서 중 두 번째 문서에 해당하는 강남세브란스병원의 응급실 실제 위치를 구글맵을 통해 측정한 모습으로 1.47km로 표현된다.

그림 12는 그림 9에서 반환된 3개의 문서 중 세 번째 문서에 해당하는 삼성서울병원의 응급실 실제 위치를 구글맵을 통해 측정한 모습으로 2.41km로 표현된다. 그림 10, 11, 12를 통해 2d 인덱스의 \(\begin{aligned}$near\end{aligned}\)연산자를 활용하여 거리순으로 정확하게 서울특별시 응급실의 위치가 포함된 문서들이 반환된 것을 확인할 수 있다.

Ⅳ. 결론

본 논문에서는 공공데이터에서 서울특별시 응급실 위치 정보 데이터를 수집하고, MongoDB에서 데이터를 가공/처리하여 공간 인덱스를 부여했다. 그리고 관련 연산자를 활용하여 인덱스의 검증을 수행하고, 특정 위치에서 거리를 기준으로 정렬하여 응급실을 찾는 시스템을 제안한다. 공간 인덱스의 최종 검증을 통해 조회한 결과 정상적으로 거리순에 따라 오름차순으로 응급실의 위치가 출력되는 것을 확인할 수 있다. 향후 Python 프로그래밍을 통해 folium 라이브러리와 같은 지도 API를 사용하여 웹과 앱에서 사용자가 현재 위치를 입력하면, 해당 시스템의 내부 로직을 통해 최단 거리에 위치한 응급실 위치 정보를 알려주는 연구를 진행하고자 한다.

References

  1. Number of emergency medical institutions and emergency room operating institutions (by city and province), "https://kosis.kr/statHtml/statHtml.do?orgId=411&tblId=DT_41104_411&conn_path=I3"
  2. Central Emergency Medical Center Emergency Room Location Portal Site, "https://www.e-gen.or.kr/egen/search_emergency_room.do"
  3. Seung-Yeon Hwang, Dong-Jin Shin, Kwang-Jin Kwak, Jeong-Joon Kim, Jeong-Min Park, "Real-time Processing of Manufacturing Facility Data based on Big Data for Smart-Factory", The Journal of the Institute of Internet, Broadcasting and Communication (IIBC), Vol. 19, No. 5, pp. 219-226, Oct 2019. DOI: https://doi.org/10.7236/JIIBC.2019.19.5.219
  4. Kwang-Jin Kwak, Ha-Young Yoon, Dong-Yoon Shin, Dong-Jin Shin, Jeong-Min Park, Jeong-Joon Kim, "Spatial Operator for Spatial MongoDB", The Journal of the Institute of Internet, Broadcasting and Communication (IIBC), Vol. 18, No. 6, pp. 237-242, Dec 2018. DOI: https://doi.org/10.7236/JIIBC.2018.18.6.237
  5. MongoDB 2dsphere Indexes Documentation, "https://www.mongodb.com/docs/manual/core/2dsphere/"
  6. Longgang Xiang, Juntao Huang, Xiaotian Shao, Dehao Wang, "A MongoDB-Based Management of Planar Spatial Data with a Flattened R-Tree", ISPRS International Journal of Geo-Information, Vol. 5, No. 7, pp. 119, July 2016. DOI: https://doi.org/10.3390/ijgi5070119
  7. MongoDB 2d Indexes Documentation, "https://www.mongodb.com/docs/manual/core/2d/"
  8. Sam-Keun Kim, Kwang-Chae Kim, Hyeon-Woo Kim, Woo-Jin Jeong, Ahn-Jae Geun, "A Self-Service Business Intelligence System for Recommending New Crops", Journal of the Korea Academia-Industrial cooperation Society(JKAIS), Vol. 22, No. 3, pp. 527-535, 2021. DOI: https://doi.org/10.5762/KAIS.2021.22.3.527