Cache vs. Database: So sánh Memcached và ScyllaDB

An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB muốn công khai công nhận dormando (Memcachediner) và Danny Kopping cho những đóng góp của họ cho dự án này, cũng như cảm ơn họ cho sự hỗ trợ và kiên nhẫn của họ. Ngủ Tác giả Danny Kopping Các kỹ sư đằng sau ScyllaDB - cơ sở dữ liệu cho hiệu suất dự đoán ở quy mô lớn - đã hợp tác với Memcached maintenance dormando để so sánh cả hai công nghệ trực tiếp, theo cách hợp tác trung lập với nhà cung cấp. Kết quả cho thấy rằng: Cả Memcached và ScyllaDB đều tối đa hóa ổ đĩa và băng thông mạng trong khi được nhấn mạnh trong điều kiện tương tự, duy trì hiệu suất tương tự nói chung. Trong khi ScyllaDB yêu cầu thay đổi mô hình dữ liệu để bão hòa đầy đủ dung lượng mạng, Memcached yêu cầu các chủ đề IO bổ sung để bão hòa đĩa I/O. Mặc dù ScyllaDB cho thấy độ trễ tốt hơn khi so sánh với Memcached yêu cầu đường ống để đĩa, độ trễ Memcached là tốt hơn cho yêu cầu cá nhân. Tài liệu này giải thích động lực của chúng tôi cho các thử nghiệm này, cung cấp tóm tắt các kịch bản và kết quả được thử nghiệm, sau đó trình bày các khuyến nghị cho bất cứ ai có thể quyết định giữa ScyllaDB và Memcached. Cũng có với một cái nhìn rộng rãi hơn về các bài kiểm tra và kết quả và liên kết đến các cấu hình cụ thể mà bạn có thể sử dụng để tự thực hiện các bài kiểm tra. một Gitbook chi tiết cho dự án này, Tiền thưởng: dormando và tôi gần đây đã thảo luận về dự án này tại P99 CONF, một hội nghị kỹ thuật cao về hiệu suất và kỹ thuật độ trễ thấp. Xem theo yêu cầu Tiền thưởng: dormando và tôi gần đây đã thảo luận về dự án này tại P99 CONF, một hội nghị kỹ thuật cao về hiệu suất và kỹ thuật độ trễ thấp. Watch on demand Xem theo yêu cầu Tại sao chúng ta đã làm điều này? Trước hết, ScyllaDB đã đầu tư rất nhiều thời gian và tài nguyên kỹ thuật để tối ưu hóa cơ sở dữ liệu của chúng tôi để cung cấp độ trễ thấp có thể dự đoán được cho các ứng dụng dữ liệu theo thời gian thực. Không có kiến trúc chia sẻ, và (hoàn toàn bỏ bộ nhớ cache trang Linux) là một số ví dụ đáng chú ý về các tối ưu hóa như vậy. Thảo luận:shard-per-core UserPace I/O lịch trình Ứng dụng Cache Internal Thứ hai: hiệu suất hội tụ theo thời gian. bộ nhớ cache đã được (trong một thời gian dài) được coi là một trong những thành phần cơ sở hạ tầng nhanh nhất. Tuy nhiên, đã có một vài năm kể từ khi các giải pháp bộ nhớ cache bắt đầu nhìn vào lĩnh vực ổ đĩa flash. If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? Thứ ba: Chúng tôi đã thảo luận trước đó và gần đây đã khám phá cách các nhóm cụ thể đã thành công . 7 lý do không nên cache trước cơ sở dữ liệu của bạn Thay thế bộ đệm của họ bằng ScyllaDB Thứ tư: Tại P99 CONF năm ngoái, Danny Kopping đã cho chúng tôi một bài phát biểu làm sáng tỏ, , nơi ông giải thích làm thế nào Memcached Extstore đã giúp Grafana Labs mở rộng dấu chân bộ nhớ cache của họ 42x trong khi giảm chi phí. Ẩn tôi nếu bạn có thể Và cuối cùng, bất chấp những lời chỉ trích (có giá trị) mà các chỉ số hiệu suất nhận được, chúng vẫn đóng một vai trò quan trọng trong việc thúc đẩy sự đổi mới. Bây giờ đến sự so sánh. Thiết lập Tòa án Các thử nghiệm được thực hiện bằng cách sử dụng các loại phiên bản AWS sau: Loader: c7i.16xlarge (64 vCPUs, 128GB RAM) Memcached: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) Tất cả các trường hợp có thể cung cấp 25Gbps băng thông mạng. Hãy nhớ rằng đặc biệt là trong các thử nghiệm tối đa hóa khả năng mạng được hứa hẹn, chúng tôi nhận thấy . Tăng lên throttling thu hẹp băng thông xuống đến khả năng cơ bản của các trường hợp Tối ưu hóa và Settings Để vượt qua những rào cản tiềm năng, các tối ưu hóa và cài đặt sau đây đã được áp dụng: Bên AWS: Tất cả các phiên bản sử dụng một chiến lược vị trí cụm, theo AWS Docs: “Chiến lược này cho phép tải công việc để đạt được hiệu suất mạng chậm trễ thấp cần thiết cho giao tiếp node-to-node được kết nối chặt chẽ, đó là điển hình của các ứng dụng máy tính hiệu suất cao (HPC).” Memcached: Phiên bản 1.6.25, được biên soạn với Extstore kích hoạt. Ngoại trừ nơi được chỉ định, chạy với 14 chủ đề, gắn với CPU cụ thể. 2 vCPU còn lại được gán cho CPU 0 (cốt lõi & HT sibling) để xử lý IRQ mạng, như được chỉ định bởi chế độ sq_split trong seastar perftune.py. Các hoạt động CAS đã bị vô hiệu hóa để tiết kiệm không gian trên mỗi mục trên đầu trang. Các đối số dòng lệnh đầy đủ là: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: Cài đặt mặc định được cấu hình bởi ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) trong i4i.4xlarge. Stressor Đối với các loa Memcached, chúng tôi đã sử dụng , một phần của bộ thử nghiệm chính thức của memcached. Các hồ sơ nhấn mạnh áp dụng là trong Lưu trữ GitHub McShredder Trang chủ / Shredders Đối với ScyllaDB, chúng tôi đã sử dụng , như được vận chuyển với ScyllaDB, và xác định khối lượng công việc tương tự như được sử dụng cho Memcached. Cassandra stress Thử nghiệm và kết quả Dưới đây là tóm tắt các bài kiểm tra chúng tôi đã thực hiện và kết quả của chúng.Nếu bạn muốn mô tả và phân tích chi tiết hơn, hãy vào . Bài viết mở rộng của dự án này RAM Caching hiệu quả Càng nhiều mục bạn có thể phù hợp với RAM, cơ hội của bạn càng tốt để có được các hit bộ nhớ cache.Hơn các hit bộ nhớ cache dẫn đến truy cập nhanh hơn đáng kể so với việc truy cập vào đĩa. Dự án này bắt đầu bằng cách đo số lượng các mục chúng tôi có thể lưu trữ cho mỗi kho dữ liệu. Trong suốt quá trình thử nghiệm của chúng tôi, khóa là từ 4 đến 12 byte (key0 .. keyN) cho Memcached, và 12 byte cho ScyllaDB. Giá trị được cố định là 1000 byte. Mênh Memcached lưu trữ khoảng 101M mục cho đến khi việc trục xuất bắt đầu. Nó có hiệu quả bộ nhớ. Từ bộ nhớ được gán 114G của Memcached, đây là giá trị khoảng 101G, không tính đến kích thước khóa và các cờ khác: ScyllaDB ScyllaDB lưu trữ từ 60 đến 61M mục trước khi xóa bỏ bắt đầu. điều này không có gì đáng ngạc nhiên, vì giao thức của nó đòi hỏi nhiều dữ liệu hơn để được lưu trữ như một phần của một viết (chẳng hạn như thời gian viết kể từ thời đại, tuổi thọ hàng, vv). ScyllaDB cũng giữ dữ liệu vào đĩa khi bạn đi, có nghĩa là Bloom Filters (và tùy chọn chỉ mục) cần được lưu trữ trong bộ nhớ cho tìm kiếm đĩa tiếp theo. Takeaways Memcached lưu trữ khoảng 65% các mục trong bộ nhớ hơn ScyllaDB. Các hàng ScyllaDB có tiêu đề trên mỗi mục cao hơn để hỗ trợ định hướng cột rộng. Trong ScyllaDB, Bloom Filters, Index Caching, và các thành phần khác cũng được lưu trữ trong bộ nhớ để hỗ trợ tìm kiếm đĩa hiệu quả, góp phần vào một lớp khác của overhead. Chỉ đọc In-Memory Workload Các (Mặc dù không thực tế) khối lượng công việc cho bộ nhớ cache là một trong đó tất cả dữ liệu phù hợp với bộ nhớ RAM - vì vậy đọc không yêu cầu truy cập đĩa và không có việc xóa hoặc bỏ xảy ra. Cả ScyllaDB và Memcached đều sử dụng logic LRU (Last Recently Used) để giải phóng bộ nhớ: Khi hệ thống chạy dưới áp lực, các mục bị xóa khỏi đuôi của LRU; đây thường là các mục ít hoạt động nhất. lý tưởng Việc loại bỏ các loại bỏ và bỏ lỡ bộ nhớ cache ra khỏi hình ảnh giúp đo lường và thiết lập một đường cơ sở hiệu suất cho cả hai kho dữ liệu. Nó đặt trọng tâm vào những gì quan trọng nhất đối với các loại tải công việc này: đọc thông lượng và yêu cầu độ trễ. Trong thử nghiệm này, chúng tôi lần đầu tiên làm nóng cả hai cửa hàng với cùng một kích thước tải trọng có thể sử dụng trong thử nghiệm trước đó. Memcached Memcached đạt được 3 triệu Gets mỗi giây ấn tượng, tối đa hóa băng thông AWS NIC (25 Gbps)! Memcached duy trì tốc độ 3M rps ổn định, tối đa hóa toàn bộ thông lượng NIC Các Parsed hiển thị rằng p99.999 trả lời hoàn thành dưới 1ms: Kết quả Đang xem mục cmd_get: Tổng số Ops: 5503513496 Tốc độ: 3060908/s === Thời gian mg === 1 - 10 0 0 000% 10-99us 343504394 6.238% 100-999us 5163057634 93.762% 1-2ms 11500 0.00021% ScyllaDB Để đọc nhiều hàng hơn trong ScyllaDB, chúng tôi cần phải thiết kế một mô hình dữ liệu tốt hơn cho các yêu cầu của khách hàng do các đặc điểm của giao thức (đặc biệt là không có đường ống). Với một phím nhóm, chúng tôi có thể tối đa hóa đầy đủ bộ nhớ cache của ScyllaDB, dẫn đến một sự cải thiện đáng kể về số lượng hàng được lưu trữ trong bộ nhớ cache. Kết quả là, số lượng bản ghi trong bộ nhớ cache được cải thiện đáng kể so với các số giá trị khóa được hiển thị trước đó. Như dormando đã chỉ ra một cách chính xác (cảm ơn!), cấu hình này khác biệt đáng kể so với thiết lập Memcached trước đó.Trong khi khối lượng công việc Memcached luôn luôn đạt được một cặp giá trị khóa riêng lẻ, một yêu cầu duy nhất trong ScyllaDB dẫn đến nhiều hàng được trả về.Đáng chú ý, cùng một kết quả có thể đạt được bằng cách sử dụng Memcached bằng cách cung cấp toàn bộ khối lượng sử dụng dưới dạng giá trị dưới một phím duy nhất, với kết quả được quy mô theo đó. Chúng tôi đã giải thích lý do cho những thay đổi này Ở đó, chúng tôi đã bao gồm các tính năng của giao thức CQL (chẳng hạn như overhead mỗi mục [so sánh với memcached] và không hỗ trợ cho pipelining) mà làm cho phân vùng rộng hiệu quả hơn trên ScyllaDB so với thu thập khóa đơn. Trong bài viết chi tiết Với những điều chỉnh này, bộ sạc của chúng tôi đã chạy tổng cộng 187K lần đọc / giây trong 30 phút. mỗi hoạt động dẫn đến 16 hàng được thu thập. Tương tự như memcached, ScyllaDB cũng tối đa hóa thông lượng NIC. Nó phục vụ khoảng 3M hàng / giây chỉ từ dữ liệu trong bộ nhớ: ScyllaDB tiết lộ thông tin độ trễ phía máy chủ, hữu ích cho việc phân tích độ trễ mà không cần mạng.Trong quá trình thử nghiệm, độ trễ server-side p99 của ScyllaDB vẫn nằm trong phạm vi 1ms: Không có gì ngạc nhiên khi các percentile phía khách hàng cao hơn so với độ trễ phía máy chủ với một đọc P99 của 0,9ms. Takeaways Cả Memcached và ScyllaDB đều bão hòa hoàn toàn mạng; để ngăn ngừa bão hòa các gói mạng tối đa mỗi giây, Memcached dựa vào đường ống dẫn yêu cầu trong khi ScyllaDB được chuyển sang định hướng cột rộng. Bộ nhớ cache của ScyllaDB cho thấy sự tăng trưởng đáng kể sau một sơ đồ cột rộng, có thể lưu trữ nhiều mục hơn so với định hướng giá trị phím đơn giản trước đó. Ở cấp độ giao thức, giao thức của Memcached đơn giản hơn và nhẹ hơn, trong khi CQL của ScyllaDB cung cấp các tính năng phong phú hơn nhưng có thể nặng hơn. Thêm đĩa vào hình ảnh Đo hiệu suất lưu trữ flash giới thiệu một tập hợp các thách thức riêng của nó, làm cho nó gần như không thể mô tả đầy đủ một khối lượng công việc nhất định một cách thực tế. Đối với các thử nghiệm liên quan đến đĩa, chúng tôi quyết định đo lường tình huống bi quan nhất: So sánh cả hai giải pháp phục vụ dữ liệu (chủ yếu) từ lưu trữ khối, biết rằng: Khả năng tải công việc thực tế làm điều này là ở đâu đó gần với không Người dùng nên mong đợi số giữa khối lượng công việc bộ nhớ cache lạc quan trước đó và khối lượng công việc gắn đĩa bi quan trong thực tế Memcached Extstore Các cung cấp chi tiết rộng rãi cho các hoạt động bên trong của giải pháp. ở cấp độ cao, nó cho phép memcached giữ bảng hash và các phím trong bộ nhớ, nhưng lưu trữ các giá trị trên lưu trữ bên ngoài. Trang chủ Wiki Trong quá trình thử nghiệm của chúng tôi, chúng tôi đã tích lũy memcached với các mục 1.25B với kích thước giá trị 1KB và kích thước phím lên đến 14 byte: Với Extstore, chúng tôi đã lưu trữ khoảng 11X số lượng mục so với khối lượng công việc trong bộ nhớ trước đó cho đến khi việc xóa bỏ bắt đầu bắt đầu xuất hiện (như được hiển thị trong bảng điều khiển bên phải trong hình trên).Mặc dù 11X là một con số ấn tượng, tổng số dữ liệu được lưu trữ trên flash chỉ là 1,25TB trong tổng số 3,5TB được cung cấp bởi phiên bản AWS. Read-Only Performance Đối với các bài kiểm tra hiệu suất thực tế, chúng tôi nhấn mạnh Extstore so với kích thước mục 1KB và 8KB. Bảng dưới đây tóm tắt kết quả: 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 Đánh giá_metaget_pipe 16 1kb 64 261K / giây 5 - 6 ms Thảo luận_metaget 1 1kb 64 256K / giây 1 - 2ms Đánh giá_metaget_pipe 16 8kb 16 92K / giây 5 - 6 ms Thảo luận_metaget 1 8kb 16 90k / giây > 1ms Đánh giá_metaget_pipe 16 8kb 32 110k / giây 3 - 4 ms Thảo luận_metaget 1 8kb 32 105K / giây > 1ms ScyllaDB Chúng tôi tích lũy ScyllaDB với cùng một số mục được sử dụng cho memcached.Mặc dù ScyllaDB cho thấy tỷ lệ GET cao hơn so với memcached, nó đã làm như vậy dưới độ trễ đuôi cao hơn một chút so với khối lượng công việc không dẫn đường của 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 Đọc 1 1kb 268.8K / giây 2ms 2.4 Mã 8KB Đọc 1 8kb 156.8K / giây 1.45ms 1.9ms Takeaways Extstore yêu cầu điều chỉnh đáng kể các thiết lập của nó để bão hòa đầy đủ flash lưu trữ I / O. Do kiến trúc Memcached, tải trọng nhỏ hơn không thể sử dụng đầy đủ không gian đĩa sẵn có, cung cấp lợi nhuận nhỏ hơn so với ScyllaDB. Tỷ lệ ScyllaDB nói chung cao hơn Memcached trong định hướng giá trị chính, đặc biệt là dưới kích thước tải trọng có thể sử dụng cao hơn. Overwriting công việc Sau kết quả Disk trước đây của chúng tôi, chúng tôi sau đó so sánh cả hai giải pháp trong một khối lượng công việc đọc chủ yếu nhắm mục tiêu cùng một lượng thông lượng (250K ops/sec). , với 10% ngẫu nhiên overwrites. Nó được coi là một "kịch bản tồi tệ nhất.". Thử nghiệm cơ bản cho Extstore Memcached Memcached đạt được tỷ lệ dưới 249K trong quá trình thử nghiệm.Mặc dù tỷ lệ viết vẫn ổn định trong suốt thời gian thử nghiệm, chúng tôi quan sát thấy rằng đọc dao động nhẹ : Trong suốt cuộc chạy Chúng tôi cũng quan sát một chút cao Mặc dù tỷ lệ đọc giảm, nhưng độ trễ vẫn thấp. những kết quả này được tóm tắt dưới đây: Đang xem mục từ: extstore_io_queue Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s 1ms ScyllaDB Thử nghiệm ScyllaDB được chạy bằng 2 bộ tải, mỗi bộ có một nửa tốc độ mục tiêu.Mặc dù ScyllaDB đạt được công suất cao hơn một chút (259.5K), độ trễ viết được giữ thấp trong suốt chạy và độ trễ đọc cao hơn (tương tự như với memcached): Bảng dưới đây tóm tắt kết quả chạy client-side trên hai bộ tải: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms Loader1 124.9K / giây 1.4 Mã 2.6 Mã Loader2 124.6K / giây 1.3 Mã 2.6 Mã Takeaways Cả Memcached và ScyllaDB đều có tỷ lệ viết ổn định, với tỷ lệ đọc hơi dao động trong suốt quá trình chạy. ScyllaDB vẫn viết tài khoản cho commitlog overhead, nằm trong con đường viết nóng Sự chậm trễ ở phía máy chủ của ScyllaDB tương tự như những gì được quan sát thấy trong kết quả Memcached, mặc dù độ trễ ở phía khách hàng cao hơn một chút. Đọc một phân tích chi tiết hơn trong Gitbook cho dự án này Wrapping lên Cả memcached và ScyllaDB đều quản lý để tối đa hóa việc sử dụng phần cứng cơ bản trên tất cả các thử nghiệm và giữ độ trễ thấp có thể dự đoán được. Nếu khối lượng công việc hiện có của bạn có thể chứa một mô hình giá trị khóa đơn giản và nó được hưởng lợi từ đường ống, thì memcached nên phù hợp hơn với nhu cầu của bạn. Mặt khác, nếu khối lượng công việc đòi hỏi hỗ trợ cho các mô hình dữ liệu phức tạp, thì ScyllaDB có thể phù hợp hơn. Một lý do khác để gắn bó với Memcached: nó dễ dàng cung cấp lưu lượng truy cập vượt xa những gì một NIC có thể duy trì. , dormando đã đề cập rằng ông có thể mở rộng nó lên hơn 55 triệu lần đọc / giây cho một máy chủ lớn hơn đáng kể. do đó, bạn có thể sử dụng các loại trường hợp nhỏ hơn và / hoặc rẻ hơn để duy trì một khối lượng công việc tương tự, miễn là bộ nhớ và dấu chân đĩa có sẵn đủ cho nhu cầu khối lượng công việc của bạn. Tin tức Hacker Thread Một góc độ khác để xem xét là kích thước tập dữ liệu. Mặc dù Extstore cung cấp tiết kiệm chi phí lớn bằng cách cho phép bạn lưu trữ các mục ngoài RAM, có một giới hạn về số lượng phím có thể phù hợp cho mỗi GB bộ nhớ. tải công việc với các mục rất nhỏ nên quan sát được lợi nhuận nhỏ hơn so với những mục lớn hơn. Nếu có, thì chạy ScyllaDB như một bộ nhớ cache phân tán được sao chép cung cấp cho bạn khả năng phục hồi lớn hơn và hoạt động không ngừng, với sự thỏa hiệp là (và như ) rằng sao chép làm giảm một nửa kích thước bộ nhớ cache hiệu quả của bạn. Thật không may, Extstore không hỗ trợ khởi động lại nóng và do đó sự thất bại hoặc bảo trì của một nút duy nhất có xu hướng làm tăng tỷ lệ thiếu bộ nhớ cache của bạn. Cho dù điều này có thể chấp nhận được hay không phụ thuộc vào ngữ nghĩa ứng dụng của bạn: Nếu thiếu bộ nhớ cache tương ứng với một chuyến đi vòng đến cơ sở dữ liệu, thì độ trễ từ đầu đến cuối sẽ cao hơn trong một thời gian. Memcached chính xác states Đối với hashing nhất quán, các khách hàng memcached chịu trách nhiệm phân phối các phím trên các máy chủ phân tán của bạn. Điều này có thể giới thiệu một số hiccups, vì các cấu hình khách hàng khác nhau sẽ gây ra các phím được gán khác nhau, và một số triển khai có thể không tương thích với nhau. ScyllaDB có một cách tiếp cận khác: hashing nhất quán được thực hiện ở cấp độ máy chủ và truyền đến các khách hàng khi kết nối được thiết lập lần đầu tiên. ConfiguringClient wiki của Memcached Vì vậy, ai giành chiến thắng (hoặc ai thua)? Vâng... Đây không phải là một cuộc thi, cũng không phải là một danh sách toàn diện mô tả mọi cân nhắc cho mỗi giải pháp. Cả ScyllaDB và memcached đều sử dụng các cách tiếp cận khác nhau để sử dụng hiệu quả cơ sở hạ tầng cơ bản. Chúng tôi rất vui khi thấy ScyllaDB phù hợp với số lượng của Memcached được công nhận trong ngành. Tất nhiên, chúng tôi không mong đợi cơ sở dữ liệu của chúng tôi sẽ nhanh hơn. trên thực tế, khi chúng tôi tiếp cận độ trễ microsecond ở quy mô lớn, định nghĩa của nhanh hơn trở nên khá chủ quan. 🙂