An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB는 dormando (Memcachediner)와 Danny Kopping가이 프로젝트에 기여한 것에 대해 공개적으로 감사하고 있으며, 지원과 인내심에 감사드립니다. 잠자기 댄스 코핑 ScyllaDB - 규모에서 예측 가능한 성능을위한 데이터베이스 - 뒤에있는 엔지니어들은 Memcached 유지 관리자 dormando와 협력하여 공급자 중립적인 방식으로 두 기술을 서로 비교했습니다. 결과는 그것을 보여줍니다 : Memcached와 ScyllaDB는 모두 디스크와 네트워크 대역폭을 최대화하면서 비슷한 조건에서 스트레스를 받았으며 전반적으로 유사한 성능을 유지했습니다. ScyllaDB는 네트워크 통과량을 완전히 포화시키기 위해 데이터 모델링 변경이 필요했지만 Memcached는 디스크 I/O를 포화시키기 위해 추가 IO 스레드를 필요로했습니다. ScyllaDB는 Memcached 파이프라인 요청과 비교할 때 더 나은 지연 시간을 보여주었지만 Memcached 지연 시간은 개별 요청에 더 좋았습니다. 이 문서는 이러한 테스트에 대한 우리의 동기를 설명하고, 테스트 된 시나리오와 결과에 대한 요약을 제공하고, ScyllaDB와 Memcached 사이에 결정을 내릴 수있는 모든 사람들에게 권장 사항을 제시합니다. 거기 또한 테스트와 결과를 더 자세히 살펴보고 테스트를 직접 수행하는 데 사용할 수 있는 특정 구성에 대한 링크를 제공합니다. 이 프로젝트에 대한 자세한 Gitbook, 보너스: dormando와 나는 최근 P99 CONF에서이 프로젝트를 논의했는데, 이는 성능과 낮은 지연 엔지니어링에 관한 매우 기술적인 컨퍼런스입니다. 수요를 지켜보라 보너스: dormando와 나는 최근 P99 CONF에서이 프로젝트를 논의했는데, 이는 성능과 낮은 지연 엔지니어링에 관한 매우 기술적인 컨퍼런스입니다. Watch on demand 수요를 지켜보라 왜 우리는 이것을 했습니까? 우선, ScyllaDB는 데이터베이스를 최적화하여 실시간 데이터 집중적 인 응용 프로그램에 예측 가능한 낮은 지연 시간을 제공하기 위해 많은 시간과 엔지니어링 자원을 투자했습니다. 아무것도 공유하지 않는 건축물, 그리고 (Linux 페이지 캐시를 완전히 우회) 이러한 최적화의 몇 가지 눈에 띄는 예입니다. 샤드-페어-코어 UserSpace I/O 스케줄러 내부 Cache 구현 둘째, 성능은 시간이 지남에 따라 합쳐집니다.In-memory 캐시는 (오랫동안) 가장 빠른 인프라 구성 요소 중 하나로 간주되었습니다.그러나, 캐시 솔루션이 플래시 디스크의 영역을 살펴보기 시작한 지 몇 년이 지났습니다.이 이니셔티브는 분명히 흥미로운 질문을 제기합니다. If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? 셋째, 우리는 이전에 논의한 그리고 최근 특정 팀이 어떻게 성공적으로 성공했는지 탐구했습니다. . 데이터베이스 앞에 캐시를 두지 않는 7가지 이유 Cache를 ScyllaDB로 교체했습니다. 넷째, 작년 P99 CONF에서 Danny Kopping는 우리에게 빛나는 연설을했습니다. 그는 Memcached Extstore가 Grafana Labs가 비용을 낮추면서 캐시 발자국을 42배 확장하는 데 어떻게 도움을 주었는지 설명했습니다. 할 수 있다면 숨겨주세요 그리고 마지막으로, 성능 벤치마크가 받는 (정당한) 비판에도 불구하고, 그들은 여전히 혁신을 추진하는 데 중요한 역할을합니다.Benchmarks는 내부 최적화 기회를 찾는 엔지니어들에게 유용한 자원입니다. 이제 비교에 가보자. 설치 법원 테스트는 다음과 같은 AWS 인스턴스 유형을 사용하여 수행되었습니다: 로더: c7i.16xlarge (64 vCPU, 128GB RAM) Memcached: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) 모든 사례는 배달할 수 있습니다 25Gbps 네트워크 대역폭.특히 약속된 네트워크 용량을 극대화하는 테스트 중에, 우리는 주목했습니다. . 위로 throttling은 대역폭을 인스턴스의 기본 라인 용량으로 줄이는 최적화 및 Settings 잠재적 인 bottlenecks를 극복하기 위해 다음 최적화 및 설정이 적용되었습니다 : AWS 측면: 모든 인스턴스는 AWS Docs에 따라 클러스터 배치 전략을 사용했습니다:“이 전략은 워크로드가 고성능 컴퓨팅 (HPC) 응용 프로그램에 전형적인 긴밀하게 연결된 노드-노드 통신에 필요한 낮은 지연 네트워크 성능을 달성할 수 있습니다.” Memcached: 버전 1.6.25, Extstore 활성화와 함께 컴파일. 지정된 경우를 제외하고, 14 개의 스레드와 함께 실행, 특정 CPU에 연결. 나머지 2 vCPU는 CPU 0 (코어 & HT 형제)에 배정되어 seastar perftune.py의 sq_split 모드에 의해 지정된 방식으로 네트워크 IRQ를 처리했습니다. CAS 작업은 각 항목에 대한 공간을 절약하기 위해 비활성화되었습니다. 전체 명령 라인 인수는 :taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB: i4i.4xlarge에서 ScyllaDB Enterprise 2024.1.2 AMI(ami-id: ami-018335b47ba6bdf9a)에 의해 구성된 기본 설정입니다.This includes the same CPU pinning settings as described above for Memcached. 스트레스 Memcached loader를 위해, 우리는 사용했습니다 , memcached의 공식 테스트 스위트의 일부.The applicable stressing profiles are in the GitHub 리포토리 마크스레드 페이 멘데스 / Shredders ScyllaDB, 우리는 사용 , ScyllaDB와 함께 배송되었으며, Memcached에 사용된 것과 비교할 수 있는 워크로드를 지정했습니다. 카지노사이트 스트레스 테스트 및 결과 다음은 우리가 수행 한 테스트와 그 결과의 요약입니다.더 자세한 설명과 분석을 원하시는 경우 . 이 프로젝트의 확장된 글쓰기 RAM Caching 효율성 RAM에 더 많은 항목을 넣을 수있을수록 캐시 히트를 얻을 수있는 기회가 높아집니다.더 많은 캐시 히트는 디스크에가는 것보다 훨씬 빠른 액세스 결과입니다. 이 프로젝트는 각 데이터 스토어에 얼마나 많은 항목을 저장할 수 있는지 측정함으로써 시작되었습니다.우리의 테스트 동안 키는 Memcached의 경우 4 ~ 12 바이트 (key0 .. keyN)와 ScyllaDB의 경우 12 바이트 사이였습니다.이 값은 1000 바이트로 고정되었습니다. 메모리 Memcached는 추방이 시작될 때까지 대략 101M 항목을 저장했습니다. 메모리 효율적입니다. Memcached의 114G 할당 메모리에서 이것은 키 크기 및 기타 깃발을 고려하지 않고 약 101G 가치입니다. ScyllaDB ScyllaDB는 배출이 시작되기 전에 60 ~ 61M 항목 사이에 저장되었습니다. 이것은 놀라운 일이 아닙니다.이 프로토콜은 쓰기의 일환으로 저장되기 위해 더 많은 데이터를 필요로합니다 (예를 들어, 시대 이후의 쓰기 타임스탬프, 행 라이브 등).ScyllaDB는 또한 블룸 필터 (및 선택적으로 인덱스)가 후속 디스크 검색을 위해 메모리에 저장되어야한다는 것을 의미합니다. Takeaways Memcached는 ScyllaDB보다 65% 더 많은 메모리 항목을 저장했습니다. ScyllaDB 행은 넓은 열 방향을 지원하기 위해 항목 당 더 높은 오버 헤드가 있습니다.ScyllaDB rows have higher per-item overhead to support a wide column orientation. ScyllaDB에서 블룸 필터, 인덱스 캐시 및 기타 구성 요소는 또한 효율적인 디스크 검색을 지원하기 위해 메모리에 저장되어 또 다른 계층의 오버헤드에 기여합니다. 읽기 전용 In-Memory Workload 이 (비록 비현실적인) 캐시의 워크로드는 모든 데이터가 RAM에 적합하므로 읽기가 디스크 액세스를 필요로하지 않으며 배출 또는 실패가 발생하지 않습니다.ScyllaDB와 Memcached 모두 LRU (Last Recently Used) 논리를 사용하여 메모리를 해제합니다 : 시스템이 압력하에 실행될 때 항목은 LRU의 꼬리에서 배출됩니다. 이상적인 사진에서 추방 및 캐시 실패를 제거하면 두 데이터 스토어의 성능 기준을 측정하고 설정할 수 있습니다.It places the focus on what matters most for these types of workloads: read throughput and request latency. 이 테스트에서 우리는 먼저 이전 테스트에서 사용한 동일한 유용량 크기로 두 가게를 따뜻하게 만들었습니다.그리고 30 분 동안 각각의 범위에 대한 읽기를 시작했습니다. Memcached Memcached는 인상적인 초당 3 백만 개의 Gets를 달성하여 AWS NIC 대역폭 (25Gbps)을 최대화했습니다! Memcached는 안정적인 3M RPS를 유지하여 NIC 투과량을 완전히 극대화 파르세드 p99.999 응답이 1ms 이하로 완료되었음을 보여줍니다. 결과 사용자 정의: cmd_get 총 옵스: 5503513496 속도: 3060908/s === 시간대 mg === 시간대 0 0 0 0 0 0 0 0 0 0 10-99us 343504394 6.238% 100 - 999US 5163057634 93.762% 1-2ms 11500 0.00021 % ScyllaDB ScyllaDB에서 더 많은 행을 읽으려면 프로토콜 특성 때문에 클라이언트 요청에 대한 더 나은 데이터 모델을 개발해야 했습니다 (특히 파이플링이 없음). 클러스터링 키를 사용하면 ScyllaDB의 캐시를 완전히 극대화하여 캐시된 행 수를 크게 향상시킬 수 있습니다. 결과적으로 캐시 내의 레코드 수는 이전에 표시된 키 값 숫자와 비교하여 상당히 향상되었습니다. dormando가 올바르게 지적했듯이 (감사합니다!), 이 구성은 이전 Memcached 설정과 크게 다릅니다.Memcached 워크로드는 항상 개별 키-값 쌍을 지만, ScyllaDB의 단일 요청은 여러 행을 반환합니다.이와 같은 결과는 Memcached를 사용하여 전체 유용량을 단일 키 아래의 값으로 공급함으로써 달성할 수 있습니다. 우리는 이러한 변화의 이유를 설명했습니다. 거기서 우리는 CQL 프로토콜의 특성을 다루었습니다 (예를 들어, 항목당 오버 헤드 [memcached에 비해] 및 파이플리닝에 대한 지원이 없음) ScyllaDB에서 넓은 파티션을 단일 키 픽치보다 효율적으로 만듭니다. 자세한 글쓰기 속에서 이러한 조정으로, 우리의 로더는 30 분 동안 초당 총 187K 읽기 옵션을 실행했습니다. memcached와 마찬가지로, ScyllaDB는 또한 NIC 통과량을 극대화했습니다.It served approximately 3M rows/sec solely from in-memory data: ScyllaDB는 네트워크 없이 지연을 분석하는 데 유용한 서버 측 지연 정보를 공개합니다.During the test, ScyllaDB’s server-side latency p99 remained within 1ms boundaries: 클라이언트 측의 센티일은 0.9ms의 읽기 P99로 서버 측의 지연보다 놀랍지 않다. Takeaways Memcached와 ScyllaDB 모두 네트워크를 완전히 포화시켰으며, 초당 최대 네트워크 패킷을 포화시키지 않으려면 Memcached는 요청 파이플링을 사용했으며 ScyllaDB는 넓은 열 방향으로 전환했습니다. ScyllaDB의 캐시는 넓은 열 계획에 따라 상당한 이득을 보였으며 이전의 간단한 키 값 방향에 비해 더 많은 항목을 저장할 수있었습니다. 프로토콜 수준에서, Memcached의 프로토콜은 더 간단하고 가볍고, ScyllaDB의 CQL는 더 풍부한 기능을 제공하지만 더 무거운 수 있습니다. 사진에 디스크를 추가하기 플래시 스토리지 성능을 측정하는 것은 그 자체의 도전을 제시하며, 주어진 작업량을 현실적으로 완전히 특징화하는 것은 거의 불가능합니다. 디스크 관련 테스트를 위해 우리는 가장 비관적 인 상황을 측정하기로 결정했습니다 : 블록 저장소에서 (대부분) 데이터를 제공하는 두 솔루션을 비교하십시오. 이 작업을 수행하는 현실적인 워크로드의 확률은 거의 0에 가까운 곳입니다. 사용자는 실제로 이전의 낙관적 인 캐시 워크로드와 비관적 인 디스크 연결 워크로드 사이의 숫자를 기대해야합니다. Memcached Extstore 이 높은 수준에서는 memcached가 해시 테이블과 키를 메모리에 보관할 수 있지만 값을 외부 저장소에 저장할 수 있습니다. 엑스트라 wiki 페이지 테스트 중에, 우리는 1KB의 값 크기와 최대 14 바이트의 키 크기의 1.25B 항목으로 memcached를 채우었습니다. Extstore를 사용하면 이전의 메모리 워크로드에 비해 항목 수가 약 11배나 저장되었으며, 추방이 시작될 때까지(이상 이미지의 오른쪽 패널에서 볼 수 있듯이) 11X는 이미 인상적인 숫자이지만, 플래시에 저장된 총 데이터는 AWS 인스턴스에서 제공하는 총 3.5TB 중 1.25TB에 불과했습니다. Read-Only Performance 실제 성능 테스트를 위해 우리는 1KB 및 8KB의 항목 크기에 대해 Extstore를 강조했습니다. Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms 미리보기_PIPE 16 1KB 32 188 K/S 4 ~ 5 ms 메타데이 - 메타데이 1 1KB 32 182 K/s < 1ms 미리보기_PIPE 16 1KB 64 261 K/s 5 ~ 6 ms 메타데이 - 메타데이 1 1KB 64 256k/s 1 ~ 2ms 미리보기_PIPE 16 8KB 16 92 K/s 5 ~ 6 ms 메타데이 - 메타데이 1 8KB 16 90k/s < 1ms 미리보기_PIPE 16 8KB 32 110k/s 3 ~ 4 ms perfrun_metaget 1 8KB 32 105 K/s < 1ms ScyllaDB 우리는 memcached에 사용 된 것과 동일한 수의 항목으로 ScyllaDB를 인구화했습니다.ScyllaDB는 memcached보다 더 높은 GET 비율을 보여주었지만, memcached의 파이플링이 아닌 워크로드에 비해 약간 높은 꼬리 지연률에 따라 그렇게했습니다.이것은 아래에 요약됩니다: Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1KB 읽기 1 1KB 268.8K / 초 2ms 2.4 MS 8KB 읽기 1 8KB 156.8K / 초 1.54 미터 1.9 MS Takeaways Extstore는 플래시 스토리지 I/O를 완전히 포화하기 위해 설정에 상당한 조정이 필요했습니다. Memcached 아키텍처로 인해, 더 작은 payloads는 사용할 수 있는 디스크 공간을 최대한 활용할 수 없으며, ScyllaDB에 비해 더 작은 이득을 제공합니다. ScyllaDB 비율은 키 값 방향에서 Memcached보다 일반적으로 높았으며, 특히 더 높은 유용량 크기에서 지연률은 파이프라인 요청보다 좋았지만 Memcached의 개별 GET보다 약간 높았습니다. Overwriting 워크로드 이전 디스크 결과를 따르고, 우리는 읽기 대부분의 워크로드의 두 솔루션을 동일한 전송량 (250K ops/sec)을 목표로 비교했습니다. 10 %의 무작위 overwrites와 함께, 그것은 "최악의 시나리오"로 간주됩니다. Extstore에 대한 ‘Basic’ 테스트 Memcached Memcached는 테스트 중에 249K 이하의 속도를 달성했지만, 테스트 기간 동안 쓰기 속도는 안정적으로 유지되었지만, 읽기 속도는 약간 변동했다는 것을 관찰했습니다. : 전체 Run 우리는 또한 약간 높은 것을 관찰했다. 읽기 비율이 낮아졌음에도 불구하고 매개 변수는 여전히 낮았습니다.These results are summarized below: 엑스트라_오오오오오오오오오오 Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms CMD_GET 64 224 K/s 1 ~ 2 ms CMD - 세트 64 4.8 K/s < 1ms ScyllaDB ScyllaDB 테스트는 목표 속도의 절반을 가진 2개의 로더를 사용하여 실행되었지만 ScyllaDB는 약간 더 높은 통과량 (259.5K)을 달성했지만, 글쓰기 지연률은 실행 기간 내내 낮게 유지되었으며 읽기 지연률은 더 높았습니다 (memcached와 마찬가지로). 아래 표는 두 로더 간의 클라이언트 측 실행 결과를 요약합니다.The table below summarizes the client-side run results across the two loaders: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms 로더1 124.9K / 초 1.4 미터 2.6 MS 로더2 124.6K / 초 1.3 MS 2.6 MS Takeaways Memcached와 ScyllaDB 모두 글쓰기 비율이 안정적이었으며, 읽기 비율은 실행 중에 약간 변동되었습니다. ScyllaDB는 여전히 뜨거운 쓰기 경로에 앉아있는 commitlog overhead에 대해 설명합니다. ScyllaDB 서버 측 늦은 시간은 Memcached 결과에서 관찰 된 것과 비슷했지만 클라이언트 측 늦은 시간은 약간 더 높았습니다. 이 프로젝트에 대한 Gitbook에서 더 자세한 분석을 읽으십시오. 포장하기 Up memcached와 ScyllaDB 모두 모든 테스트에서 기본적인 하드웨어 사용량을 극대화하고 지연률을 예측할 수있게 낮추는 데 성공했습니다.So which one should you choose? 기존 워크로드가 간단한 키 값 모델을 수용할 수 있고 파이프라인링을 활용할 수 있다면, memcached는 귀하의 요구에 더 적합해야 합니다. Memcached에 붙어있는 또 다른 이유는 NIC가 유지할 수있는 것보다 훨씬 더 많은 트래픽을 쉽게 제공합니다. dormando는 훨씬 더 큰 서버를 위해 5천5백만 개의 읽기 옵션/초 이상으로 확장할 수 있다고 언급했습니다.당신은 사용할 수 있는 메모리와 디스크 발자국이 당신의 작업량 요구에 충분할 때 비슷한 워크로드를 유지하기 위해 더 작고/또는 더 저렴한 인스턴스 타입을 사용할 수 있습니다. 이 해커 뉴스 트레일 고려해야 할 다른 각도는 데이터 세트 크기입니다.Extstore는 RAM 이외의 항목을 저장할 수 있도록함으로써 큰 비용 절약을 제공하지만, 메모리 GB 당 몇 개의 키가 적합할 수 있는지에 대한 한계가 있습니다.매우 작은 항목을 가진 워크로드는 더 큰 항목을 가진 것에 비해 더 작은 이득을 관찰해야합니다.그것은 ScyllaDB의 경우가 아닙니다.그것은 크기에 관계없이 수십억 개의 항목을 저장할 수 있습니다. 또한 데이터 내구성이 필요한지 여부를 고려하는 것이 중요합니다.If it is, then running ScyllaDB as a replicated distributed cache provides you greater resilience and non-stop operations, with the tradeoff being (그리고 같은) 이 복제는 효과적인 캐시 크기를 절반으로 줄여줍니다. 불행히도 Extstore는 뜨거운 재시작을 지원하지 않으며, 따라서 단일 노드의 실패 또는 유지 보수는 캐시 미스 비율을 높일 가능성이 있습니다.이 수용 가능한지 여부는 응용 프로그램 정의에 달려 있습니다. 메이커가 올바른 상태를 일관된 해시에 관해서는, memcached 클라이언트는 분산된 서버에 키를 배포하는 책임이 있습니다.This may introduce some hiccups, as different client configurations will cause keys to be assigned differently, and some implementations may not be compatible with each other. ScyllaDB는 다른 접근 방식을 취합니다: 일관된 해시는 서버 수준에서 수행되고 연결이 처음 설정될 때 클라이언트에 전파됩니다.This ensures that all connected clients always observe the same topology as you scale. Memcached's Configuring클라이언트 wiki 그래서 누가 이겼는지 (또는 누가 졌는지)? 잘... 이것은 경쟁이 될 필요가 없으며, 각 솔루션에 대한 각각의 고려 사항을 다루는 완전한 목록도 아닙니다. ScyllaDB와 memcached는 기본 인프라를 효율적으로 활용하기 위해 서로 다른 접근 방식을 사용합니다. 우리는 ScyllaDB가 업계에서 인정받는 Memcached의 숫자와 일치하는 것을 보게되어 기습니다. 당연히, 우리는 우리의 데이터베이스가 "더 빠르다"고 기대하지 않았습니다.
