아무도 묻지 않는 질문
기술 팀이 데이터 저장 옵션을 평가할 때, 대화는 보통 기능에서 시작됩니다. 고급 쿼리가 필요한가? 복제는? 다중 사용자 접근 제어는?
xGrid의 경우, 대화는 다른 질문에서 시작됩니다. IT 담당자 없이, 구성 단계 없이, 백그라운드 서비스 없이 휴대용 장치에서 데이터베이스가 실행될 수 있으며, 그래도 환자 데이터를 맡길 수 있는가?
이 답이 가장 단순한 선택지 외의 모든 것을 제거합니다.
제로 구성이 실제로 의미하는 것
일반적인 엔터프라이즈 데이터베이스에는 다음이 필요합니다. 서버 소프트웨어 설치, 사용자 계정 생성, 인증 구성, 성능 매개변수 조정, 백그라운드 서비스 설정, 장애 모니터링, 버전 업그레이드 처리. 일곱 단계이며, 각각이 잠재적 장애 지점입니다.
xGrid의 임베디드 데이터베이스에 필요한 것: 시스템이 하나의 파일을 가리키는 것입니다. 그 파일이 곧 데이터베이스입니다. 서버 프로세스 없음. 자격 증명 없음. 구성 파일 없음. 네트워크 포트 없음.
IT 부서가 있는 병원에서 이 일곱 단계는 일상입니다. 그러나 운영자가 간호사이고 "배치"가 "장치를 꽂고 전원을 켜는 것"을 의미하는 재난 현장에서는, 각 단계가 시스템이 시작되지 않을 위험이 됩니다.
읽기와 쓰기의 동시 수행
단일 파일 데이터베이스는 동시 사용 시 제한될 수 있습니다. xGrid는 동시 읽기와 쓰기를 허용하는 저널링 모드(journaling mode)로 이를 극복합니다.
- 15명의 간호사가 환자 기록을 조회하는 동안 혈액 은행 작업이 새로운 수혈 오더를 기록할 수 있습니다
- 읽기가 쓰기를 차단하지 않으며, 쓰기가 읽기를 차단하지 않습니다
- 한 번에 하나의 쓰기 작업만 수행됩니다. 그리고 이것이 실제로는 장점이 됩니다
의도적인 병목
xGrid는 모든 쓰기 작업을 단일 제어 진입점을 통해 직렬화합니다. 모든 데이터 변경 -- 신규 환자, 업데이트된 활력 징후, 조제된 약물 -- 이 정돈된 큐에서 대기합니다.
이것은 성능 제약처럼 들립니다. 실제로 그렇습니다. 의도적으로.
재난 의료에서 데이터 정확성은 속도를 자릿수 차이로 압도합니다. 손상된 분류 기록은 50밀리초의 쓰기 지연보다 무한히 나쁩니다. 단일 진입점은 모든 쓰기가 정돈되고, 충돌이 없으며, 완전함을 보장합니다. 복잡한 조정 메커니즘 불필요. 재시도 로직 불필요. 한 번에 하나의 변경, 순서대로, 매번.
휴대용 하드웨어에서의 성능
임베디드 데이터베이스는 6가지 최적화를 통해 휴대용 하드웨어에 맞게 특별히 조정되었습니다.
| 최적화 | 효과 |
|---|---|
| 동시 접근 모드 | 여러 임상 인력이 읽는 동안 한 명이 쓰기 가능 |
| 균형 잡힌 내구성 | 체크포인트에서 데이터 저장 -- 임상 사용에 충분히 빠르고, 정전에 충분히 안전 |
| 메모리 캐시 | 자주 접근하는 데이터가 메모리에 유지되어 디스크 읽기 감소 |
| 인메모리 임시 저장 | 중간 계산이 저장 카드가 아닌 메모리에서 수행 |
| 메모리 매핑 접근 | 대규모 데이터 읽기가 느린 디스크 작업을 우회 |
| 참조 무결성 | 데이터베이스가 데이터 관계를 강제 -- 존재하지 않는 환자를 참조하는 처방은 생성 불가 |
내구성 설정은 특별한 주의가 필요합니다. 가장 빠른 옵션은 정전 시 데이터 손상 위험이 있습니다. 배터리로 구동되는 장치에서 정전은 가설이 아닙니다. 일상적인 시나리오입니다. xGrid는 균형 잡힌 설정을 사용합니다. 임상 처리량에 충분히 빠르면서, 예기치 않은 종료 시에도 데이터베이스가 손상되지 않을 만큼 안전합니다.
41회 스키마 업데이트, 수동 개입 제로
xGrid Medical Grid는 혈액 은행 테이블부터 검색 인덱스까지 41회의 데이터베이스 구조 업데이트를 거쳐 진화했습니다. 각 업데이트는 등록되고, 순서가 지정되며, 자동으로 실행됩니다.
- 일회 실행 보장: 각 업데이트는 버전 번호로 추적되어 정확히 한 번만 실행
- 순서대로 실행: 업데이트는 순차적으로 실행되며, 순서가 뒤바뀌지 않음
- 장애 허용: 실패한 업데이트는 완료된 것에 영향 없이 깨끗하게 롤백
- 완전 자동: 보류 중인 모든 업데이트가 시스템 시작 시 실행
간호사가 원격 업데이트 후 시스템을 재시작합니다. 데이터베이스 구조가 조용히 진화합니다. 프롬프트를 보지 않고, 명령을 실행하지 않으며, 구성 화면을 만지지 않습니다.
용량: 하나의 장치가 처리할 수 있는 양
테스트된 수치:
- 하루 500명의 환자: 임상 시스템 처리 처리량
- 동시 10~15개 연결: 동시에 운영되는 간호 스테이션
- 15개 초과 시: 응답 시간이 눈에 띄게 증가 -- 두 번째 장치 배치 필요
병목은 단일 쓰기 설계와 저장 카드 속도의 조합입니다. 재난 의료 규모 -- 일반적으로 사이트당 하루 100~300명의 환자 -- 에는 이 용량이 충분하고도 남습니다.
백업은 파일 복사
엔터프라이즈 데이터베이스 백업에는 보통 전용 내보내기 도구, 예약된 작업, 저장소 관리가 필요합니다.
xGrid의 데이터베이스를 백업한다는 것은 하나의 파일을 복사한다는 뜻입니다. 시스템은 파일 크기와 레코드 수를 비교하여 백업 무결성을 검증합니다.
긴급 대피 시에는 전체 데이터베이스를 다운로드 가능한 아카이브로 패키징하는 엔드포인트가 있습니다. "백업"이 "데이터를 가지고 뛰어라"를 의미할 때도 있기 때문입니다.
단순함이 기능이 될 때
기존의 관점
- 서버 프로세스 없음
커넥션 풀링이나 사이트 간 복제 불가 - 단일 쓰기
높은 동시 사용 시 처리량 저하 - 단일 파일
여러 서버에 걸친 수평 확장 불가 - 사용자 관리 없음
사용자별 세밀한 접근 제어 불가
재난 의료의 관점
- 서버 프로세스 없음
고장날 수 있는 구성요소가 하나 줄어듦 - 단일 쓰기
자연스러운 순서 보장 -- 복잡한 조정 불필요 - 단일 파일
백업은 복사, 대피는 다운로드 - 사용자 관리 없음
잘못 구성할 수 있는 항목이 하나 줄어듦
현장에서 가장 신뢰할 수 있는 시스템은 가장 강력한 시스템이 아닙니다. 움직이는 부품이 가장 적은 시스템입니다.
관련 글: 오프라인 퍼스트는 대체 수단이 아닙니다 · 워크어웨이 테스트 -- 개발자가 사라져도 살아남는 소프트웨어 설계
