실시간 데이터베이스
Real-time database실시간 데이터베이스는 상태가 지속적으로 변화하는 워크로드를 처리하기 위해 실시간 처리를 사용하는 데이터베이스 시스템이다.[1] 이는 대부분 시간에 영향을 받지 않는 영구 데이터를 포함하는 기존 데이터베이스와 다르다. 예를 들어 주식시장은 매우 빠르게 변화하고 역동적이다. 다른 시장의 그래프는 매우 불안정해 보이지만, 데이터베이스는 뉴욕 증권거래소의 모든 시장의 현재 가치를 추적해야 한다.[2] 실시간 처리란 거래가 신속하게 처리되어 결과가 다시 나타나 바로 실행된다는 것을 의미한다.[3] 실시간 데이터베이스는 회계, 은행, 법률, 의료 기록, 멀티미디어, 프로세스 제어, 예약 시스템, 과학 데이터 분석에 유용하다.[4]
개요
실시간 데이터베이스는 신뢰할 수 있는 응답을 제공할 수 있는 추가 권한을 부여하기 위해 확장을 사용하는 전통적인 데이터베이스다. 이들은 데이터가 유효한 특정 범위의 값을 나타내는 타이밍 제약조건을 사용한다. 이 범위를 시간적 타당성이라고 한다. 실제 세계 개체와 이를 나타내는 데이터 사이의 불일치가 단순 수정에 비해 너무 심각하기 때문에 이러한 상황에서는 기존의 데이터베이스가 작동하지 않는다. 효과적인 시스템은 시간에 민감한 쿼리를 처리할 수 있어야 하고, 임시로 유효한 데이터만 반환해야 하며, 우선 순위 스케줄링을 지원할 수 있어야 한다. 레코드에 데이터를 입력하기 위해 센서나 입력 장치는 물리적 시스템의 상태를 모니터링하고 물리적 시스템을 보다 정확하게 반영하기 위해 새로운 정보로 데이터베이스를 업데이트하는 경우가 많다.[5] 실시간 데이터베이스 시스템을 설계할 때는 유효한 시간을 나타내는 방법, 사실이 실시간 시스템과 어떻게 연관되는지를 고려해야 한다. 또한 프로세스 트랜잭션 및 데이터 일관성에 위반이 없도록 데이터베이스에서 속성 값을 표시하는 방법도 고려하십시오.
시스템을 설계할 때는 마감일이 충족되지 않을 때 시스템이 무엇을 해야 하는지를 고려하는 것이 중요하다. 예를 들어, 항공 교통 관제 시스템은 수백 대의 항공기를 지속적으로 감시하고 들어오는 비행 경로에 대한 결정을 내리고 연료, 고도, 속도 등의 데이터를 기반으로 항공기가 착륙해야 하는 순서를 결정한다. 만약 이 정보들 중 어떤 것이라도 늦으면, 그 결과는 파괴적일 수 있다. 사용되지 않는 데이터의 문제를 해결하기 위해 타임스탬프는 명확한 시간 참조를 제공함으로써 트랜잭션을 지원할 수 있다.
데이터 일관성 유지
실시간 데이터베이스 시스템은 단순한 시스템처럼 보일 수 있지만, 두 개 이상의 데이터베이스 트랜잭션이 데이터베이스의 동일한 부분에 대한 액세스를 요구할 때 과부하 시 문제가 발생한다. 트랜잭션은 일반적으로 데이터베이스의 내용에 접근하거나 변경하는 프로그램의 실행의 결과물이다.[6] 스트림은 읽기 전용 작업만 허용하고 트랜잭션은 읽기 및 쓰기 작업을 모두 수행할 수 있기 때문에 트랜잭션은 스트림과 다르다. 이것은 스트림에서 여러 사용자가 동일한 데이터 조각에서 읽을 수 있지만 둘 다 수정할 수는 없다는 것을 의미한다.[5] 데이터베이스는 데이터 일관성을 보존하기 위해 한 번에 하나의 트랜잭션만 작동하도록 허용해야 한다. 예를 들어, 만약 두 명의 학생이 수업의 한 부분에 대해 나머지 자리를 요구하면서 동시에 제출한다면, 오직 한 명의 학생만 등록할 수 있어야 한다.[5]
실시간 데이터베이스는 동시성 제어를 위한 스케줄링 알고리즘을 활용하여 이러한 요청을 처리할 수 있으며, 어떤 방식으로든 두 학생의 요청에 우선순위를 부여한다. 이 글에서 우리는 시스템이 단일 프로세서, 디스크 기반 데이터베이스 및 주 메모리 풀을 가지고 있다고 가정한다.[7]
실시간 데이터베이스에서는 마감일이 형성되고 다른 종류의 시스템이 다른 방식으로 마감일을 충족하지 않는 데이터에 대응한다. 실시간 시스템에서 각 트랜잭션은 타임스탬프를 사용하여 트랜잭션을 예약한다.[5] 우선순위 매퍼 장치는 시스템이 시간 및 기타 우선순위를 보는 방법에 따라 데이터베이스 시스템에 도착하는 즉시 각 트랜잭션에 중요도 수준을 할당한다. 타임스탬프 방법은 시스템의 도착 시간에 의존한다. 연구자들은 대부분의 연구에서 거래는 예측 불가능한 도착 시간을 가진 산발적인 것이라고 밝혔다. 예를 들어, 이 시스템은 더 높은 우선순위에 더 이른 요청 시한을, 더 늦은 마감 시한을 더 낮은 우선순위에 부여한다.[7] 아래는 다른 스케줄링 알고리즘을 비교한 것이다.
- 가장 빠른 마감일
- PT = DT — 거래의 가치는 중요하지 않다. 예를 들면, 상품을 주문하기 위해 전화를 거는 사람들이 있다.
- 최고 가치
- PT = 1/VT — 마감일은 중요하지 않다. 일부 트랜잭션은 공정성이 아니라 중요성에 기반하여 CPU에 도달해야 한다. 이것은 최소한의 시간을 기다릴 수 있는 최소한의 느슨함의 예다. 전화 교환기에 과부하가 걸리면 911에 신고하는 사람이 우선돼야 한다.[4]
- 가치 부풀리기 마감일
- PT = DT/VT — 일정에 따라 마감일 및 값과 동일한 가중치를 부여한다. 수강 희망 블록을 선택해 제출을 누르는 수업 등록이 대표적이다. 이 시나리오에서는 높은 우선순위가 우선하는 경우가 많다. 학교 등록 시스템은 서버가 두 개의 등록 트랜잭션을 받을 때 이 기법을 사용할 수 있다. 한 학생이 22학점을, 다른 학생이 100학점을 받은 경우 100학점을 받은 학생이 우선(가치 기반 스케줄링)하게 된다.
타이밍 제약 조건 및 마감
소프트 또는 확정 기한을 가진 거래와 관련된 연재 및 타이밍 제약을 올바르게 인지하는 시스템은 절대 일관성을 이용한다.[8] 데이터가 절대적인지 확인하는 또 다른 방법은 상대적 제약조건을 사용하는 것이다. 상대적 제약조건은 데이터 트랜잭션이 연관된 그룹의 나머지 부분과 동시에 시스템에 들어오도록 보장한다. 절대적 및 상대적 제약의 메커니즘을 사용하면 데이터의 정확성을 크게 보장할 수 있다.
마감일 외에 실시간 데이터베이스 시스템에서 분쟁 해결을 처리하는 추가적인 방법은 대기 정책 방법이다. 이 프로세스는 시간에 중요한 시스템의 최신 정보를 보장하는 데 도움이 된다. 이 정책은 가장 필수적인 데이터 블록이 처리될 때까지 모든 비요청 블록에 대기하도록 요청함으로써 충돌을 방지한다.[5] 연구실 연구 결과 데이터 데드라인에 기반한 정책이 성능을 크게 향상시키지 못하는 것으로 나타났지만, 강제 대기 정책은 성능을 50% 향상시킬 수 있다.[9] 강제 대기 정책에는 교착 상태를 방지하기 위해 우선 순위가 높은 트랜잭션이 처리될 때까지 기다리는 것이 포함될 수 있다. 데이터가 지연될 수 있는 또 다른 예는 데이터 블록이 만료되려고 할 때 입니다. 강제 대기 정책은 새 입력 데이터를 사용하여 데이터가 업데이트될 때까지 처리를 지연시킨다. 후자의 방법은 시스템의 정확도를 높이는 데 도움이 되며, 중단되는 필요한 프로세스의 수를 줄일 수 있다. 일반적으로 대기 정책에 의존하는 것은 최적이 아니다.[10]
마감일의 형성에 대해 논의할 필요가 있다. 마감일은 거래에 의해 접근되는 대체될 데이터의 제약조건이다. 마감일은 관측 가능하거나 예측 가능해야 한다.[10] 준수 기한 시스템에서는 미완료된 모든 거래를 검사하고 프로세서가 기한을 충족했는지 여부를 결정한다.[5] 이 방법에서 문제는 탐색 시간 변화, 버퍼 관리 및 페이지 결함에 의해 야기되는 변화 때문에 발생한다.[11] 마감일을 보다 안정적으로 정리하는 방법이 예측 방법이다. 그것은 후보 일정을 짜고, 거래가 일정에 따라 마감일을 놓칠지 여부를 결정한다.[5]
기한을 놓친 것에 대한 대응의 종류는 기한이 딱딱한지, 부드러우는지, 아니면 확고한지 여부에 달려 있다. 하드 데드라인에서는 각 데이터 패킷이 패킷이 만료되기 전에 목적지에 도달해야 하며 그렇지 않을 경우 프로세스가 손실되어 문제가 발생할 수 있다. 최악의 경우를 결정하기 위해 마감일을 지정하기 전에 시스템의 전반적인 기능이 요구되기 때문에 이와 같은 문제는 그리 흔하지 않다. 이것은 매우 하기 어렵고 만약 시스템에 미세한 하드웨어 결함 같은 예상치 못한 일이 일어난다면, 그것은 데이터를 날려버릴 수 있다. 연약하거나 딱딱한 마감일의 경우, 기한을 놓치면 성능이 저하될 수 있지만 대재앙은 아닐 수 있다.[7] 연한 마감일은 가능한 한 많은 마감일을 충족한다. 그러나 시스템이 모든 마감일을 충족할 수 있다는 보장은 없다. 거래가 마감일을 놓치면 시스템은 더 유연해지고 거래의 중요성은 높아질 수 있다. 아래는 이러한 응답에 대한 설명이다.
- 하드마감
- 기한을 맞추지 못하면, 힘든 기한이 최선이다. 주기적인데, 규칙적인 리듬 패턴으로 데이터베이스에 들어간다는 뜻이다. 센서가 수집한 데이터를 예로 들 수 있다. 이것들은 종종 삶에서 중요한 시스템에 사용된다.[12]
- 확정기한
- 확정기일은 거래가 도착한 후 어느 시점에 거래를 완료하는 것이 얼마나 중요한지를 측정하기 때문에 확정기일은 하드기일과 유사하지만 하드기일과 다르다. 때때로 거래의 마감일이 경과한 후에 거래를 완료하는 것은 해롭거나 도움이 되지 않을 수 있으며, 기업과 하드라인 모두 이를 고려한다. 확실한 마감일의 예로는 오토파일럿 시스템이 있다.[4]
- 소프트 마감
- 회의 시간의 제약이 바람직하지만 기한을 지키지 않는 것이 심각한 피해를 초래하지 않는 경우, 부드러운 기한이 최선일 수 있다. 그것은 주기적 또는 불규칙적인 스케줄로 운영된다. 사실 각 과제에 대한 매회 도착은 알 수 없다. 예를 들면 전화 교환기를 들 수 있다.[12]
하드 데드라인 공정은 마감시한을 넘긴 거래를 중단해 처리가 필요한 잡동사니를 정리하는 방식으로 시스템을 개선한다. 프로세스는 일단 프로세서에 도달하면 더 이상 사용되지 않을 것으로 가정하여 마감일이 만료된 트랜잭션뿐만 아니라 마감일이 가장 긴 트랜잭션도 삭제할 수 있다. 이는 다른 거래의 우선 순위가 더 높아야 한다는 것을 의미한다. 또한, 시스템은 가장 덜 중요한 트랜잭션을 제거할 수 있다. 트래픽이 많은 기간 동안 에 대한 클래스를 미리 선택할 때 데이터베이스의 필드가 등록 요청으로 너무 바빠져서 잠시 사용할 수 없게 되고 트랜잭션의 결과는 전송된 SQL 쿼리와 현재 데이터를 사용할 수 없다는 메시지를 표시하는 것이었습니다. 이 오류는 규칙의 상태를 확인하는 메커니즘인 체커와 그 이전에 발생한 규칙에 의해 발생한다.[13]
일정 기간 및 마감일의 목표는 작업량이 최소화되도록 마감일 전에 완료하도록 보장된 트랜잭션을 업데이트하는 것이다. 대용량 실시간 데이터베이스에서는 버퍼링 기능이 성능을 엄청나게 향상시키는 데 도움이 될 수 있다. 버퍼는 트랜잭션 응답 시간을 줄이기 위해 메인 메모리에 저장되는 데이터베이스의 일부다. 디스크 입출력 거래를 줄이기 위해서는 일정 수의 버퍼를 할당해야 한다.[14] 때때로 데이터 블록이 현재 사용 중일 때, 다중 데이터들은 버퍼에 저장된다. 나중에 데이터베이스에 데이터가 추가된다. 다른 전략은 버퍼를 할당하며 과도한 양의 메모리를 사용하는 것과 검색해야 할 모든 것을 하나의 버퍼에 포함하는 것 사이에서 균형을 맞춰야 한다. 검색 시간을 없애고 버퍼 프레임 사이에 자원을 분산해 데이터에 빠르게 접근하는 것이 목표다. 버퍼 관리자는 필요한 경우 더 많은 메모리를 할당하여 응답 시간을 개선할 수 있다. 버퍼 매니저는 심지어 자신이 가지고 있는 트랜잭션을 진전시켜야 하는지도 결정할 수 있다. 버퍼링은 실시간 시스템에서 속도를 향상시킬 수 있다.[14]
미래 데이터베이스 시스템
기존 데이터베이스는 지속적이지만 끊임없이 변화하는 동적 데이터를 처리할 수 없다. 따라서 다른 제도가 필요하다. 실시간 데이터베이스는 정확성과 효율성을 향상시키고 충돌을 피하기 위해 시간적 일관성을 보장하기 위해 마감일과 대기 기간을 제공함으로써 수정될 수 있다. 실시간 데이터베이스 시스템은 물리적 시스템을 모니터링하고 데이터베이스에 대한 데이터 스트림에서 이를 나타내는 방법을 제공한다. 메모리와 같은 데이터 스트림은 시간이 지남에 따라 퇴보한다. 가장 신선하고 가장 정확한 정보가 기록되도록 하기 위해 거래를 적절한 순서로 실행되도록 하기 위해 여러 가지 방법으로 확인할 수 있다. 온라인 경매장은 빠르게 변화하는 데이터베이스의 예를 제공한다.
이제 데이터베이스 시스템은 과거보다 더 빨라졌다. 미래에는, 우리는 더 빠른 데이터베이스 시스템을 기대할 수 있다. 비록 지금은 더 빠른 시스템을 가지고 있지만, 실수나 지각 시간을 줄이기 위한 노력은 여전히 유익할 것이다. 시기적절하고 예측 가능한 방식으로 결과를 처리하는 능력은 빠른 처리보다 항상 더 중요할 것이다. 잘못 적용된 빠른 처리는 실시간 데이터베이스 시스템에 도움이 되지 않는다. 더 빨리 실행되는 트랜잭션은 여전히 때때로 중단되고 재시작되어야 하는 방식으로 차단된다. 사실, 처리 속도가 빨라지면 속도가 증가하면 더 복잡해지고 속도 차이로 인한 문제에 대한 가능성이 높아지기 때문에 일부 실시간 응용 프로그램이 손상된다. 처리 속도가 빨라지면 어떤 마감일이 성공적으로 충족되었는지 판단하기가 더 어려워진다. 미래의 데이터베이스 시스템이 그 어느 때보다 더 빨리 실행되기 때문에, 효율적인 시스템을 계속 보유할 수 있도록 더 많은 연구를 할 필요가 있다.[15]
실시간 데이터베이스 시스템을 연구하는 연구량은 eBay와 같은 웹 기반 경매 회사 같은 상업적 응용 프로그램 때문에 증가할 것이다. 더 많은 개발도상국들이 전화 시스템을 확장하고 있으며, 세계 다른 곳뿐만 아니라 미국에서도 휴대폰을 소지한 사람들의 수가 계속해서 증가하고 있다. 또한 실시간 연구에 박차를 가할 가능성이 높은 것은 마이크로프로세서의 속도가 기하급수적으로 증가하는 것이다. 이를 통해 실시간 데이터베이스 시스템에 의존하는 음향·고해상도 동영상에서 웹-비디오 회의, 인스턴트 메신저 대화 등 신기술도 가능하다. 시간적 정합성에 대한 연구는 실시간 거래를 보다 효과적으로 처리할 수 있다는 목표와 함께 새로운 프로토콜과 타이밍 제약으로 귀결된다.[7]
참조
- ^ 부크만, A. "실시간 데이터베이스 시스템" 데이터베이스 기술 및 응용프로그램 백과사전. 에드. 로라 C Rivero, Jorge H. Doorn, Viviana E. 페라기네 2005년 아이디어 그룹.
- ^ Kanitkar, Vinay & Alex Delis (1997). "A Case for Real-Time Client-Server Databases". Brooklyn, New York: Polytechnic University. Retrieved 13 December 2006. Cite 저널은 필요로 한다.
journal=
(도움말) - ^ 카프론, H.L., J. A. 존슨. 컴퓨터: 정보 시대를 위한 도구. 프렌티스 홀, 1998년 제5판
- ^ a b c (Snodgrass)
- ^ a b c d e f g Abbot, Robert K., and Hector Garcia-Molina. (1992). "Scheduling Real-Time Transactions: a Performance Evaluation" (PDF). Stanford University and Digital Equipment Corp. ACM. doi:10.1145/132271.132276. Retrieved 13 December 2006. Cite 저널은 필요로 한다.
journal=
(도움말)CS1 maint: 여러 이름: 작성자 목록(링크) - ^ 싱할, 무케시 실시간 데이터베이스 시스템 설계 방법, SGIMOD 기록, 제17권, 제1호, 1988년 3월
- ^ a b c d Haritsa, J., J. Stankovic, and M Xiong. "A State-Conscious Concurrency Control Protocol for Replicated Real-Time Databases". University of Virginia. IEEE Real-Time Applications Symposium. Retrieved 13 December 2006. Cite 저널은 필요로 한다.
journal=
(도움말)CS1 maint: 여러 이름: 작성자 목록(링크) - ^ Lee, Juhnyoung (1994). "Concurrency Control Algorithms for Real-Time Database Systems". Diss. Univ. of Virginia. Retrieved 13 December 2006. Cite 저널은 필요로 한다.
journal=
(도움말) - ^ (포크카)
- ^ a b 강, KD, S손, J 스탄코비치. 실시간 데이터 서비스의 품질 지정 및 관리. 버지니아 대학교. IEEE TKDE, 2004.
- ^ 카오 & 가르시아-몰리나 1994, 페이지 261–282.
- ^ a b 스탄코비치, 존 A, 마르코 스푸리, 크리스티 라맘리담, 조르지오 C. 부타조. 실시간 시스템의 마감일 지정: EDF 및 관련 알고리즘. 1998년 스프링거
- ^ (라마리담)
- ^ a b (오닐)
- ^ 람, 캄유, 테이웨이 궈. 실시간 데이터베이스 시스템: 건축과 기술. 2001년 스프링거
추가 읽기
- 오즈소요글루, 굴테킨, 리처드 T. 스노드그래스. 시간 및 실시간 데이터베이스: 설문 조사. 지식정보공학, 1995. 2006년 12월 13일.
- Kao, Ben; Garcia-Molina, Hector (1994). "An Overview of Real-Time Database Systems". Real Time Computing. Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-88049-0_13. ISBN 978-3-642-88051-3. ISSN 0258-1248.
- 린드스트롬, 1월 실시간 데이터베이스 시스템. 솔리드, 2008. 2008년 3월 25일
- 시바산카란, 라젠드란 M, 존 A. 스탄코비치, 돈 토우슬리, 바스카르 푸리메틀라, 크리스티 라마리담. 실시간 활성 데이터베이스의 우선 순위 할당. 매사추세츠 대학교. 1996년 12월 13일 뉴욕주 아머스트.
- 스톤브레이커, 마이클 등 HStore: 고성능 분산형 메인 메모리 트랜잭션 처리 시스템, 2008.
- Gorine, Andrei, 미션 크리티컬 결정론적 DBMS On Time, 2021.