스트리밍 데이터베이스의 4가지 주요 설계 원칙 및 보장

스트리밍 데이터베이스의 4가지 주요 설계 원칙과 보증에 대해 설명합니다.

실시간 데이터 처리는 현대 기술 지향 비즈니스를 운영하는 기본적인 측면입니다. 고객은 그 어느 때보다 빠른 결과를 원하며 더 빠른 결과를 얻을 수 있는 아주 작은 기회에도 결함이 발생할 것입니다. 따라서 요즘 조직은 응답 시간을 밀리초 단위로 줄이기 위해 지속적으로 노력하고 있습니다.

실시간 처리는 배치 처리를 사용하여 이전에 처리되었던 대부분의 측면을 처리합니다. 실시간 처리를 위해서는 들어오는 데이터 스트림에서 비즈니스 로직을 실행해야 합니다. 이는 데이터를 데이터베이스에 저장한 다음 분석 쿼리를 실행하는 기존 방식과 매우 대조적입니다. 이러한 애플리케이션은 기존 데이터베이스에 먼저 데이터를 로드한 다음 쿼리를 실행하는 데 필요한 지연 시간을 감당할 수 없습니다. 이렇게 하면 데이터베이스를 스트리밍할 수 있습니다. 스트리밍 데이터베이스는 고속 데이터를 수신하여 기존 데이터베이스 없이 이동 중에도 처리할 수 있는 데이터 저장소입니다. 기존 데이터베이스를 대신할 수는 없지만 고속 데이터를 처리하는 데는 능숙합니다. 이 기사에서는 스트리밍 데이터베이스의 네 가지 주요 설계 원칙과 보증에 대해 설명합니다.

 

 

스트리밍 데이터베이스 이해

스트리밍 데이터베이스는 들어오는 일련의 데이터 지점(즉, 데이터 스트림)을 실시간으로 수집하고 처리할 수 있는 데이터베이스입니다. 기존 데이터베이스는 데이터를 저장하고 사용자가 쿼리를 실행하여 최신 데이터를 기반으로 결과를 가져올 것으로 예상합니다. 실시간 처리가 핵심 기준인 현대 사회에서 쿼리를 기다리는 것은 선택사항이 아닙니다. 대신 쿼리가 지속적으로 실행되고 항상 최신 데이터를 반환해야 합니다. 스트리밍 데이터베이스는 이를 용이하게 합니다.

스트리밍 데이터베이스의 경우 실행이 완료되지 않으므로 쿼리가 실행되지 않고 등록됩니다. 이들은 들어오는 새로운 데이터에 반응하면서 무한한 시간 동안 실행됩니다. 또한 애플리케이션은 시간이 지남에 따라 데이터가 어떻게 변경되는지 파악하기 위해 시간을 거슬러 조회할 수 있습니다.

기존 데이터베이스와 비교하여 스트리밍 데이터베이스는 작성 시 모든 작업을 수행합니다. 이를 달성하기 위해서는 많은 과제가 수반됩니다. 예를 들어 기존 데이터베이스에서 기대하는 최소 내구성과 정확성이 있습니다. 이러한 종류의 내구성과 정확성을 유지하려면 데이터가 항상 작동할 때 복잡한 설계가 필요합니다. 그리고 사용자가 이동 중인 데이터를 쿼리할 수 있도록 하는 문제가 있습니다. SQL은 모든 쿼리 요구사항에 대해 오랫동안 표준으로 사용되어 왔습니다. 스트리밍 데이터베이스도 SQL을 지원하는 것은 당연하지만, 데이터가 항상 이동할 때 윈도우 설정, 집계 등과 같은 구성을 구현하는 것은 복잡합니다.

영구 쿼리는 데이터를 이동할 때 작동하는 쿼리입니다. 그들은 무한정 실행되고 계속해서 출력 행을 만들어냅니다. 끝없는 쿼리는 논리를 업데이트하는 데 고유한 문제를 제기합니다. 중요한 질문은 쿼리를 개선된 쿼리로 교체할 때의 동작입니다. 이때까지 도착한 모든 데이터에서 작동합니까, 아니면 다음 데이터 집합에서만 작동합니까? 첫 번째 작동 모드의 이름은 backfill이고 후자는 정확히 한 번만 처리됩니다. 정확히 한 번만 처리를 구현하려면 실행 엔진에 로컬 저장소가 있어야 합니다. 쿼리가 다른 데이터 스트림에 공급될 수도 있습니다. 이러한 작업을 계단식 모드라고 합니다.

이제 개념이 명확해졌으므로 스트리밍 데이터베이스의 아키텍처 세부 사항에 대해 잠시 살펴보겠습니다. 스트리밍 데이터베이스는 일반적으로 생산자-소비자 패러다임을 기반으로 작동하는 스트림 처리 시스템 위에 구축됩니다. 프로듀서는 이벤트를 생성하는 엔티티입니다. 소비자는 이벤트를 소비하고 처리합니다. 이벤트는 일반적으로 비즈니스 논리 구현을 용이하게 하기 위해 항목의 논리적 파티션으로 그룹화됩니다.

생산자와 소비자에게 필요한 스트림과 포맷 변환의 안정성을 보장하는 브로커가 그들 사이에 있습니다. Broker는 일반적으로 고가용성과 견고성을 보장하기 위해 분산 플랫폼에 배포됩니다. 스트림 쿼리 엔진은 처리 플랫폼의 맨 위에 있습니다. SQL 쿼리를 스트림 처리 논리로 변환하는 SQL 추상화 계층도 있습니다. 모든 것을 꿰매어 보면, 구조는 아래와 같습니다.

 

스트리밍 데이터베이스의 4가지 주요 설계 원칙 및 보장

 

이제 스트리밍 데이터베이스와 지속적인 쿼리의 개념을 이해했으므로 이러한 데이터베이스의 일반적인 사용 사례에 대해 잠시 살펴보겠습니다.

 

 

IoT 플랫폼

IoT 플랫폼은 전 세계 장치에서 밀려오는 수많은 이벤트를 처리합니다. 실시간 처리를 기반으로 경고를 생성하고 대응 시간과 관련하여 엄격한 SLA를 준수해야 합니다.

IoT 플랫폼은 또한 수신된 모든 이벤트를 영구적으로 저장해야 하며 분석을 위해 스트리밍 데이터에 대한 윈도우 기반 집계가 필요합니다. 스트리밍 데이터베이스와 지속적인 쿼리는 여기에 적합합니다.

 

 

이벤트 소싱

이벤트 소싱은 엔티티의 최종 상태가 아니라 시간이 지남에 따라 발생한 이벤트 측면에서 애플리케이션 로직이 실행되는 패러다임입니다. 이벤트에 회신하여 언제든지 응용프로그램 상태를 다시 만들 수 있으므로 응용프로그램의 내구성과 신뢰성을 향상시키는 데 도움이 됩니다. 이 기능은 감사 추적이 필수 요구 사항인 경우에 유용합니다.

 

 

스트림 분석 클릭

Clickstream 분석 플랫폼은 애플리케이션 사용의 일부로 생성되는 Click 이벤트를 처리합니다. 클릭 이벤트의 데이터는 때때로 고객에게 권장 사항과 제안 사항을 제공하는 기계 학습 모델에 직접 제공됩니다. 클릭 스트림에 대한 지속적인 이벤트와 실시간 처리는 eCommerce와 같은 비즈니스를 운영하는 데 중요한 부분입니다.

 

 

트레이딩 시스템

거래 시스템은 초당 수백만 건의 거래 요청을 처리하고 이를 수요 및 공급 방정식과 대조하여 거래를 해결합니다. 사소한 지연이라도 관련 당사자들에게 막대한 금전적 손실을 초래할 수 있는 경우 감사 추적은 필수 요건입니다.

 

 

부정 행위 탐지 시스템

부정 행위 탐지 시스템은 일반적인 부정 행위의 시작과 밀접하게 일치하는 시나리오를 탐지한 후 즉시 조치를 취해야 합니다. 또한 트리거된 경고와 사고 이후의 후속 이벤트를 기록해야 합니다. 정당한 소유자의 지출 패턴을 기반으로 사기를 탐지하는 금융 시스템 사기 탐지 시스템을 생각해 보십시오. 이벤트 기능을 실시간으로 부정 행위 탐지 모델에 제공하고 위반 가능성을 표시할 때 즉시 조치해야 합니다. 실시간 데이터베이스는 이러한 사용 사례를 구현하기 위한 훌륭한 솔루션입니다.

 

 

IT 시스템 모니터링

중앙 집중식 모니터링을 통해 조직은 IT 시스템을 항상 실행할 수 있습니다. 스트리밍 데이터베이스는 시스템에서 로그를 수집하고 특정 조건이 충족될 때 경고를 생성하는 데 자주 사용됩니다. 이벤트 스토리지를 통해 생성된 실시간 경고 및 감사 추적은 관찰 가능한 시스템 구현의 핵심 요소입니다.

스트리밍 데이터베이스 시장은 붐비는 시장이 아니며 프로덕션 워크로드를 처리하기 위해 경쟁이 치열한 데이터베이스는 소수에 불과합니다. Kafka, Materialize, Memgraph 등이 안정적인 몇 가지입니다. 사용 사례에 맞는 제품을 선택하려면 각 제품의 기능과 사용 사례를 자세히 비교해야 합니다.

이제 스트리밍 데이터베이스에 대한 주요 데이터베이스 설계 원칙과 보증에 대해 알아보겠습니다.

 

 

4가지 주요 스트리밍 데이터베이스 설계 원칙 및 보증

데이터베이스 시스템의 완전성은 종종 데이터베이스가 ACID를 준수하는지 여부로 표시됩니다. ACID 불만 사항은 우수한 데이터베이스 설계 원칙의 기초를 형성합니다. ACID 준수는 원자성, 일관성, 격리 및 내구성을 나타냅니다. 원자성은 문 중 하나에 오류가 있을 경우 논리 연산의 문 그룹 부분이 정상적으로 실패한다는 보장입니다. 이러한 문 그룹을 트랜잭션이라고 합니다. 스트리밍 데이터베이스의 초기에는 트랜잭션 지원 및 그에 따른 원자성이 누락되는 경우가 많았습니다. 그러나 최신 버전은 트랜잭션을 지원합니다.

일관성은 고유한 키 제약 조건, 외부 키 제약 조건 등과 같이 데이터베이스에 의해 시행되는 규칙을 준수하는 것을 의미합니다. 결과 상태가 이러한 규칙을 준수하지 않으면 일관된 데이터베이스가 트랜잭션을 반환합니다. 격리는 한 트랜잭션이 다른 트랜잭션에 영향을 미치지 않도록 별도의 트랜잭션 실행 개념입니다. 이를 통해 트랜잭션을 병렬로 실행할 수 있습니다. KSQLDB와 같은 데이터베이스는 쿼리의 강력한 일관성과 병렬 실행을 지원합니다. 내구성은 고장 지점에서 복구하는 것입니다. 아키텍처의 분산 특성은 최신 스트리밍 데이터베이스에 강력한 내구성을 보장합니다.

스트리밍 데이터베이스의 경우 보증은 이벤트 처리에 대한 보증을 의미합니다. 데이터가 지속적으로 이동하기 때문에 이벤트 처리 순서를 보장하거나 중복 처리를 피하기 어렵습니다. 모든 데이터를 한 번에 정확하게 처리하는 것은 비용이 많이 드는 작업이며 상태 저장 및 승인이 필요합니다. 마찬가지로, 메시지가 수신된 순서와 동일하게 처리되도록 하려면 분산 응용프로그램의 경우 복잡한 아키텍처가 필요합니다.

이제 핵심 설계 원칙과 스트리밍 데이터베이스에서 이 원칙이 어떻게 달성되는지 알아보겠습니다.

 

1. 자동 복구

스트리밍 데이터베이스의 경우 자동 복구는 가장 중요한 데이터베이스 설계 원칙 중 하나입니다. 스트리밍 데이터베이스는 의료, 금융 시스템 등과 같이 규제가 엄격한 영역에서 사용됩니다. 이러한 영역에서는 실패에 대한 변명이 없으며, 사건이 발생하면 막대한 금전적 손실이나 심지어 인명 손실을 초래할 수 있습니다.

의료 IoT 플랫폼의 일부로 통합된 스트리밍 데이터베이스를 상상해 보십시오. 센서는 환자의 중요 매개변수를 모니터링하여 클라우드에서 호스팅되는 스트리밍 데이터베이스로 전송합니다. 이러한 시스템은 절대 중단될 수 없으며 임계값을 기반으로 경고를 생성하는 쿼리가 무기한 실행되어야 합니다.

오류는 스트리밍 데이터베이스에 대한 옵션이 아니므로 분산 아키텍처를 기반으로 구현되는 경우가 많습니다. 노드 클러스터를 기반으로 설계된 스트리밍 데이터베이스는 몇 개의 노드가 중단되더라도 시스템의 나머지 부분은 쿼리를 수락할 수 있는 상태를 유지하기 때문에 뛰어난 내결함성을 제공합니다. 이러한 내결함성은 개발 주기의 초기에 스트리밍 데이터베이스 설계에 통합되어야 합니다. 이제 스트리밍 데이터베이스의 자동 복구와 관련된 주요 활동을 살펴보겠습니다.

분산 스트리밍 데이터베이스의 자동 복구에는 다음 작업이 포함됩니다:

 - 장애 감지

- 재조정 및 지능형 라우팅

- 최종 복구

 

장애 감지는 자동 복구의 첫 번째 단계입니다. 시스템은 복구에 필요한 단계를 수행할 수 있도록 장애 상태를 감지할 수 있을 정도로 자체 인식 상태여야 합니다. 분산 시스템에서 장애 감지는 일반적으로 하트비트 메커니즘을 통해 수행됩니다. 하트비트는 노드가 클러스터의 마스터에게 각각 또는 각각 보낸 주기적인 경량 메시지입니다. 이것은 다른 사람들에게 그것이 살아있고 발로 차고 있다는 것을 알게 합니다. 노드에서 하트비트 메시지가 수신되지 않으면 시스템은 노드가 비활성 상태라고 가정하고 복구 절차를 시작합니다. 하트비트 메시지의 크기, 번들 정보 및 하트비트 메시지의 빈도는 리소스를 최적화하는 데 중요합니다. 매우 빈번한 하트비트는 오류를 훨씬 더 빨리 감지하는 데 도움이 되지만 처리 시간이 너무 오래 걸리고 오버헤드가 발생하기도 합니다.

분산 시스템에서 노드 장애가 발생하면 해당 노드가 소유한 리소스를 다른 노드로 재조정해야 합니다. 분산 시스템은 제어된 복제 기능을 사용하여 노드 중 일부가 다운되어도 데이터가 손실되지 않도록 합니다. 노드가 다운되면 시스템은 다른 노드 간에 데이터 균형을 재조정하고 복제 전략을 최대한 유지하여 데이터 손실 위험을 줄입니다.

가용성이 높은 스트리밍 데이터베이스를 유지하려면 부분적인 장애가 발생한 경우 재조정하는 것만으로는 충분하지 않습니다. 스트리밍 데이터베이스의 경우 쿼리가 항상 실행되므로 시스템은 쿼리가 계속 실행되도록 해야 합니다. 여기서 지능형 라우팅이 시작됩니다. 지능형 라우팅은 쿼리가 계속 실행되고 결과가 반환되도록 보장합니다. 장애가 발생한 노드의 리소스를 사용하는 쿼리는 다른 노드로 원활하게 라우팅됩니다. 이를 위해서는 신중한 설계가 필요하며 스트리밍 데이터베이스에 대한 기본 요구사항의 일부입니다.

최종 복구에는 사고가 발생하는 동안 손실된 상태 저장소를 복구하는 작업이 포함됩니다. 상태 저장소는 시스템이 사용자 구성 제약 조건을 정확하게 한 번, 최대 한 번 또는 최소한 처리 보증을 충족하도록 보장하기 위해 필요합니다. 분산 데이터베이스는 종종 무한 로그를 진실의 소스로 사용합니다. 또한 시간 오프셋을 복구 메커니즘으로 유지하는 별도의 항목을 사용합니다. 오류가 발생한 경우 이 시간 오프셋 항목을 사용하여 이벤트의 시간 표시 막대를 다시 만들 수 있습니다.

 

2. 정확히 한 번의 의미

스트리밍 데이터베이스의 경우 장애 발생 시 자동 복구만으로는 충분하지 않습니다. 전통적인 데이터베이스 설계와 달리 스트리밍 데이터베이스 설계는 실패 시 손실된 결과가 다운스트림 소비자에게 영향을 미치지 않도록 보장해야 합니다. 이를 달성하는 데는 몇 가지 측면이 있습니다. 첫째, 시스템은 레코드 처리 누락이 없도록 해야 합니다. 이 작업은 모든 기록을 재처리하여 수행할 수 있지만 위험이 수반됩니다. 한 예로, 적절한 고려 없이 재처리하면 레코드가 두 번 이상 처리될 수 있습니다. 이로 인해 부정확한 결과가 발생합니다. 예를 들어 경고가 생명을 좌우하는 동일한 의료 IOT 플랫폼을 생각해 보십시오. 중복 처리로 인해 경고가 중복되어 리소스가 낭비될 수 있습니다. 또한 중복 처리를 통해 평균, 백분위수 계산 등의 집계 결과를 얻을 수 있습니다.

요구 사항에 따라 이벤트 처리 시 일부 오류가 허용될 수도 있습니다. 스트리밍 데이터베이스는 요구사항이 다른 사용 사례를 지원하기 위해 다양한 메시지 처리 보증을 정의합니다. 사용할 수 있는 메시지 보증에는 세 가지 유형(최대 한 번, 최소 한 번, 정확히 한 번)이 있습니다. 최대 한 번 보증은 메시지가 두 번 이상 처리되지 않지만 처리를 놓칠 수 있는 경우를 정의합니다. 한 번 이상 보증은 중복 처리가 허용되지만 누락된 레코드는 허용되지 않는 경우를 정의합니다.

정확히 한 번만 의미론은 메시지가 한 번만 처리된다는 것을 보장하며, 결과는 소비자가 실패 사고를 인식하지 못할 정도로 정확합니다. 다이어그램을 사용하여 이 개념을 살펴보겠습니다.

스트리밍 데이터베이스의 4가지 주요 설계 원칙 및 보장 2

 

 

시스템이 순서대로 수신되는 메시지를 처리하고 있다고 가정해 보겠습니다. 대표적으로, 메시지는 여기서 1부터 순서대로 나열됩니다. 프로세서는 메시지를 수신하고 논리에 따라 변환 또는 집계하여 소비자에게 전달합니다. 위 다이어그램에서 녹색은 아직 처리되지 않은 메시지를 나타내고 빨간색은 처리된 메시지를 나타냅니다. 메시지가 처리될 때마다 프로세서는 오프셋을 사용하여 상태 저장소를 업데이트합니다. 이는 장애 발생 시 복구를 활성화하기 위한 것입니다. 이제 프로세서가 두 번째 메시지를 처리한 후 오류가 발생하여 충돌한다고 가정해 보겠습니다. 프로세서가 다시 작동하면 메시지 2가 아닌 3부터 처리를 다시 시작해야 합니다. 상태 저장소에 중복 업데이트를 하거나 메시지 2의 결과를 소비자에게 다시 제공하지 않아야 합니다.

즉, 시스템은 결과 관점과 시스템 간 통신 관점 모두에서 오류를 마스킹합니다. 이를 위해서는 생산자, 메시징 시스템 및 소비자가 합의된 계약을 기반으로 협력해야 합니다. 메시지 배달 확인은 스트리밍 데이터베이스가 이를 수행하는 데 도움이 될 수 있는 가장 간단한 보증입니다. 계약은 중개인의 실패, 생산자와 중개인 간의 통신 실패, 심지어 소비자의 실패까지 견뎌낼 수 있어야 합니다.

 

3. 주문 외 기록 처리

우수한 데이터베이스 설계는 순서가 잘못된 레코드를 처리하는 것을 중요한 측면으로 간주합니다. 스트리밍 데이터베이스는 여러 가지 이유로 인해 순서가 잘못된 레코드에 직면합니다. 그 이유로는 네트워크 지연, 생산자 신뢰성 저하, 동기화되지 않은 클럭 등이 있습니다. 처리 순서가 매우 중요한 금융 및 의료와 같은 매우 민감한 애플리케이션에서 사용되기 때문에 스트리밍 데이터베이스는 이를 정중하게 처리해야 합니다. 문제를 더 잘 이해하기 위해 동일한 IOT 의료 플랫폼의 예를 살펴보겠습니다. 일시적인 인터넷 연결 오류로 인해 장치 중 하나가 짧은 시간 동안 데이터를 전송하지 못했다고 가정해 보겠습니다. 그것이 재개되었을 때, 그것은 재개 시간으로부터 데이터를 보내기 시작했습니다. 잠시 후 장치의 펌웨어가 이전에 전송하지 못한 나머지 데이터를 전송했습니다. 이로 인해 스트리밍 데이터베이스에 잘못된 레코드가 도달하게 됩니다.

더 나은 상황을 위해 이제 다이어그램을 사용하여 이 문제를 설명하겠습니다. 아래 다이어그램에는 1부터 시작하는 숫자로 메시지를 보내는 생산자가 있습니다. 녹색 블록은 아직 전송되지 않은 이벤트를 나타내고 빨간색 블록은 여기서 이미 전송된 이벤트를 나타냅니다. 메시지 1, 2, 3이 타임스탬프 순서대로 도착하면 모든 것이 정상입니다. 그러나 메시지 중 하나가 도중에 또는 소스 자체에서 지연되면 스트리밍 플랫폼의 결과에 손상을 초래합니다. 이 경우 메시지 1과 3이 2보다 먼저 도착했습니다. 스트리밍 플랫폼은 1과 3 다음에 2를 수신하지만 다운스트림 소비자가 실제 순서대로 메시지를 수신하는지 확인해야 합니다.

스트리밍 데이터베이스의 4가지 주요 설계 원칙 및 보장 3

 

레코드를 처리하는 스트리밍 데이터베이스는 순서가 잘못된 레코드가 제대로 처리되지 않으면 다운스트림 시스템에 부정확한 결과를 제공합니다. 예를 들어 메시지가 온도 값을 나타내며 마지막 1분 동안의 평균 온도를 찾는 지속적인 쿼리가 있다고 가정합니다. 온도 값이 지연되면 평균 값이 잘못될 수 있습니다. 스트리밍 데이터베이스는 두 가지 방법으로 이러한 경우를 처리합니다. 첫 번째 방법에는 각 마이크로 배치가 시작되기 전에 프로세서가 순서가 잘못된 레코드가 도착하기를 기다리는 시간을 정의하는 구성 매개 변수가 포함됩니다. 마이크로 배치는 실시간 쿼리의 일부인 레코드 그룹입니다. 마이크로 배치의 개념은 영구 쿼리의 기초입니다.

순서가 잘못된 레코드를 처리하는 두 번째 방법은 프로세서가 이미 계산된 결과를 업데이트할 수 있도록 하는 것입니다. 이를 위해서는 소비자와의 합의가 필요합니다. 이 개념은 트랜잭션 개념과 직접적으로 충돌하므로 구현 시 신중한 설계가 필요합니다. 이것은 다른 순서로 입력을 받았더라도 다운스트림 소비자가 동일한 출력을 생성할 수 있는 경우에만 작동합니다. 예를 들어 다운스트림 소비자의 출력이 수정을 허용하는 테이블인 경우 스트리밍 데이터베이스는 이 전략을 사용할 수 있습니다.

 

4. 일관된 쿼리 결과

스트리밍 데이터베이스 구현은 일반적으로 분산 아키텍처를 기반으로 합니다. 기존의 데이터베이스 설계 원칙은 원자성과 일관성을 우수한 데이터베이스 설계의 핵심 요소로 간주합니다. 그러나 스트리밍 데이터베이스의 경우 분산된 특성 때문에 쓰기의 일관성을 유지하기가 어렵습니다. 복제된 파티션의 개념을 사용하고 노드 클러스터에 배포되는 스트리밍 데이터베이스를 생각해 보십시오. 수익 흐름은 스토리지 패턴에 따라 서로 다른 파티션 또는 노드로 이동합니다. 진정한 쓰기 일관성을 보장하려면 모든 파티션이 스트림을 성공적으로 반영할 때만 스트림을 확인해야 합니다.

논리적 트랜잭션의 일부로 여러 개의 메시지가 있는 경우에는 이 작업이 어렵습니다. 트랜잭션을 성공으로 표시하기 전에 개별적으로 추적하고 각 메시지를 확인하는 것이 중요합니다.

쓰기 일관성을 보장하는 어려움은 읽기 일관성에도 영향을 미칩니다. 읽기가 일관된 경우에만 일관된 쿼리 결과를 반환할 수 있습니다. 서로 다른 비즈니스 논리에 따라 스트림을 집계하는 여러 개의 영구 쿼리에 대한 데이터 소스 역할을 하는 스트림을 생각해 보십시오. 스트리밍 데이터베이스는 두 쿼리가 단일 진실 소스에서 작동하고 쿼리 결과가 충돌하지 않는 값을 반영하는지 확인해야 합니다. 이는 순서가 잘못된 레코드를 처리하기 위해 대부분의 데이터베이스가 연속 업데이트 모드에서 작동하여 이전에 계산한 결과를 변경하는 경우가 많기 때문에 매우 어려운 제안입니다. 연결된 쿼리의 경우 이러한 업데이트는 서로 다른 시간에 다운스트림 스트림으로 유입되며, 일부 파생된 쿼리 상태는 다른 소스 데이터 상태를 반영할 수 있습니다.

일관된 쿼리 결과의 문제를 해결하는 두 가지 방법이 있습니다. 첫 번째 방법은 해당 스트림에서 발생하는 모든 쿼리가 완료될 때까지 쓰기가 확인되지 않도록 함으로써 이 문제를 처리합니다. 이것은 생산자 입장에서는 비쌉니다. 정확한 한 번 처리 요구 사항을 충족하기 위해 대부분의 스트리밍 데이터베이스는 브로커와 생산자 간의 확인에 의존합니다. 쿼리 완료 후에만 모든 쓰기가 확인되면 생산자는 훨씬 더 오랫동안 비밀에 부쳐집니다. 이 접근 방식은 쓰기 시 블록 방식입니다.

일관성을 해결하기 위한 두 번째 접근 방식은 쿼리 엔진 수준에서 수행하는 것입니다. 여기서 쿼리 엔진은 모든 쓰기가 확인될 때까지 강력한 일관성 보장이 필요한 특정 쿼리의 결과를 지연시킵니다. 이것은 입력 스트림의 쓰기 성능에 영향을 주지 않기 때문에 첫 번째 접근 방식보다 비용이 적게 듭니다. 이 접근 방식은 쿼리의 기초 역할을 하는 입력 스트림의 확인을 지연시키는 대신 쿼리 수준에서 작동합니다. 따라서 쿼리에 강력한 일관성 보장이 필요하지 않은 경우 동일한 입력 스트림에 의존하는 다른 쿼리보다 먼저 결과가 출력됩니다. 따라서 일관성 구성에 따라 동일한 입력 스트림의 서로 다른 버전에서 서로 다른 쿼리가 작동합니다. 이를 위해 스트리밍 데이터베이스는 여러 쿼리가 실행된 데이터 버전을 쉽게 결론 내릴 수 있도록 모든 계산의 선형화된 기록을 유지해야 합니다.

스트리밍 데이터베이스는 성능을 최적화하기 위해 데이터의 안정성과 일관성 수준 간의 균형을 유지해야 합니다. 일관성 수준을 높이면 처리 속도가 저하될 수 있으며, 그 반대의 경우도 마찬가지입니다.

 

결론

스트리밍 데이터베이스는 실시간 처리 응용프로그램의 기초입니다. 기존 데이터베이스를 대체하는 것은 아니지만, 데이터 스트림에서 항상 작동하는 처리가 필요한 고유한 요구사항을 충족하는 데 도움이 됩니다. 스트리밍 데이터 처리에 관련된 제약으로 인해 스트리밍 데이터베이스를 설계하는 것은 복잡한 작업입니다. 스트리밍 데이터베이스를 설계할 때 고려되는 일반적인 설계 원칙은 읽기 일관성 달성, 순서가 잘못된 데이터 처리, 한 번만 처리 및 자동 복구입니다.