Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them 글쓰기 힘든 데이터베이스 워크로드는 읽기 힘든 데이터베이스 워크로드보다 명확하게 다른 도전을 가져옵니다.Write-heavy database workloads bring a distinctly different set of challenges than read-heavy ones. 스케일링 글쓰기는 비용이 많이 들 수 있으며, 특히 작업당 지불하고 글쓰기는 글쓰기보다 5배나 비싸다. Locking은 지연을 추가하고 통과량을 줄일 수 있습니다. I/O 병점은 글쓰기 증폭과 충돌 복구를 복잡하게 만들 수 있습니다. 데이터베이스 backpressure can throttle incoming load 데이터베이스 backpressure can throttle the incoming load 비용이 중요하지만 - 많은 경우 - 이것은 우리가 여기서 다루고 싶은 주제가 아닙니다.그러나 팀이 일반적으로 직면하는 성능과 관련된 복잡성에 초점을 맞추고 그 문제를 해결할 수있는 옵션을 논의하십시오. "Real-Time Write Heavy Workload"이란 무엇을 의미하는가? 첫째, 우리는 “실시간 쓰기 힘든” 워크로드를 의미하는 것을 명확히 해 봅니다.We are talking about workloads that: 큰 양의 데이터를 흡수합니다 (예를 들어, 50K OPS 이상) 읽는 것보다 글을 쓰는 것이 더 많다. 엄격한 지연 SLA (예를 들어, 단일 숫자 밀리초 P99 지연) 야생에서, 그들은 온라인 게임에서부터 실시간 증권 거래소에 이르기까지 모든 것에서 발생합니다. 사물인터넷(IoT) 워크로드는 시간 시리즈 데이터의 소규모하지만 빈번한 첨부 기록을 포함하는 경향이 있습니다.여기서 섭취율은 주로 데이터를 수집하는 엔드포인트 수에 의해 결정됩니다.Smart home sensors 또는 산업 모니터링 장비가 지속적으로 데이터 스트림을 처리하고 저장하도록 보내는 것을 생각하십시오. 로깅 및 모니터링 시스템은 또한 빈번한 데이터 섭취를 다루지만 고정된 섭취율이 없습니다.그들은 반드시 단지 첨부되지 않을 수도 있고, 예를 들어 한 엔드포인트가 잘못 행동할 때와 같은 핫스팟에 취약 할 수도 있습니다. 온라인 게임 플랫폼은 게임 상태 변경, 플레이어 행동 및 메시징을 포함한 실시간 사용자 상호 작용을 처리해야합니다.작업 부하는 활동의 갑작스런 상승과 함께 강렬한 경향이 있습니다.그들은 심지어 작은 지연도 게임 경험에 영향을 미칠 수 있기 때문에 매우 지연 민감합니다. 전자 상거래 및 소매 워크로드는 일반적으로 업데이트 중량이며 종종 배치 처리를 포함합니다.이 시스템은 정확한 재고 수준을 유지하고, 고객 리뷰를 처리하고, 주문 상태를 추적하며, 업데이트하기 전에 일반적으로 기존 데이터를 읽어야하는 쇼핑 카트 운영을 관리해야합니다. 이러한 시스템은 인쇄 추적 및 경매 결과를 포함한 복잡한 경매 처리를 처리하며 동시에 클릭 및 변환과 같은 사용자 상호 작용을 모니터링합니다. 실시간 증권 거래 시스템은 고주파 거래 작업, 지속적인 주식 가격 업데이트 및 복잡한 주문 일치 프로세스를 지원해야하며, 모든 것이 절대적인 데이터 일관성과 최소한의 지연 시간을 유지합니다. 다음으로, 글쓰기 성능에 영향을 미치는 주요 건축 및 구성 고려 사항을 살펴보자. 스토리지 엔진 아키텍처 스토리지 엔진 아키텍처의 선택은 데이터베이스의 쓰기 성능에 근본적으로 영향을 미칩니다.Two primary approaches exist: LSM trees and B-Trees. ScyllaDB, Apache Cassandra, HBase 및 Google BigTable와 같은 데이터베이스는 Log-Structured Merge Trees (LSM)를 사용합니다.이 아키텍처는 대량의 글쓰기를 처리하는 데 이상적입니다. 글쓰기가 메모리에 즉시 첨부되므로 매우 빠른 초기 저장 기능을 제공합니다. 메모리의 "memtable"가 채워지면 최근 글쓰기는 정렬된 순서로 디스크로 씻어집니다. 예를 들어, 다음은 ScyllaDB 쓰기 경로가 어떻게 생겼는지입니다: B-tree 구조와 함께, 각 쓰기 작업은 나무의 노드를 찾고 수정해야하며, 이는 순차적 및 무작위 I/O를 포함합니다.데이터 세트가 성장함에 따라 나무는 추가 노드와 재균형을 필요로 할 수 있으며, 이는 성능에 영향을 미칠 수 있습니다.B-trees는 일반적으로 조합 및 임시 쿼리를 포함하는 워크로드에 더 적합합니다. Payload 크기 페이로드 크기는 성능에도 영향을 미칩니다.작은 페이로드와 함께, 패스푸트는 좋지만 CPU 프로세싱은 주된 병아리입니다.페이로드 크기가 증가함에 따라 전체 패스푸트가 낮아지고 디스크 사용도 증가합니다. 궁극적으로, 작은 글꼴은 일반적으로 모든 버퍼에 적합하고 모든 것이 매우 빠르게 처리 될 수 있습니다.이 때문에 높은 전송량을 얻는 것이 쉽습니다.더 큰 유용 부하의 경우, 더 큰 버퍼 또는 여러 버퍼를 할당해야합니다.더 큰 유용 부하, 더 많은 자원 (네트워크 및 디스크)이 그 유용 부하를 제공하는 데 필요합니다. 압축 디스크 사용은 쓰기 힘든 워크로드로 주의해야 할 일입니다.스토리지가 지속적으로 저렴해지고 있지만 여전히 무료는 아닙니다. 압축은 상황을 통제하는 데 도움이 될 수 있으므로 압축 전략을 현명하게 선택하십시오.더 빠른 압축 속도는 쓰기 힘든 워크로드에 중요하지만 사용 가능한 CPU 및 메모리 자원을 고려하십시오. 확실히 봐 주세요 The 압축은 기본적으로 데이터를 더 작은 블록 (또는 조각)으로 분할 한 다음 각 블록을 별도로 압축합니다.이 설정을 조정할 때 더 큰 조각이 읽기에 더 좋으며 작은 조각이 쓰기에 더 좋으며 사용량 크기를 고려하십시오. Compression Chunk 크기 파라미터 동정심 LSM 기반 데이터베이스의 경우, 선택한 압축 전략은 또한 쓰기 성능에 영향을 미칩니다. 압축은 여러 SSTables를 더 적고 조직된 파일로 병합하여 읽기 성능을 최적화하고 디스크 공간을 되찾고 데이터 분열을 줄이고 전체 시스템 효율성을 유지합니다. 압축 전략을 선택할 때, 읽기를 최대한 효율적으로 만드는 낮은 읽기 증폭을 목표로 할 수 있습니다.또는 압축이 너무 공격적이지 않도록 낮은 쓰기 증폭을 목표로 할 수 있습니다.또는 낮은 공간 증폭을 우선 순위에 두고 가능한 한 효율적으로 압축 정화 데이터를 가질 수 있습니다.예를 들어, ScyllaDB는 제공합니다. (그리고 Cassandra는 비슷한 것을 제공합니다): 여러 개의 컴팩트 전략 크기 계층 압축 전략 (STCS) : 시스템이 충분한 크기의 SSTables (기본적으로 4 개)를 가지고있을 때 트리거됩니다. 수준화된 압축 전략(LCS): 시스템은 다양한 수준에 분포된 소형, 고정 크기(기본적으로 160MB) SSTables를 사용합니다. Incremental Compaction Strategy (ICS) : STCS와 동일한 읽기 및 쓰기 증폭 요소를 공유하지만, 2배의 임시 공간 증폭 문제를 해결하여 큰 스테블을 SSTable 런으로 분쇄하여, 이는 더 작은 (1GB 기본적으로)의 정렬된 집합으로 구성됩니다. 타임윈도우 압축 전략 (TWCS): 타임윈도우 데이터를 위해 설계되었습니다. 글쓰기 힘든 워크로드의 경우, 우리는 사용자가 모든 비용으로 균형 잡힌 압축을 피하도록 경고합니다.그 전략은 읽기 힘든 사용 사례를 위해 설계되었습니다.그것을 사용하면 유감스러운 40x 글쓰기 증폭이 발생할 수 있습니다. 배치 ScyllaDB 및 Cassandra와 같은 데이터베이스에서는 배치가 실제로 약간의 함정이 될 수 있습니다 - 특히 글쓰기 힘든 워크로드를 위해. 관계 데이터베이스에 익숙하다면 배치가 많은 양의 글쓰기를 처리하는 좋은 옵션처럼 보일 수 있습니다. 그러나 조심스럽게 수행하지 않으면 실제로 일을 느리게 할 수 있습니다. 다음은 당신이 무거운 글쓰기를 다루고있을 때 배치에 대해 생각하는 방법입니다 : 파티션 키에 따라 배치: 파티션 키에 따라 글을 그룹화하여 배치가 데이터를 소유하는 조정기 노드로 이동합니다.이 방법으로 조정기는 추가 데이터를 위해 다른 노드에 도달 할 필요가 없습니다.그 대신, 단지 자체를 처리하여 불필요한 네트워크 트래픽을 줄입니다. 배치를 작고 타겟팅하십시오 : 파티션에 따라 큰 배치를 더 작은 배치로 분할하면 작업이 효율적입니다. 네트워크를 과부하하는 것을 피하고 각 노드가 소유한 데이터에만 작동하도록합니다.당신은 여전히 배치의 이점을 얻을 수 있습니다. 로그인되지 않은 배치에 붙어 : 이전 포인트를 따르고 있기 때문에 로그인되지 않은 배치를 사용하는 것이 가장 좋습니다.Logged batches add extra consistency checks, which can really slow down the writing. 그래서, 당신이 쓰기 어려운 상황에 있다면, 큰 크로스 노드 배치가 가져올 수있는 지연을 피하기 위해 배치를 조심스럽게 구성하십시오. 포장하기 Up 우리는 몇 가지 경고를 제안했지만 걱정하지 마십시오.많은 팀이 실시간 쓰기 힘든 워크로드로 매우 성공적으로 작업하기 때문에 배운 수업 목록을 작성하는 것이 쉽습니다. 더 많은 것을 배우고 싶다면, 꽤 흥미로운 글쓰기 어려운 도전에 대처한 팀의 첫 손의 관점이 있습니다. Zillow: 여러 데이터 제조업체의 레코드를 소비하여 잘못된 업데이트를 초래할 수 있는 오류가 발생했습니다. Tractian: IoT 장치에서 쓰는 고주파 데이터의 10배 성장에 대한 준비 Fanatics : 주문 처리, 쇼핑 카트 및이 온라인 스포츠 소매 업체에 대한 제품 업데이트와 같은 무거운 쓰기 작업 Zillow 트래픽 팬티스트 또한 다음 비디오를 살펴보십시오.이 글쓰기 어려운 도전에 더 깊이 들어가고 ScyllaDB에서 이러한 워크로드가 어떻게 생겼는지 살펴보십시오.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Real-Time Write Heavy Database Workloads : 고려 사항 및 팁

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

독특한 생태계를 강화하는 비트코인 UTXO 모델

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

독특한 생태계를 강화하는 비트코인 UTXO 모델

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps