Real-Time Data Platforms: SingleStore vs Databricks

 

SingleStore와 Databricks는 모두 고객들이 직면한 중요한 과제를 해결할 수 있는 훌륭한 데이터 플랫폼입니다.

---

그러나 Databricks와 달리 SingleStore는 처음부터 성능을 최우선으로 고려하여 설계되었고, 이는 곧 비용 절감에 여러 이점을 가져왔습니다. 이번 글은 이러한 차이점을 살펴볼 여러 시리즈 중 첫 번째 글로, SingleStore가 뛰어난 영역인 실시간 분석 및 운영에 관한 주제로 시작하겠습니다.

 

또한, SingleStore은 실시간이 아닌 일괄 ETL 작업에서도 비용과 성능 면에서 이점이 있음을 확인했으며, 이어진 글에서 설명드리도록 하겠습니다.

 

Understanding the value of real-time data

먼저, 실시간 데이터의 중요성을 알아보겠습니다. 고객들은 왜 실시간 데이터를 중요하게 생각할까요?

간단하게 말하자면, 많은 사용 사례를 보면 데이터의 가치는 시간이 지남에 따라 감소한다는 것입니다. 마케팅 캠페인을 최적화하거나, 거래 속도를 모니터링하거나, 실시간 재고 업데이트를 진행하거나, 네트워크 지연 또는 보안 이벤트를 관찰하는 경우, 고객 반응이 지연되면 바로 재정적 손실이라는 결과로 이어집니다. 이러한 소스들에서 생성된 이벤트는 계속해서 스트림으로 흘러 들어오고 있으며, 이것이 스트리밍 기술의 발전으로 이어졌습니다.

 

"많은 고객들과의 대화에서 우리는 일관된 1초 이내의 지연 시간이 필요한 여러 사례를 접했습니다. 이러한 낮은 지연(latency) 사용 사례는 운영 알림 및 실시간 모니터링과 같은 응용 프로그램에서 나타납니다. 이를 '운영 워크로드(operational workloads)'라고도 합니다.”

 

SingleStore에서는 밀리세컨드(ms) 단위로 처리하는데, 이는 고객에게 아주 중요한 사항이기 때문입니다. 이것을 품질 지연 시간(Quality Latency)라고 부르고, 한 이벤트가 플랫폼에 들어오고 목적지에 도달하며 가치를 생성하는 데 걸리는 시간으로 정의하겠습니다. 여기에는 고려해야 할 다른 중요한 요소들이 있으며, Databricks는 글에서 "사용자에게 처리량, 비용 및 지연 시간(latency) 간의 균형을 맞추기 위한 유연성을 제공"을 설명하는 요소들을 올바르게 지적하고 있습니다. 우리는 이상적인 실시간 데이터 플랫폼에 대한 목표를 완성하기 위해 단순성과 가용성이라는 두가지 요건을 추가할 것입니다.

 

          1. 지연 시간의 최소화

          2. 처리량의 극대화

          3. 비용의 최소화

          4. 가용성의 극대화

          5. 단순성의 극대화

 

How SingleStore handles real-time use cases

먼저 다음 그림과 같이 실시간 데이터 사용 사례에 대한 싱글스토어의 권장 방법, 즉 스트리밍 데이터를 싱글스토어로 수집하여 쿼리하는 방법에 대해 설명하고자 합니다.

 

이 시점에서 여러분은 아마도 "흠? 그게 다야? 분명이 필요한 단계들 더 있을 거야!”라고 생각하고 있을 것입니다.

어떻게 한 데이터 플랫폼이 실시간 SLA를 희생시키지 않으면서 실시간으로 데이터를 수집하고 동시에 분석 쿼리를 처리할 수 있는 것일까요?

저는 회사들이 항상 새롭고 전문화된 스트리밍 제품을 추가하는 것에 대해 이야기 하는 것을 듣습니다.

그들은 어떤 역할을 하는 것일까요?

 

How Databricks handles real-time use case

알고보니 Databricks도 그런 기업 중 하나입니다. 최근에 발표된 "Latency goes subsecond in Apache Spark Structured Streaming"이라는 블로그에서 그들의 접근 방식을 알아보겠습니다. 이 블로그에는 두 개의 그림이 포함되어 있습니다. 첫 번째 그림에서는

 

"분석 워크로드는 일반적으로 실시간으로 데이터를 수집, 변환, 처리하여 분석하고 결과를 객체 스토리지로 백업된 Delta Lake에 기록합니다.”

[여기서 실시간이 중단됩니다]

 

그게 끝이 아닙니다. 블로그에는 완전히 분리된 '운영 워크로드' 구성도 포함되어 있습니다. 이 구성의 존재 자체가 분석 워크로드 구성이 Delta Lake에 도달하면 실시간이 중단된다는 강력한 증거이고, Databricks는 블로그에서 이를 거의 인정하고 있습니다.

 

"반면에, 운영 워크로드는 실시간으로 데이터를 수집, 처리하며 비즈니스 프로세스를 자동으로 트리거합니다."

[이 역시 실시간으로 수행됩니다]

 

두 번째 다이어그램에서 특이한 점은 메시지 버스에서 종료된다는 것입니다. 데이터는 절대 저장되지 않으며 결국 사용되지 않습니다.

Databricks의 실시간 솔루션은 Kafka에서 읽어 변환을 수행하고 다시 Kafka를 사용하고 또는...

 

" Apache Cassandra 또는 Redis와 같은 빠른 키-값 저장소는 비즈니스 프로세스와의 하향 통합을 위해 사용됩니다."

 

...또는 다른 데이터베이스! 데이터 플랫폼 회사인 Databricks가 왜 고객에게 데이터를 다른 데이터베이스에 저장하라고 권장할까요? 그것은 그 데이터베이스들이 Databricks가 제공하지 않는 빠른 포인트 읽기 및 쓰기(CRUD)와 같은 기능을 제공하기 때문입니다. 이들은 이 능력을 활용하기 위해 키-값 형식을 사용하며, 이는 분석 쿼리의 효율성을 희생시키는 대신에 가능해지며, 이러한 데이터베이스 및 Kafka는 분석 쿼리를 쉽고 효율적으로 처리하는 데는 어려움이 있습니다.

 

SingleStoreDB은 특허 기술을 사용한 Universal Storage로, 트랜잭션 및 분석 쿼리를 모두 수행할 수 있습니다. 실제로 SingleStore은 Databricks와 키-값 저장소의 합보다 더 많은 기능을 제공합니다. 왜냐하면 SingleStore은 읽기와 쓰기를 수행하기 위한 단일 SQL 인터페이스를 제공하기 때문입니다.

 

         1. 높은 선택성 ( OLTP, CRUD 포함 )

         2. 중간 선택성 ( 실시간 분석 ) - 오직 SingleStore만이 가능함

         3. 낮은 선택성 ( 대규모 분석 및 대량 인서트 )

 

Databricks가 실시간을 위해 Cassandra 또는 Redis를 권장하는 이유를 설명하는 데 충분하기는 하지만 또 다른 중요한 이유가 있습니다. SingleStore와 이러한 데이터베이스들은 Databricks보다 더 높은 가용성을 제공합니다. SingleStore는 클러스터의 노드 내에서 자동으로 중복성을 갖추고 있으며(스탠다드 에디션), 프리미엄 에디션에서는 버튼 한 번으로 가용성 영역 간(across AZ)에도 자동으로 중복성을 갖출 수 있습니다. 반면 Databricks는 고가용성에 관한 문서를 갖고 있지 않습니다. 대신 Databricks는 시스템의 구성 요소 중 하나인 AWS S3가 고가용성이라고 언급하고 있습니다 (이는 전체 시스템이 고가용성이라는 것을 의미하지 않습니다).

 

이 기능의 부재로 인해 AWS 배포 가이드가 만들어졌습니다. 해당 가이드는 상당한 노력을 기울여 Databricks 클러스터를 두 가용성 영역(AZ)에 배포하는 방법을 설명하고 있습니다. 그러나 주의할 점은 여전히 교차-AZ 클러스터가 아니라 단순히 두 AZ에 클러스터가 존재하는 것뿐이라는 것입니다. Databricks를 기반으로 한 애플리케이션이 AZ 장애에 대해 실제로 허용이 되기를 원한다면, 위의 설정을 구성하고 앱을 두 클러스터에 연결하여 직접 수행해야 합니다. 그러나 이러한 작업은 더 많은 노력, 비용 및 복잡성을 동반하게 됩니다.

 

이 모든 것을 고려할 때, Databricks의 제안을 나타내는 이 그림은 그들이 제안하는 Rube Goldberg Machine 의 더 완전한 표현이자 그 단점들을 보여주고 있습니다.

 

Databricks가 권장하는 운영 스트리밍 파이프라인의 구성은 모두 SingleStore로 대체함으로써 크게 간소화될 수 있습니다. SingleStore는 실시간 용도로 구축되어 있으며 입력에 대해서는 단일 메시지 버스만 필요합니다.

 

 

 

How SingleStore works under the hood

 

어떻게 이게 가능한지 궁금하신가요? SingleStore를 실시간 분석을 위한 간단하고 성능이 뛰어난 플랫폼으로 만드는 아키텍처에 대해 자세히 알아보겠습니다.

 

스트리밍 데이터는 원본에서 생성되며 이벤트는 SingleStore의 파이프라인에 투입됩니다. 이 파이프라인은 완전히 병렬화되어 있으며 Kafka 및 여러 인기있는 형식의 다양한 소스에서 데이터를 읽을 수 있습니다. 실시간 데이터의 또 다른 가능한 원본은 데이터를 삽입, 업데이트, 삭제 및 업서트하기 위한 DML 문입니다. 이러한 작업은 행 레벨 잠금 덕분에 스트리밍 투입과 고속으로 동시에 실행될 수 있습니다. 이는 전체 테이블이 아닌 개별 행이 쓰기를 위해 잠겨질 수 있기 때문에 전체 시스템의 처리량을 크게 높입니다.

 

변환은 SingleStore에서 파이프라인의 엔드포인트로 호출될 수 있는 저장 프로시저와 함께 적용할 수 있으며, 이를 통해 고객은 필터링, 조인, 그룹화 집계 및 여러 테이블에 쓰는 기능을 포함하여 스트리밍 데이터에 복잡한 변환을 적용할 수 있습니다. 파이프라인 엔드포인트로서 작동할 수 있기 때문에 데이터 일괄 처리에 작업하는 단일 분할된 작성기가 있어 병렬성을 용이하게 합니다.

다음은 CDC 데이터를 포함하는 파이프라인에서 그룹화된 데이터에 대한 사용자 지정 러닝 SUM(또는 AVG) 집계를 유지하는 저장 프로시저의 예시입니다. (여기서 'action' 열은 'DELETED' 및 'INSERTED'를 포함할 수 있음)

 

 

변환된 후 데이터는 LSM 트리(SingleStoreDB 테이블을 지원하는 기본 데이터 구조)의 메모리 계층인 티어1에 기록됩니다. 이러한 쓰기는 복제된 WAL(미리 쓰기 로그)을 사용하여 티어 2에 유지되고, 로컬 디스크 및 티어3에 대한 지속성은 지연 시간이 중요하지 않은 백그라운드에서 느리게 수행됩니다. 최종 결과는? 데이터는 일관되게 쿼리 가능하며 응답 시간은 단일 자릿수 밀리초(ms) 내로 유지됩니다.

 

 

Key differences between SingleStore and Databricks architecture

Databricks가 SingleStore에 필적하는 실시간 기능을 제공할 수 없는데에는 2가지 이유가 있습니다.

 

          1. 쓰기의 경우, 티어 1+2가 존재하지 않습니다.

          2. 읽기의 경우, 티어 1이 존재하지 않으며 티어 2는 기본적으로 꺼져 있어 사용이 어렵고 지연 시간이 추가됩니다.

 

먼저 쓰기 경로를 살펴보겠습니다. SingleStore에서는 쓰기가 Tier 1에 도착하고 로그가 Tier 2에 기록되며 데이터가 시스템 전체에 복제되고 즉시 쿼리 가능합니다. 이것을 Databricks와 대조해 보면 Databricks에서는 쓰기가 인식되기 전에 클라우드 객체 스토어까지 이동해야 합니다.

 

읽기 경로도 유사한 제한이 있습니다. SingleStore에서는 Universal Storage가 Tier 1과 2를 모두 활용하며 오직 메모리 rowstore 테이블도 최대 성능 최적화를 위해 사용할 수 있습니다. 이를 Databricks와 비교하면 Databricks는 잘 알려져 있듯이Spark 메모리 레이어에 아무것도 저장하지 않습니다. 이는 읽기를 정말 빠르게 수행하려는 순간까지는 좋은 접근 방식입니다.

 

게다가 Databricks의 디스크 레이어는 기본적으로 꺼져 있으며, 활성화된 경우에도 새로운 데이터는 먼저 객체 스토어에 적제되어야 하고 그런 다음 캐시로 가져와져야 하기 때문에 상당한 지연이 발생합니다. 반면에 SingleStore에서는 새로운 데이터가 들어올 때 이미 디스크에 기록되므로 필요할 때 즉시 읽을 수 있습니다.

 

가장 중요한 것은 Databricks는 클라우드 객체 스토어에 저지연으로 쓰고 읽는 것이 불가능하다는 점을 알고 있으며, 이 능력이 부족한 상태를 보상하기 위해 전체 스트리밍 아키텍처를 설계했다는 것입니다.

 

Databricks는 사용자들에게 애플리케이션을 두 부분으로 나누어 완전히 다른 시스템에서 실행하도록 권장합니다.

 

          1. Spark Structured Streaming 파이프라인을 사용하여 데이터 전처리하기

          2. 전처리된 데이터에 대한 가벼운 쿼리 실행하기

 

그러나 첫 번째 시스템은 지연을 발생시키고 처리를 약한 실시간으로 만들며, 두 번째 시스템은 여전히 많은 상황에서 충분히 낮은 지연 시간을 제공하지 못합니다.

 

SingleStore는 원시 수집 데이터나 파이프라인의 엔드포인트인 저장 프로시저에서 전처리된 데이터에 대한 빠르고 낮은 지연 시간의 쿼리를 수행할 수 있습니다. 후자의 경우 SQL을 사용하여 동일한 환경에서 전처리가 이루어집니다. 이로써 실질적인 실시간 처리가 가능해집니다.

 

Strengths of Databricks

위에서 언급한 모든 내용에도 불구하고 데이터베이스에 전혀 접근하지 않는 스트리밍 아키텍처는 여전히 사용되는 경우가 있습니다. 예를 들어, 저장 공간에 저장될 수 있는 것보다 훨씬 많은 양의 데이터가 있는 경우가 있습니다. 여기서는 하나의 Kafka 스트림에서 이벤트를 몇 가지 변환하고 다른 Kafka 스트림을 다시 방출하여 경고를 트리거하는 경우가 그 예시입니다 .

 

Databricks는 데이터 탐색 분야에서도 큰 발전을 이루었으며, 개발자들은 노트북 인터페이스의 유연성에 만족하고 있습니다.  또한 그들의 제품에는 많은 고급 기계 학습 기능이 있습니다.

 

Databricks는 또한 ETL 작업을 구동하는 데 널리 사용되고 있지만, SingleStore는 이 영역에서도 성능과 비용의 이점을 가지고 있어 몇몇 작업은 SingleStore에서 더 유리할 수 있습니다. 이 시리즈의 향후 블로그에서는 두 제품을 어떻게 함께 사용하는 것이 가장 좋은 방법인지를 다룰 것입니다.

 

Summary: Real-time data platforms: SingleStore vs. Databricks

실시간 사용 사례에서는 Apache Spark Structured Streaming과 다른 데이터베이스를 함께 사용하는 것이 지나치게 복잡하고 비실용적인 해결책일 수 있습니다. 단순히 스트리밍 데이터를 SingleStore에 적재하고 쿼리하는 것이 더 효율적일 수 있습니다.

 

Lower latency

 

• SingleStore는 신규로 삽입된 데이터 및 업데이트에 대한 인메모리 데이터 티어를 갖추고 있으며, 빠른 메타데이터 접근도 가능합니다. 이 레이어는 Databricks에는 없습니다.

 

• SingleStore는 운영 시스템에서 찾을 수 있는 행 레벨 인덱스 및 저렴한 탐색을 지원하는 데이터 형식을 갖고 있습니다. 반면, Databricks는 파일 수준에서 읽기 세트를 제거하는 데 사용되는 중복 데이터 구조만을 지원하며(이는 SingleStore도 수행함), 행 수준에서는 지원하지 않습니다. 이로써 SingleStore는 Databricks보다 훨씬 적은 CPU 및 디스크 I/O를 사용할 수 있게 됩니다. 특히 높은 및 중간 선택성을 갖는 쿼리에서 이점을 얻을 수 있습니다.

 

• SingleStore에서 데이터는 하이브리드 행 및 열 중심 표현식으로 저장될 수 있습니다. 이는 Universal Storage로 시작된 회사의 주요 혁신 분야이며, 최근에는 Column Group Indexes로 확장되었습니다. 이는 또한 SingleStore가 디스크 I/O 및 CPU 비용을 Databricks에 비해 절약할 수 있게 해줍니다. 특히 테이블의 모든 또는 대부분의 열을 선택하는 쿼리에서 이점을 얻을 수 있습니다.

 

 • SingleStore에 대한 쓰기 작업은 인메모리 티어와 Write Ahead Logging (WAL) 덕분에 일관된 쿼리 응답 시간을 수밀리세컨드 내에 얻을 수 있습니다. 객체스토어로 백업된 Delta 테이블에서 끝나는 파이프라인과 비교하면, S3로의 각 blob 쓰기 작업은 최대 100밀리초까지 걸릴 수 있으며, 각 업데이트에 대해 여러 blob 쓰기 작업이 있을 것으로 예상되며, 이는 데이터가 Parquet로 변환된 후에 발생합니다. 이는 지연이 중요한 코드 경로에서는 SingleStore에서 필요하지 않은 또 다른 단계입니다. 마지막으로, end-to-end로 보면 이는 Databricks에 대한 쓰기가 SingleStore보다 10~100배 더 느리다는 것을 의미합니다.

 

 •  위의 모든 이점을 더하면 이 TPC-H 벤치마크에서 볼 수 있듯이 SingleStore 쿼리가 Databricks에 비해 매우 빠르다는 것은 놀라운 일이 아닙니다.

 

More throughput

 

 •   처리량에 영향을 미치는 두 가지 핵심 요소가 있으며, 가장 중요한 것은 지연 시간입니다.  SingleStore 쿼리에 10ms가 걸리고 비슷한 크기의 Databricks 클러스터에서 동일한 쿼리에 1초가 걸리는 경우 다른 모든 조건이 동일하면 SingleStore는 Databricks 처리량의 100배를 갖게 됩니다. 지연 시간 측면에서 SingleStore의 우수성에 대한 자세한 내용은 위의 섹션을 참조해보세요.

 

 •   다른 추가적인 요소는 동시성입니다. 쿼리 간에 간섭이 발생하는 시스템은 처리량이 감소할 것입니다. 모든 다른 조건이 동일한 상황에서도 SingleStore는 이에 대해 Databricks보다 우위를 가집니다. 예를 들어, SingleStore는 기본적으로 행 레벨 잠금을 지원하며, 이는 Databricks에서 테이블 레벨에서만 작동하는 동등한 쓰기 충돌 기능과 비교할 수 있습니다(미리보기로만 제공되는 몇 가지 예외적인 경우를 제외하고). 이러한 유형의 기능은 Databricks에 대해 훨씬 어려운데, 누구든지 언제든지 열려 있는 테이블에 쓸 수 있기 때문에 쓰기 충돌을 피하기 위해 많은 추가 단계를 추가해야 합니다.

 

 •   처리량을 테스트하기 위한 가장 인기 있는 벤치마크는 TPC-C에서 파생된 것으로, 그 결과를 "분당 트랜잭션"으로 제공합니다. 우리는 SingleStore의 TPC-C 성능을 게시했으며, 우리가 알기로는 Databricks는 동일한 성능 테스트를 수행한 적이 없으며 다른 어떤 기관도 성능 평가를 하지 않았습니다.

 

More cost effective

 

 •   SingleStoreDB와 동일한 실시간 SLA를 충족하기 위해 Databricks는 추가적인 데이터베이스와 추가적인 메시징 버스가 필요합니다. 그리고 오픈 소스 소프트웨어를 선택하든 관리형 솔루션을 선택하든 어느 쪽을 선택하더라도 전자는 더 많은 인력이 필요하고 후자는 비용이 들기 때문에 어느 경우에도 더 많은 지출이 예상됩니다.

 

 •   SingleStore는 종종 Databricks보다 동일한 쿼리를 10배에서 100배 빠르게 실행할 수 있으며(latency section참조), SingleStore는 더 나은 동시성을 가지고 있습니다(throughput section 참조). Databricks가 SingleStore의 지연 시간을 따라잡기 위한 투자를 하지 않기 때문에, Databricks 사용자가 동일한 결과를 얻기 위해서는 더 많은 비용을 지출하고 인프라를 확장하는 경우에만 SingleStore의 처리량을 따라올 수 있습니다.  총론적으로, 클라우드 서비스 제공자들은 시간 단위로 비용을 청구하며, 작업을 훨씬 더 빨리 완료할 수 있다면 그만큼 돈을 적게 지불하게 됩니다.

 

More available

 

 •   Databricks는 복제, 교차 가용성, 항상 쿼리에 사용할 수 있는 두 개의 핫 복사본을 보유하고 점진적 백업과 같은 고가용성 기능이 없기 때문에 RPO=0 및 매우 낮은 RTO를 필요로 하는 응용 프로그램 및 사용 사례를 제공할 수 없습니다.

 

Much simpler

 

 •   SingleStore가 더욱 실시간입니다. 스트리밍 데이터의 집계가 5초 또는 1분의 창을 가진 윈도우 함수를 사용하는 경우, SingleStore는 다음 쿼리에서 즉시 부분적인 시간 창의 데이터를 제공할 것입니다. 이와 대조적으로 Databricks 사용자는 스트리밍 파이프라인에서 집계 결과를 계산할 때 해당 창이 종료되고 결과가 데이터베이스에 삽입될 때까지 집계 결과를 볼 수 없습니다.

 

 •   스트림을 조인하는 방식에 대한 이해를 강요하지 않습니다. 테이블을 조인하는 것은 훨씬 더 이해하기 쉽습니다.

 

 •   늦게 도착하는 데이터에 대해 걱정할 필요가 없습니다. 일부 이벤트가 늦게 발생하더라도 다음 쿼리에서는 과거의 이벤트 타임라인에서 발생한 변경 사항을 반영할 것입니다.

 

 •   정확히 한 번만 지원하므로 "정확히 한 번의 엔드투엔드 처리가 지원되지 않는" Databricks와 달리 데이터가 손실되지 않습니다.

 

 •   저장 프로시저로 끝나는 파이프라인은 변환을 수행하고 실행 중인 집계를 유지 관리할 수 있습니다.

 

 •   SingleStore는 read-modify-write를 지원하여 최종 사용 사례를 더 간단하게 만들 수 있으며, 순수한 이벤트 기반 프로그래밍 및 데이터 모델링 패러다임을 고수할 필요가 없습니다.

 

 •   SingleStore는 노트북이나 저장 프로시저에서 코드를 저장하고 실행할 수 있으나, Databricks는 노트북만을 가지고 있습니다.

 

 •   마지막으로, 계속 이야기 해서 지겨우시겠지만, 반복해서 언급할 가치가 있습니다. 싱글스토어는 다른 추가 데이터베이스가 필요하지 않습니다.

 

 •   간단히 말하면, SingleStore의 쿼리는 매우 효율적이고 신뢰성 있게 빠르고, 높은 동시성을 지원하며, 고가용성과 결합되어 매우 중요한 애플리케이션을 구동합니다. 이것이 LiveRamp와 Outreach 같은 기업들이 미션 크리티컬하고 실시간 분석 워크로드를 구동하기 위해 SingleStore를 신뢰하는 이유입니다. (이 회사들은 Databricks 또한 사용하고 있습니다.)

 

다음은 토론한 모든 내용을 정리한 표입니다.