실시간 대시 보드와 빠른 업데이트를 위한 SingleStore의 벤치 마크

최신 Upsert 벤치 마크는 통신사, ISP 및 CDN을

통한 인터넷 청구에서 중요한 사용 사례를 보여줍니다. SingleStore는 초당790 만 건의 Upsert를 달성했으며,

현재 GitHub에서 제공되는 Cassandra 벤치 마크 세부 정보 및 스크립트보다 6 배 빠릅니다.

빠른 업데이트 및 실시간 대시 보드에 대한 비즈니스 요구

기업은 데이터에서 통찰력을 원하며 정보를 보다 빨리 얻기를 원합니다. 빠르게 변화하는 데이터를 위해서는 올바른 결정을 내리기 위해 통찰력을 신속하게 수집해야합니다. IoT 원격 측정 모니터링, 모바일 네트워크 사용, 인터넷 서비스 제공 업체 (ISP) 청구 및 콘텐츠 전송 네트워크(CDN) 사용 추적과 같은 산업 응용 프로그램은 빠르게 변화하는 데이터를 사용하는 실시간 분석에 따라 다릅니다. 웹 트래픽은 놀라운 속도로 계속 증가하기 때문에 특별한 주의를 기울일 필요가 있습니다. 시스코에 따르면 글로벌 IP 트래픽은 향후 5 년 동안 거의 3 배 증가하고 2005 년에서 2020 년까지 거의 100 배 증가 할 것입니다. 전체적으로 IP 트래픽은 2015 년에서 2020년까지 22 %의 연평균 성장률 (CAGR)로 증가 할 것 입니다. 비즈니스는 대규모 웹 트래픽을 모니터링, 분석 및 수익을 창출해야 하는 과제에 직면해 있으므로 이 사용 사례를 살펴 보겠습니다.

---

​

사용 사례

특히, 우리는 CDN (Content Delivery 또는 Distribution Network)의 예에 대해 설명합니다. CDN은 여러 지역에 걸쳐 여러 데이터 센터에 배포된 전 세계에 분산된 웹 서버 네트워크로, 미디어 회사 및 전자 상거래 공급 업체와 같은 콘텐츠 제공 업체가 최종 사용자에게 콘텐츠를 제공합니다. CDN은 업무상 시스템을 실시간으로 모니터링해야 합니다. 청구 목적으로 고객 사용량을 기록하는 것 외에도 로드 밸런싱 및 "서비스 거부 공격"과 같은 네트워크 이벤트를 감지하기 위해 워크로드가 갑자기 증가 및 감소한다는 알림을 받고자합니다. 대량의 웹 트래픽의 로드를 지원하기 위해 확장할 수 있는 대규모 병렬 처리 (MPP) 시스템을 요구합니다. 실시간 분석에 대한 요구는 하이브리드 트랜잭션 / 분석 처리 또는 HTAP가 핵심입니다. HTAP 시스템은 데이터 이동이나 ETL없이 동시에 고속 수집 및 정교한 분석을 가능하게합니다.

​

Upsert 벤치 마크에 대한 배경

이 벤치 마크는 대용량 업데이트를 수용하는 데이터베이스 시스템의 강력한 성능을 보여줍니다. Update 또는 Upsert는 여기서 핵심 단어입니다. 기존 Insert의 각 데이터베이스 항목마다 새 행이 작성됩니다. Upsert를 사용하면 개별 행을 업데이트 할 수 있습니다. 이 Upsert 기능은 보다 효율적인 데이터베이스 테이블과 빠른 집계를 가능하게 하며 특히 인터넷 청구와 같은 영역에서 유용합니다. 이 사용중인 작업량에 대한 자세한 내용은 이 블로그 게시물 (High-Speed Counter로 Volume 켜기)을 참조하십시오.

SingleStore는 다음과 같은 매개 변수화된 쿼리를 사용하여 10 노드 클러스터에서 초당 최대 8 백만 개의 효율적인 Upsert 성능을 제공합니다.

​

SingleStore에 대한 Upsert 쿼리

insert into records (customer_code, subcustomer_id, geographic_region, billing_flag, bytes, hits) values on duplicate key update bytes=bytes+VALUES(bytes),hits=hits+VALUES(hits);

​

Upsert 성능 비교

레거시 데이터베이스 및 데이터웨어 하우징 솔루션은 데이터의 Batch 로드에 최적화되어 있으며 새로 생성된 데이터에 대한 분석과 함께 빠른 데이터 삽입을 처리할 수 ​​없습니다. Cassandra와 같은 NoSQL 데이터베이스는 빠른 데이터 삽입을 처리 할 수 ​​있지만 최종 소비자의 행동에 대한 웹 트래픽 모니터링 및 웹 추적에 중요한 Upsert를 사용할 때 상당히 많은 문제가 발생합니다. 그러나 Cassandra는 분석에 대한 기본 지원을 제공하지 않으며 의미있는 데이터 쿼리를 지원하기 위해 SparkSQL과 같은 추가 구성 요소를 가져와야 합니다.

Cassandra에 대해 다음 쿼리를 작성했습니다.

​

Cassandra에 대한 Upsert 쿼리

update perfdb.records set hits = hits + 1 where timestamp_of_data=1470169743185 and customer_code=25208 and subcustomer_id='ESKWUEYXUKRB' and geographic_region=10 and billing_flag=1 and ip_address='116.215.6.236';

update perfdb.records set hits = hits + 1 where timestamp_of_data=1470169743185 and customer_code=25208 and subcustomer_id='ESKWUEYXUKRB' and geographic_region=10 and billing_flag=1 and ip_address='116.215.6.236';

​

Upsert 벤치 마크는 10 개의 서로 다른 지역에서 웹 트래픽을 기록하는 시뮬레이션 된 워크로드를 기반으로합니다. SingleStore 5.1은 AWS의 10 노드 m4.10xlarge 클러스터에서 시간당 $ 2.394 (1 년 예약 인스턴스 가격)로 실행되며 초당 최대 8 백만 건의 Upsert를 실행하고 최신 데이터에 대한 실시간 쿼리를 동시에 실행할 수 있습니다 변화하는 트래픽 형태에 대한 실시간 데이터를 제공합니다.

동일한 클러스터에서 실행되는 Cassandra는 초당 150 만 번의 Upsert를 달성합니다. 최신 3.0.8 버전의 Apache Cassandra를 테스트했습니다. Cassandra 쿼리에서 update는 upsert를 의미합니다.

다음 차트에서 알 수 있듯이 배치 크기가 500 인 컴퓨터 수를 늘리면 SingleStore가 선형으로 확장됩니다. 그러나 Cassandra는 큰 배치 크기를 제대로 지원하지 않는 것으로 보입니다. Cassandra에는 다음과 같은 메시지가 출력됩니다.

# Caution should be taken on increasing the size of this threshold as it can lead to node instability. # Fail any batch exceeding this value. 50kb (10x warn threshold) by default.

따라서 10,000 행 배치 크기를 지원하도록 batch_size_fail_threshold_in_kb: 5000으로 설정 했지만 이러한 설정으로 벤치 마크가 Cassandra에서 실행되지 못하게하는 수많은 오류가 발생했습니다.

​

SingleStore, Cassandra간의 또 다른 차이점 

SingleStore에는 일관되고 내구성 있는 트랜잭션이 있지만 Cassandra는 덜 엄격한(stringent) 시맨틱을 가지고 일관된 논트랜잭션(Non-transactional) 카운터가 있습니다. 따라서 SingleStore가 처리하는 모든 Insert는 트랜잭션 일관성이 있고 즉시 사용 가능합니다. Cassandra의 카운터는 대신 트랜잭션 시맨틱 없이 최종 일관성을 제공합니다. 요컨대 SingleStore는 ACID 준수를 유지하고 Cassandra는 유지하지 않으며 ACID 보증 유지는 청구(Billing)와 같은 중요한 환경에 응용 프로그램을 구축하는 데 중요한 부분입니다.

​

Upsert 못지 않게 중요한 분석

물론 들어오는 데이터는 그림의 일부일 뿐 입니다. 중요한 보완은 데이터를 기록하자마자 정교한 쿼리를 실행할 수 있는 기능입니다.

Cassandra는 SingleStore와 달리 기본적으로 분석 쿼리를 지원하지 않으며 사용자는 동일한 클러스터 또는 다른 클러스터에 SparkSQL을 설치해야합니다. 추가적인 복잡성 외에도, 사용자는 SparkSQL이 분석 쿼리를 실행하기 전에 Spark 데이터 프레임으로 데이터를 읽어야하기 때문에 추가 대기 시간에 직면하게됩니다.

​

정교한 쿼리는 기본적으로 SingleStore에서 실행됩니다.

SingleStore는 기본 SQL 엔진이 포함된 완전 관계형 데이터베이스이므로 사용자는 데이터를 저장한 후 즉시 정교한 쿼리를 실행할 수 있습니다. 인터넷 청구 응용 프로그램에서 사용할 수 있는 몇 가지 샘플 쿼리는 다음과 같습니다.

다음 쿼리는 전달된 바이트 수를 기준으로 10 개 지역 각각의 상위 5 개 고객을 나열합니다.

​

각 지역의 상위 5 개 고객

select *
from (
    select *, row_number() over (partition by geographic_region order by bytes desc rows between unbounded preceding and current row) as rank
    from records
    where timestamp_of_data > now() - interval 1 minute
    ) as REGIONS_WINDOWED
where rank <= 5;

CDN은 로드 밸런싱을 늘리거나 추가 용량을 프로비저닝하기 위해 트래픽 급증을 모니터링 해야합니다. 다음 쿼리는 트래픽 증가 측면에서 상위 10 명의 고객을 나열합니다.

​

마지막 1 초 동안 상위 10 개 증가

 

with
RECORDS_AGGREGATED as (
    select timestamp_of_data, subcustomer_id, sum(bytes) as bytes, UNIX_TIMESTAMP(timestamp_of_data) as epoch_seconds
    from records
    where timestamp_of_data between (now() - interval 2 second) and (now() - interval 1 second)
    group by timestamp_of_data, subcustomer_id
    ),
RECORDS_WINDOWED as (
    select *
        ,lead(bytes, 1) over (partition by subcustomer_id order by timestamp_of_data desc rows between unbounded preceding and current row) as bytes_prev
        ,lead(epoch_seconds, 1) over (partition by subcustomer_id order by timestamp_of_data desc rows between unbounded preceding and current row) as epoch_seconds_prev
    from RECORDS_AGGREGATED
    ),
TRAFFIC_SURGES as (
    select timestamp_of_data, subcustomer_id, epoch_seconds, bytes,
       bytes - if(epoch_seconds_prev = epoch_seconds - 1, bytes_prev, 0) as bytes_change
    from RECORDS_WINDOWED
    where epoch_seconds = unix_timestamp(now()) - 1
    )
select timestamp_of_data, subcustomer_id, epoch_seconds, bytes, bytes_change
from TRAFFIC_SURGES
order by bytes_change desc
limit 10;

일반적으로 웹 트래픽의 급격한 증가는 특별 이벤트나 프로모션으로 인한 고객의 관심 증가로 인한 것일 수 있습니다. 그러나 경우에 따라 서비스 거부 공격으로 인해 급격한 증가가 발생합니다. 다음 쿼리는 상대적으로 적은 수의 IP 주소에서 많은 수의 요청으로 인해 급격한 증가가 발생하는 경우 DDoS 공격 경고를 생성합니다. 급격한 증가는 평균과의 표준 편차가 두 개 이상 증가한 것으로 정의됩니다.

 

with
RECORDS_AGGREGATED as (
    select timestamp_of_data, subcustomer_id, sum(bytes) as bytes,
           UNIX_TIMESTAMP(timestamp_of_data) as epoch_seconds,
           approx_count_distinct(ip_address) as unique_ip_addrs
    from records
    where timestamp_of_data between (now() - interval 2 second) and (now() - interval 1 second)
    group by timestamp_of_data, subcustomer_id
    ),
RECORDS_WINDOWED as (
    select *
        ,lead(bytes, 1) over (partition by subcustomer_id order by timestamp_of_data desc rows between unbounded preceding and current row) as bytes_prev
        ,lead(epoch_seconds, 1) over (partition by subcustomer_id order by timestamp_of_data desc rows between unbounded preceding and current row) as epoch_seconds_prev
    from RECORDS_AGGREGATED
    ),
TRAFFIC_SURGES as (
    select timestamp_of_data, subcustomer_id, epoch_seconds, bytes, unique_ip_addrs,
       bytes - if(epoch_seconds_prev = epoch_seconds - 1, bytes_prev, 0) as bytes_change
    from RECORDS_WINDOWED
    where epoch_seconds = unix_timestamp(now()) - 1
    )
select timestamp_of_data, subcustomer_id, epoch_seconds, bytes, bytes_change
from TRAFFIC_SURGES
where unique_ip_addrs < 100 and bytes_change > (select avg(bytes_change) + 2*stddev(bytes_change) from TRAFFIC_SURGES)
order by bytes_change desc
limit 10;

모든 면에서, SingleStore는 선형 스케일 성능 측면에서 매력적인 옵션을 제공 할뿐만 아니라 SQL을 사용하여 정교한 쿼리를 쉽게 실행할 수있는 기능도 제공합니다.

​

​

GitHub.com에 대한 전체 벤치 마크 세부 사항

스크립트를 포함한 벤치 마크에 대한 자세한 내용은 https://github.com/memsql/upsert-benchmark를 방문하십시오.

​

​

August 11, 2016

---

출처: https://www.singlestore.com/blog/new-performance-benchmark-for-live-dashboards-and-fast-updates/

New Performance Upsert Benchmark for Live Dashboards & Fast Updates - SingleStore Blog - MemSQL is Now SingleStore

MemSQL achieves 7.9M upserts per second, 6x faster than Cassandra. Learn more about MemSQL's new performance benchmarks for live dashboards & fast updates.

www.singlestore.com

​

​

​※ www.a-platform.biz | info@a-platform.biz