Summary
이 연구 비교 관계형 및 비-관계형 (NoSQL) 표준화 의료 정보 시스템. 복잡 한 계산 같은 데이터베이스 관리 시스템 (DBMS)을 쿼리 응답 시간이 배로 크기의 데이터베이스를 사용 하 여 계산 됩니다. 이러한 결과 다른 시나리오와 문제 각 데이터베이스 접근 방법의 적합성의 토론 도움이.
Abstract
이 연구는 관계형 쿼리 계산 복잡도 평가 하는 프로토콜 및 비-관계형 (NoSQL (뿐만 아니라 구조적 쿼리 언어)) 표준화 전자 건강 기록 (EHR) 의료 정보 데이터베이스 시스템 (DBMS). 그것은 사용 하 고 3 배 크기의 데이터베이스, 즉 데이터베이스 저장 5000, 10000 그리고 20000 현실적인 세 가지 다른 데이터베이스 관리 시스템 (DBMS)에서 EHR 추출 물, 표준화: 관계형 MySQL 개체-관계형 매핑 (ORM), 문서 기반의 NoSQL MongoDB, 그리고 네이티브 확장 마크업 언어 (XML) NoSQL 존재.
6 증가 하는 복잡 한 쿼리를 평균 응답 시간 계산 된 고 결과 NoSQL의 경우 선형 동작을 보였다. NoSQL 필드에 MongoDB 존재 보다 많은 아첨 선형 슬로프를 제공합니다.
NoSQL 시스템 일관성과 NoSQL 데이터베이스에 저장 된 데이터의 효율성에 영향을 주지 해야 의료 정보의 업데이트 정책의 특별 한 특성으로 인해 표준화 된 의료 정보 시스템을 유지 하기 위해 더 적절 한 수도 있습니다.
이 프로토콜의 한계가 상 관계형 매핑 (팔) 같은 데이터와 향상 된 관계형 시스템의 직접적인 결과의 부족 이다. 그러나, 그 두 배로 크기 데이터베이스 결과의 보간 문학에서 제시 하 고 다른 게시 된 결과 NoSQL 시스템은 더 많은 특정 시나리오 및 문제 해결에 적절 한 수 있습니다 제안 합니다. 예를 들어 NoSQL EHR 추출 임상 연습, 또는 판 및 시각화, 또는 목표 뿐만 아니라 상황에 사용 된 쿼리 의료 정보를 뿐만 아니라 정확 하 게 그것의 원래 모양에서 EHR 복원 같은 문서 기반 작업에 대 한 적절 한 있을 수 있습니다.
Introduction
NoSQL (뿐만 아니라 SQL) DBMS 최근 대신 전통적인 관계형 DBMS (RDMBS)에 등장. RDBMS는 데이터 수십 년 동안 데이터베이스 시스템에 저장 하는 방법을 지배 있다. 잘 공부 하 고 이해 관계형 대 수와 미적분학 효율성과 RDBMS1의 일관성을 보장 했습니다. NoSQL 시스템 관계형 시스템에 대 한 대체 될 수 없는 것입니다 하지만 그들은 특정 시나리오에서 조건 하에서 여러 advantageously 행동할 수 있었다.
특정 시나리오의 일부 데이터베이스 유지 관리 및 의료 정보를 저장 하는 데 사용 하는 전자 건강 기록 (EHR) 시스템을 설계할 때 발생 합니다. 상호 운용성 및 연습, 여러 국제 표준 ISO/EN 13606, openEHR, 및 HL72,,34등 지속 가능한 있어야,5 표준화 EHR 추출 물 사용 되었습니다.
ISO/EN 13606, openEHR 등 여러 기준을 참조 모형 (RM)으로 표현 하는 추상화의 전형이라는 특수 한 데이터 구조는 두 가지 서로 다른 수준으로 정보와 지식을 분리 했습니다. 이 분리는 종종 듀얼 모델 이라고 하 고 그것 EHR 시스템을 전체 EHR 시스템 프로그래밍을 하지 않고, 그리고 결과적으로, 진화를 의미상으로 운용 하 고 의료 지식을 관리 하 고 실제로6 지속 가능한 . 그러나, 표준화 된 EHR 시스템에서 구현 하는 듀얼 모델 하려면 정보 특정 구조를 따르는이 방식으로 시스템의 데이터베이스 지 속성 수준 설계7깊은 결과가지고 합니다.
개체 관계형 매핑 (ORM)8 은 관계형 데이터베이스 패러다임을 사용 하 여 EHR 시스템을 구현 하기 위해 한 방법입니다. ORM은 철저 하 게 표준화 된 EHR 추출 XML (확장 마크업 언어) 파일 시스템에서 사용 하는 관계형 데이터베이스의 구조를 매핑합니다. ORM는 철저 하 게 표준화 된 EHR 추출 XML 파일의 구조에 따라 많은 관계형 테이블을 생성 합니다. 이러한 관계형 테이블 많은 외래 키를 통해 관련 고 결과 시스템은 매우 효율적으로 되지 않을 수 있습니다.
ORM 여러 관계형 개선 제안 되었습니다. openEHR의 노드 + 경로9 Blob (이진 대형 개체)로 전체 추출 XML 파일의 직렬화 하위에 의해 관계형 테이블의 수를 줄입니다. 그러나,이 단순화는 복잡 한 쿼리를 손상 하는 복잡 한 검색 논리를 발생 합니다. 상을 관계형 매핑 (팔)10 전형, 전형 및 관계형 테이블 간의 매핑을 기반으로 새로운 관계형 스키마를 구축에 힘입어 데이터베이스 모델을 생성 합니다. 따라서, 일부 EHR 추출의 비 의료 정보는 손실 됩니다.
많은 문서 기반의 NoSQL 데이터베이스는 원래 XML 또는 JSON (자바 스크립트 객체 표기법)을 존중 하는 전체 Blob으로 전체 문서 저장 형식. 즉, 관계형 테이블이 생성 됩니다. 이러한 NoSQL 데이터베이스 스키마 있고 중 조인 또는 (산) 속성11, 즉, 원자성, 일관성, 격리, 또는 내 구성을 지원 하지 않습니다. 결과적으로, 그들은 수 있습니다 매우 효율적으로 동일한 요소를 참조 하는 문서 요소 또는 간접 링크를 활용 하 여 다른 문서. 일관성을 유지 하기 위해 참조 된 문서의 전체 순차적으로 처리 해야 하기 때문에 발생 합니다. 그러나, 비-관계형 데이터베이스는 DBMS에 의해 수행 하는 주요 작업은 문서 기반 작업 하는 경우에 아직도 적절 한 수 있습니다. 이 때문에 데이터가 남아 있을 수 있습니다 폼에 더 밀접 하 게 가깝게 문서 기반의 NoSQL 데이터베이스를 사용 하 여 그것의 진정한 표현을 EHR 의료 문서 (토론 섹션 참조)에 의해 수행 하는 특별 한 유지 정책 때문 이기도 하지만.
이 방법의 목적은 세 가지 다른 Dbms를 사용 하 여 표준화 된 EHR 시스템의 지 속성 계층의 구현을 비교 몇 가지 실험을 선보일: 한 관계형 (MySQL)와 두 개의 NoSQL (MongoDB 문서 기반 그리고 네이티브 XML). 그들의 복잡 한 계산 되었습니다 계산 하 고 3 개의 다른 증가 크기 데이터베이스 및 6 다른 복잡성 증가 하는 쿼리를 사용 하 여 비교. 세 가지 데이터베이스 서버를 설치 하 고 쿼리 실행 되어 같은 컴퓨터에서 로컬로 구성 되었습니다. 기술적인 세부 사항에 대 한 테이블의 자료 를 참조 하십시오.
동시성 실험 또한 관계형 MySQL과 NoSQL MongoDB Dbms의 성능을 비교 하기 위해 실시 되었습니다. 설명된 ORM 개선 (노드 + 경로 및 팔)도 문학10관련 적절 한 결과 사용 하 여 비교 되었습니다.
데이터베이스 관리 시스템은 가속 속도로 지속적으로 진화 하고있다. 아무도 유일한 기존 패러다임은 관계형 모델이 지 수 개발에 대 한 생각 것 이다. 예제를 참조 하십시오 예를 들어12, ACID 속성을 유지 하는 응답 시간 향상 된 관계형 데이터베이스를 구현 하는 모델 제안 어디.
Protocol
1. 3 개의 두 배 크기의 표준화 된 EHR 추출 데이터베이스를 저장 하는 관계형 MySQL DBMS 구축
- 가져오기는 W3C (World Wide Web 컨소시엄) XML 스키마에 해당 하는 ISO/EN13606 RM 및 ISO21090 데이터 형식에는 '자바 IDE' (통합 개발 환경).
참고: ISO 국제 표준 기구에 대 한 의미합니다. EN 유럽 표준에 대 한 의미합니다. - JAXB (자바 XML 바인딩); IDE에 플러그인 실행 이 EHR 추출 XML 파일의 요소에의 구조에 해당 하는 자바 클래스를 생성 합니다.
- JPA 레이블 생성 하는 Java 클래스를 수동으로 태그. 이러한 분류는 카디널리티 및 MySQL 데이터베이스의 관계형 테이블 사이 다른 관계를 참조 하십시오.
- IDE에 JPA (자바 지 속성 API)의 라이브러리를 가져오고 태그 자바 클래스에서 MySQL 데이터베이스를 구축 하는 방법을 실행.
- XML 파일 5000, 10000 그리고 20000 현실적인 EHR 추출 물과 세 가지 디렉터리를 만듭니다.
- XML 추출 5000 추출 디렉터리의 모든 추출 물에 MySQL DBMS를 JPA 메서드를 실행 합니다.
- 한 번 10000 추출 디렉터리와 함께 한 번 20000 추출 디렉터리 1.6 단계를 두 번 반복 합니다.
2. 3 개의 두 배 크기의 표준화 된 EHR 추출 데이터베이스를 저장 하는 NoSQL MongoDB DBMS 구축
- 프로세스 각 5000, 10000 그리고 20000 현실적인 EHR 추출 XML 파일 XML 파일 json.org.XML 같은 JSON 파일을 변환 하는 표준 프로그램을 포함 하는 세 가지 디렉터리의. 5000, 10000, 20000 JSON 파일 세 개의 디렉터리를 생산 한다.
- 시작 MongoDB GUI (그래픽 사용자 인터페이스, 테이블의 자료를 참조).
- DOS (디스크 운영 체제) 시스템 창에서 mongod 프로그램을 실행 하 여 MongoDB 2.6 서버 를 시작 합니다.
- MongoDB GUI 27017 포트를 사용 하 여 로컬 호스트 서버에 연결 합니다.
- "연결" 메뉴를 선택 합니다.
- 연결에 대 한 이름을 작성 (예를 들어 ' 첫 번째').
- DB 서버 텍스트 상자에 localhost:27017를 작성 합니다.
- "연결" 단추; 현재 데이터베이스와 나무는 왼쪽에 표시 됩니다.
- 추출 물 5000 표준화 EHR을 포함 하는 데이터베이스를 구축 합니다.
- 왼쪽에 나무의 상단에 연결의 이름을 클릭 하십시오.
- "파일" 메뉴를 선택 합니다.
- "데이터베이스 추가"를 선택 하십시오.
- 나타나는 대화 상자에서 데이터베이스의 이름을 입력 합니다.
- 클릭 확인입니다.
- 추출 물 5000 표준화 EHR을 포함 하는 컬렉션을 빌드하십시오.
- 왼쪽 트리에서 데이터베이스의 이름을 클릭 하십시오.
- 메뉴 "데이터베이스"를 선택 합니다.
- "AddCollection"를 선택 하십시오.
- 나타나는 대화 상자에 컬렉션의 이름을 입력 합니다.
- " 생성"을 클릭 합니다.
- 컬렉션의 이름을 클릭 하십시오.
- "가져오기" 메뉴를 선택 합니다.
- 라디오 단추를 선택 하십시오'JSON-몽고 쉘 / / mongoexport ".
- "다음"을 클릭 합니다.
- "소스 파일 추가" 버튼을 누릅니다.
- 대화 상자를 사용 하 여 컴퓨터에 이동 합니다.
- 오픈 5000 JSON를 포함 하는 디렉터리 파일을 추출 합니다.
- 디렉터리에 있는 모든 파일을 선택 합니다.
- "열기"를 누릅니다. JSON 파일 목록 가져오기 대화 상자에 표시 됩니다.
- 누르십시오 "다음"; 데이터베이스에 새 컬렉션의 미리 보기가 왼쪽에 나타납니다.
- "다음"을 누릅니다.
- "가져오기 시작"을 누릅니다. 가져오기의 진행 경과 시간과 가져온 파일의 수를 나타내는 왼쪽 아래로 나타납니다.
- 단계 5와 추출 10000 표준화 EHR의 컬렉션을 구축 하는 6 단계를 반복 합니다.
- 단계 5와 추출 물 20000 표준화 EHR의 컬렉션을 구축 하는 6 단계를 반복 합니다.
3. 빌드는 NoSQL DBMS 저장 3 두 배 크기의 표준화 EHR 추출 데이터베이스에 존재
- 존재 하는 데이터베이스를 시작 합니다.
- 데이터베이스의 아이콘을 사용 하는 Java 관리자 클라이언트를 엽니다.
- 관리자 암호를 입력 합니다.
- "연결" 버튼을 누릅니다.
- 추출 물 5000 표준화 EHR을 포함 하는 컬렉션을 빌드하십시오.
- 도구 모음에서 "만들기 새 컬렉션" 메뉴를 선택 합니다.
- 나타나는 대화 상자에서 새 컬렉션의 이름을 입력 합니다.
- 클릭 "적용"; 새 컬렉션 표시 됩니다.
- 컬렉션의 이름을 선택 합니다.
- 도구 모음에서 "데이터베이스에 파일 저장" 메뉴를 선택 합니다.
- 대화 상자를 사용 하 여 컴퓨터에 이동 합니다.
- 5000 표준화 된 XML 추출 파일이 포함 된 디렉터리를 선택 합니다.
- "파일 또는 저장 하는 디렉터리를 선택" 버튼을 클릭 합니다. Note는 대화 상자가 나타납니다 파일 저장 되는 진행률을 표시 하 고 생성 하는 데이터베이스의 백분율.
- 추출 물 10000 표준화 EHR을 포함 하는 컬렉션을 구축 하는 5 단계를 반복 합니다.
- 추출 물 20000 표준화 EHR을 포함 하는 컬렉션을 구축 하는 5 단계를 반복 합니다.
4. 디자인 고 3 관계형 MySQL 데이터베이스에서 6 복잡성 증가 하는 쿼리 실행
- EHR 추출 물에서 사용 하는 전형에 따라 6 복잡성 증가 하는 쿼리를 디자인 합니다.
- MySQL 데이터베이스에 첫 번째 쿼리는 SQL 스크립트를 프로그램. SQL 추출 표준화 (전형)으로 인해 MySQL 데이터베이스의 특별 한 구조에 적응 해야 합니다. 데이터베이스 추출의 전체 구조를 매핑합니다. 그 결과, SQL 쿼리는 다소 복잡 합니다.
- 비록 대부분의 인덱스는 DBMS에 의해 자동으로 만들어지는 인덱스 그들에 만들어진 경우 쿼리 응답 시간을 빠르게 것 이라고 다음 이러한 인덱스를 구성 하는 데이터베이스의 특성을 식별 합니다.
- 쿼리가 아닌 자동으로 만들어진된 인덱스를 경우 수동으로 빌드.
- MySQL 서버 (보조 그림 1)에 연결 합니다.
- 선택 하 고 왼쪽에 데이터베이스 이름을 클릭 하십시오.
- 선택한 인덱싱된 필드 있는 관계형 테이블을 클릭 합니다.
- "구조" 탭을 클릭 하십시오.
- 선택한 인덱스 구축 될 열을 클릭 합니다.
- "인덱스"를 클릭 하십시오. Note는 인덱스를 작성 하면 SQL 문장, 나타나고 문장 성공적으로 구축 되었습니다 내용의 메시지가 나타납니다.
- 첫 번째 쿼리를 실행 합니다.
- 선택 하 고 왼쪽에 데이터베이스 이름을 클릭 하십시오.
- "SQL" 탭을 클릭 하십시오.
- 작성 하거나 첫 번째 쿼리의 SQL 코드를 붙여 넣습니다 ( 보충 그림 2참조).
- "계속"을 누릅니다. 참고 쿼리 실행 시간에 포함 된 메시지와 함께 결과 목록의 첫 번째 화면이 나타납니다.
- 5 번 실행을 반복 하 고 평균 응답 시간 계산.
- 쿼리 2-6 단계 5를 반복 합니다.
- 세 번, 5000, 10000, 20000 추출 데이터베이스와 전체 프로세스를 할.
5. 디자인 고 3 NoSQL MongoDB 데이터베이스에 6 복잡성 증가 하는 쿼리 실행
- MongoDB GUI를 실행 ( 재료의 표참조).
- DOS 시스템 창에서 mongod 프로그램을 실행 하는 MongoDB 2.6 서버 시작 ( 보충 그림 3참조).
- 따라 단계 2.4 MongoDB GUI 27017 포트를 사용 하 여 로컬 호스트 서버에 연결할.
- 선택한 왼쪽에 MongoDB 데이터베이스를 확장 합니다.
- 컬렉션을 선택 합니다.
- 도구 모음에서 "컬렉션" 메뉴에서 클릭 합니다.
- 첫 번째 MongoDB 쿼리를 실행 합니다.
- "쿼리 작성기" 버튼을 두 번 누릅니다.
- "쿼리 필드" 쿼리 작성기 오른쪽의 두 번 클릭.
- 쿼리 패널 ( 보충 그림 4참조)의 필드 텍스트 상자에 MongoDB 쿼리의 필드를 작성 합니다.
- 쿼리 패널의 값 텍스트 상자에 MongoDB 쿼리 값을 작성 합니다.
참고:이 쿼리 {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText 같은 것 이어야 한다. "값:"Descripcion"}. 필드와 값 인용 하 고 세미콜론으로 구분 됩니다. - 쿼리 작성기의 투영 필드를 두 번 클릭
- 프로젝션 텍스트 상자에 첫 번째 투영을 작성 ( 보충 그림 5참조).
- 프로젝션 필드 새로운 프로젝션 textbox를 추가를 두 번 클릭.
- 프로젝션 텍스트 상자에 두 번째 투영을 작성 합니다.
참고: 투영 쿼리에서 검색 하는 문서의 부분을 선택 합니다. 이 {"ns3:EHRExtract 같은 것을 해야. allCompositions.content.items.parts.parts.value.value": 1} 및 {" n s 3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1} - 쿼리를 실행 하려면 파란색 재생 버튼을 클릭 합니다.
- 쿼리 코드 탭에서 쿼리 코드를 시각화 합니다.
- 설명 탭에서 결과의 세부 정보를 볼: 결과의 수, 실행 시간 (밀리초)입니다.
- 확인, 확장, 하 고 결과 탭에서 결과 검사.
- 추가 쿼리의 처리 하는 것이 필요한 경우 결과 처리 하는 쿼리 및 메서드 MongoDB Java 드라이버와 자바 프로그램을 작성 합니다.
- 5 번 실행을 반복 하 고 평균 응답 시간 계산.
- 5.7 6 쿼리를 통해 나머지 2 단계 할.
- MongoDB 데이터베이스를 추출 하는 5000, 10000, 20000 전체 프로세스를 반복 합니다.
6. 디자인 고 3에서 실행 NoSQL 데이터베이스 6 증가 복잡성 쿼리 존재
- 존재 DBMS를 시작 합니다.
- 자바 관리 클라이언트를 엽니다.
- ""데이터베이스에 연결단추를 누릅니다.
- 데이터베이스를 선택 하 고 그것을 클릭.
- "XPath를 사용 하 여 데이터베이스를 참조 하십시오"; 메뉴 클릭 상담 대화 상자가 나타납니다.
- 첫 번째 XPath 쿼리 실행 ( 보충 그림 6참조).
- 작성 하거나 대화 상자의 상단 부분에 첫 번째 쿼리의 XPath 코드를 붙여 넣습니다.
- 대화 상자의 도구 모음에서 "실행" 메뉴에서 클릭 합니다.
- 대화 상자의 아래 부분에 "XML" 탭을 사용 하 여 XML 결과 보기.
- 결과 및 컴파일 및 실행 시간 대화 상자의 맨 아래에 보기 수입니다.
- 5 번 실행을 반복 하 고 평균 응답 시간 계산.
- 쿼리 2 6-6 단계를 반복 합니다.
- 5000, 10000, 20000 추출 존재 데이터베이스 전체 과정 3 번 마십시오.
7. 디자인 하 고 MySQL 데이터베이스를 추출 하는 MongoDB 5000를 사용 하 여 동시성 실험 실행
참고: 존재 데이터베이스 이전 실험에서 더 성능 때문에 시점에서 실험에서 제거 되었습니다.
- (일반적으로 몇 초)에서 5000 추출 데이터베이스를 사용 하 여 이전 실험에서 3 개의 짧은 시간 응답에 포함 된 쿼리를 선택 합니다.
- 식별 하 고 필요한 경우 수동으로 해당 쿼리에 대 한 적절 한 특성 인덱스를 작성 합니다.
- 자바 다중 스레드 응용 프로그램 2, MySQL에 대 한 하나; MongoDB에 대 한 다른 각 응용 프로그램은 1 단계에서 선택한 각 쿼리에 대 한 하나의 3 개의 다른 우선 순위 스레드가 있을 것 이다.
- 실행 하 고 있는 CPU (중앙 처리 장치) 배포를 사용 하 여 각 스레드 (쿼리)에 대 한 계산.
- 각 10 분 기간 동안 5 번 실행 버튼 클릭 하면 각 다중 스레드 응용 프로그램을 실행 하 고 가장 실행된 (가장 높은 우선 순위) 계산 평균 처리량과 평균 시간 응답의 3 개의 쿼리를 쿼리.
- 쿼리 실행, 우선순위와 실행 시간에에서 보기.
- 평균 처리량 및 3 개의 질문의 각각의 평균 응답 시간을 계산 합니다.
Representative Results
6 다른 쿼리 수행 현실적인 표준화 EHR 추출 물을 포함 하 여 그들의 이름, 초기 및 최종 날짜와 심각도, 환자의 문제에 대 한 정보를 포함 하는 표 1에 표시 됩니다.
각 DBMS의 3 배로 크기 데이터베이스에서 6 쿼리의 평균 응답 시간 표 2-4에 나와 있습니다. 그림 1-6 동일한 결과 그래픽으로 표시 (통지 수직 축이이 수치를 통해 매우 다른 비늘을 사용).
복잡 한 계산의 강한 선형 동작 3 데이터 집합 사용의 상대적으로 작은 크기에 따른 적절 한 주의 함께 비록 NoSQL 데이터베이스의 모든 쿼리를 통해 분명 하다. 그러나, 관계형 ORM 데이터베이스 불분명 선형 동작을 보여 줍니다. MongoDB 데이터베이스는 존재 데이터베이스 보다 훨씬 아첨 슬로프.
문학에서 출판 하는 소개에서 설명 하는 향상 된 관계형 시스템으로 결과 표 5에서 찾을 수 있습니다. MongoDB 결과 표 3 에서 비슷한 쿼리 및 표 5 에서 팔 결과의 데이터베이스 크기를 인터폴 레이 팅 두 데이터베이스 시스템, 1 분기에서와 동일 하지만 3 분기에 MongoDB를 하시 더군요.
동시성 실험의 결과 표 5 및 표6에서 찾을 수 있습니다. MongoDB은 처리량과 응답 시간에서 모두 MySQL을 친다. 사실, MongoDB 잘 동작 하는 절연, 보다 동시성 및 동시 실행에 인상적인 데이터베이스로 서.
그림 1 : 알고리즘 복잡성 ORM MySQL, MongoDB의 쿼리 q 1과 q 4에 대 한 DBMS를 존재 하 고. 이 그림7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 q 1과 q 4에 대 한 데이터베이스를 추출. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
그림 2 : 쿼리 q 2에 대 한 ORM MySQL DBMS의 알고리즘 복잡성. 이 그림은 10000 및 20000 EHR 추출 ORM MySQL 데이터베이스 쿼리 q 2에 대 한 5000, 초에서 응답 시간을 보여 줍니다. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
그림 3 : 알고리즘 복잡성 MongoDB의 쿼리 q 2와 q 5에 대 한 DBMS를 존재 및. 이 그림7 크리에이 티브 커먼즈 라이센스를 사용 하 여에서 수정 되었습니다 (에 의해 http://creativecommons.org/licenses/ / 4.0)에서는 응답 시간 초 5000, 10000 그리고 20000 크기 EHR 각 DBMS 및 쿼리 q 2와 q 5에 대 한 데이터베이스를 추출 하는 고. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
그림 4 : 쿼리에 Q3 Q5 ORM MySQL DBMS의 알고리즘 복잡성. 각 DBMS 및 쿼리 q 3와 Q5에 대 한 데이터베이스를 추출 하는 10000 그리고 20000 크기 EHR 5000, 초에서 응답 시간을 표시 합니다. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
그림 5: 존재와 MongoDB 쿼리 q 3에 대 한 DBMS의 알고리즘 복잡성. 이 그림7 크리에이 티브 코몬즈 라이센스 (여/4.0/http://creativecommons.org/licenses/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 q 3에 대 한 데이터베이스를 추출. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
그림 6 : 알고리즘 복잡성 ORM MySQL의 존재와 MongoDB DBMS에 대 한 쿼리 Q6. 이 그림7 크리에이 티브 코몬즈 라이센스 (여/4.0/http://creativecommons.org/licenses/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 Q6에 대 한 데이터베이스를 추출. 이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.
| 쿼리 | |
| 1 분기 | 단일 환자의 모든 문제를 찾아 |
| Q2 | 모든 환자의 모든 문제를 찾아 |
| 3 분기 | 초기 날짜, 해상도 날짜 및 심각도 |
| 단일 환자에의 한 문제 | |
| 4 분기 | 초기 날짜, 해상도 날짜 및 심각도 |
| 단일 환자의 모든 문제 문제 | |
| Q5 | 초기 날짜, 해상도 날짜 및 심각도 |
| 모든 환자의 모든 문제 문제 | |
| Q6 | 문제 '인 두 염', 모든 환자를 찾기 |
| 초기 날짜 > 2007/10/16 ' =', 해결 날짜 | |
| < = ' 06/05/2008 ' 및 심각도 '높은' |
표 1: 6 쿼리는 관계형에서 수행과 NoSQL 데이터베이스 포함 된 표준화 된 EHR 환자의 문제에 대 한 추출. 이 테이블 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여7 에서 수정 되었습니다 및 자연에서 표현 하는 각 DBMS에 대 한 3 크기 성장 하는 데이터베이스에 수행 6 성장 하는 복잡 한 쿼리를 보여 줍니다. 언어입니다.
| ORM/MySQL | 5000 문서 | 10000 문서 | 20000 문서 |
| 1 분기 (s) | 25.0474 | 32.6868 | 170.7342 |
| Q2 (s) | 0.0158 | 0.0147 | 0.0222 |
| 3 분기 (s) | 3.3849 | 6.4225 | 207.2348 |
| 4 분기 (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| 데이터베이스 크기 | 4.6 GB | 9.4 GB | 19.4 G B |
| 총 추출 | 5000 | 10000 | 20000 |
표 2: 평균 응답 시간 두 배로 크기 데이터베이스 ORM MySQL 관계형 DBMS의 6 개의 쿼리의 초에서. 이 테이블 3 배 크기의 데이터베이스 ORM MySQL 관계형 DBMS를 사용 하 여 세 가지 데이터베이스의 메모리 크기에 대 한 각 쿼리에 대 한 6 응답 시간을 보여 줍니다.
| MongoDB | 5000 문서 | 10000 문서 | 20000 문서 | 슬로프 (*10exp(-6)) |
| 1 분기 (s) | 0.046 | 0.057 | 0.1221 | 5.07 |
| Q2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| 3 분기 (s) | 0.048 | 0.058 | 0.1201 | 4.81 |
| 4 분기 (s) | 0.052 | 0.061 | o.1241 | 4.81 |
| Q5 (s) | 38.0202 | 75.4376 | 149.933 | 7460.85 |
| Q6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| 데이터베이스 크기 | 1.95 GB | 3.95 기가바이트 | 7.95 G B | |
| 총 추출 | 5000 | 10000 | 20000 |
표 3: 평균 응답 시간 MongoDB NoSQL DBMS의 배로 크기 데이터베이스에 6 개의 쿼리의 초에. 이7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 테이블과 NoSQL MongoDB DBMS 및 메모리 크기를 사용 하 여 3 배 크기의 데이터베이스에 대 한 각 쿼리 6 응답 시간을 보여 줍니다. 세 가지 데이터베이스. 각 쿼리의 선형 슬로프도 표시 됩니다.
| 존재 | 5000 문서 | 10000 문서 | 20000 문서 | 슬로프 (*10exp(-6)) |
| 1 분기 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| Q2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| 3 분기 (s) | 0.6976 | 1.771 | 4.1172 | 227.96 |
| 4 분기 (s) | 0.6445 | 3.7604 | 7.3216 | 445.17 |
| Q5 (s) | 145.3373 | 291.2502 | 597.7216 | 30,158.93 |
| Q6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| 데이터베이스 크기 | 1.25 GB | 2.54 GB | 5 월 12 일 기가바이트 | |
| 총 추출 | 5000 | 10000 | 20000 |
표 4: 평균 응답 시간 존재 NoSQL DBMS의 배로 크기 데이터베이스에 6 개의 쿼리의 초에. 이 표7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여에서 수정 되었습니다 및 DBMS와의 메모리 크기는 NoSQL을 사용 하 여 3 배 크기의 데이터베이스에 대 한 각 쿼리 6 응답 시간 존재 표시 3 데이터베이스입니다. 각 쿼리의 선형 슬로프도 표시 됩니다.
| 암 종이 | 팔 (s) | 노드 + 경로 (s) | |
| 1 분기 | 쿼리 2.1 | 0.191 | 24.866 |
| 3 분기 | 3.1 쿼리 | 0.27 | 294.774 |
| 데이터베이스 크기 | 2.90 GB | 43.87 GB | |
| 총 추출 | 29,743 | 29,743 |
표 5: 평균 응답 시간 쿼리 q 1과 q 3에는 향상 된 관계형 시스템의 비슷한 초에서 10 . 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 나타나고 두 대부분 비슷한 쿼리 q 1과 q 3에10 두 향상 된 관계형 데이터베이스 시스템에 해당 하 그리고 그들의 응답 시간입니다. 두 개의 데이터베이스 크기도 표시 됩니다.
| ORM/MySQL | 처리량 | 응답 시간 |
| 1 분기 (s) | 4,711.60 | 0.0793 |
| 3 분기 (s) | 4,711.60 | 0.1558 |
| 4 분기 (s) | 4,711.60 | 0.9674 |
표 6: 평균 처리량과 응답 시간 쿼리 1 분기, 3 분기 및 4 분기의 ORM MySQL 관계형 DBMS 동시 실행에의 초. 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 및 동시에 3 개의 단일 환자 쿼리 및 그들의 평균 응답 시간 가장 높은 평균 처리량을 보여줍니다. ORM MySQL 관계형 시스템을 사용 하 여 실행 실험입니다.
| MongoDB | 처리량 | 응답 시간 |
| 1 분기 (s) | 178,672.60 | 0.003 |
| 3 분기 (s) | 178,672.60 | 0.0026 |
| 4 분기 (s) | 178,672.60 | 0.0034 |
표 7: 평균 처리량과 응답 시간 (초)의 동시 실행 쿼리 1 분기, 3 분기 및 4 분기 MongoDB NoSQL DBMS. 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 및 동시에 3 개의 단일 환자 쿼리 및 그들의 평균 응답 시간 가장 높은 평균 처리량을 보여줍니다. MongoDB NoSQL 시스템을 사용 하 여 실행 실험입니다.
보충 그림 1: 스크린샷 MySQL 서버에 연결 하는 소프트웨어 화면을 보여줍니다. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
보충 그림 2: 스크린샷 보여줍니다 SQL 인터페이스 MySQL 서버에 첫 번째 SQL 쿼리 작성 되었습니다. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
보충 그림 3: The MongoDB 2.6 localhost 서버 서버 mongod를 실행 하 여 DOS 시스템 창을 사용 하 여 시작 됩니다. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
보충 그림 4: 스크린샷 단계 5.7.4 통해 5.7.1 에서처럼 쿼리 작성기의 텍스트 상자에 작성 하는 쿼리를 보여 줍니다. 스크린샷 단계를 5.7.3 보여 줍니다. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
보충 그림 5: 스크린샷은 단계 5.7.6. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
보충 그림 6: 화면 캡처 설명 대화 상자의 theupper 부분에 XPath 쿼리 작성. 이 그림을 다운로드 하려면 여기를 클릭 하십시오.
Discussion
이 프로토콜 표시는 순수 관계형 ORM 시스템 하지 않는 것 단일 환자 쿼리 (Q1, Q3, Q4)에 대 한 실제 응답 시간이 느린 때문에 많은 비싼 조인 작업을 수행 하는 관계형 테이블의 높은 숫자 때문에 아마 때문에 특정 종류의 데이터베이스에서 사용 하는 스토리지 시스템. NoSQL 데이터베이스는 관계형 시스템 사용 테이블-기반 패션 데이터베이스 전체에 걸쳐 각 문서를 확산 하는 문서 기반 패션에 데이터를 저장 합니다. NoSQL 시스템 DBMS 보다 상당히 빠른 수행 MongoDB와 선형 경사를 보여줍니다. 동시성, MongoDB는 또한 관계형 MySQL ORM7보다 훨씬 더 잘 동작합니다.
이 프로토콜은 ORM MySQL DBMS에 관한7 에서 제시 하는 결과 대 한 문제 해결 프로토콜을 제공 합니다. MySQL 시스템 최신 버전으로 업데이트 하 고 결과 약간 수정 되었습니다. 또한, 문서 기반의 NoSQL 시스템에서 중요 한 포인트와 같은 MongoDB EHR을 추출 하 여 업데이트 될 때 그것은 덮어쓰기되지 않습니다, 때문에 의료 정보7 를 저장 하지만 전체 새로운 새 데이터로 추출 하는 때 그들은 일관성을 보존할 수는 생성 하 고 시스템에 저장 된 원래 추출 유지 됩니다. 이것은 의료 정보의 엄격한 요구 사항 때문에 일부 의료 종사자 들은 원래 데이터에 따라 중요 한 의료 결정을 만들 수 있습니다.
크게 향상 된 관계형 팔 시스템 관계형 테이블의 수를 감소 하 고 관계형 성능을 향상 시킵니다. 관계형 스키마를 수정 하는 때문에, 추출 하 여 보유 하는 의료 정보를 쿼리할 수 있습니다, 그러나, 추출 물 그들의 정확한 원래 형태로 복구할 수 없습니다.
중에서 매우 큰 데이터베이스 사용 (연구), 그것은 때문에 모든 환자 쿼리 (q 2와 q 5) 행동 보다 ORM에 더 나은 NoSQL 시스템, 데이터베이스 시스템은 더 적절 한 불분명 하지만 이러한 시스템 수행 보다는 단순화 된 관계형 12에서시스템입니다. 우리 고려 Q6 임상 연습 사이 및 보조 특별 한 쿼리 사용 동작 이러한 실험에 의해 굴복 하는 결과 의해 결정 될 수 없습니다.
그러나, 방법의 한 가지 한계는 정확히 동일한 데이터 프로토콜에 사용 되는 향상 된 관계형 팔 시스템 NoSQL MongoDB 쿼리를 단일 환자, 의료 연습에 관한 비교는 직접 실험의 inavailability. 우리는 인터폴 레이 팅 표 3 및 표 5 단일 환자 쿼리에 관한 실험 프로토콜에 최적화 된 팔을 포함 하 여 수행 될 때까지 결과 유지. 우리는 미래의 응용 프로그램에 대 한 이러한 실험을 두고. 우리는 정확한 상태--예술의 세 가지 기술을 비교할 수 있도록 프로토콜 내에서 하나의 중요 한 단계는 다양 한 무료 데이터베이스, 최근 몇 년 동안에서 유사한 소프트웨어 버전입니다.
이것을 직접 관계형 비교할 첫 번째 시도 및 실제, 현실, 표준화 된 의료 정보를 사용 하 여 NoSQL 시스템 중 하나입니다. 그러나, 사용 될 특정 시스템 훨씬 실제 시나리오 및 문제 해결된8수에 따라 다릅니다.
Disclosures
저자는 공개 없다. 이 실험에 사용 된 데이터 집합이이 실험에 대 한 라이센스 여러 스페인 병원에 의해 제공 되었다 고 따라서 공개적으로 사용할 수 있습니다. ISO/EN 13606 RM XML 스키마 했다 대학 대학 런던 센터 의료 정보학 및 Multiprofessional 교육 (차 임)에 제공 됩니다.
Acknowledgments
저자 박사 Dipak Kalra, 표준 ISO/EN 13606와 ISO/EN 13606 W3C XML 스키마를 사용 하 여 그들의 종류 권한을 대학 대학 런던에서 그의 팀을 정의 하는 EHRCom 태스크 포스의 리더를 감사 하 고 싶습니다.
이 작품은 Instituto de에 의해 지원 되었다 건배 카를로스 III [보조금 번호 PI15/00321, PI15/00003, PI1500831, PI15CIII/00010, RD16CIII].
Materials
| Name | Company | Catalog Number | Comments |
| MySQL 5.7.20 | MySQL experiments | ||
| Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB | |||
| MongoDB 2.6 | MongoDB experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| eXist 3.0RC1 | eXist experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| Studio 3T 5.5.1 | 3T Software Labs Gmbh | MongoDB GUI |
References
- Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
- Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
- Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
- Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
- Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
- Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
- Sánchez-de-Madariaga, R., et al. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).
- Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
- Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
- Wang, L., Min, L., Wang, R., et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88 (2015).
- Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
- Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).
