Một bài kiểm tra toàn diện so sánh các hệ thống cache và cơ sở dữ liệu phổ biến đã gây ra cuộc thảo luận sôi nổi trong cộng đồng nhà phát triển, đặc biệt xung quanh các lựa chọn trực quan hóa dữ liệu và sự khác biệt hiệu suất bất ngờ giữa các công nghệ tương tự.
Thang Đo Logarit Che Giấu Sự Khác Biệt Hiệu Suất Thực Tế
Kết quả kiểm tra, mặc dù có phạm vi toàn diện, đã bị chỉ trích vì sử dụng thang đo logarit trong các biểu đồ hiệu suất. Lựa chọn trực quan hóa này đã khiến người đọc khó nắm bắt được mức độ thực tế của sự khác biệt hiệu suất giữa các hệ thống. Những gì xuất hiện như một lợi thế khiêm tốn trên các biểu đồ logarit thực tế đại diện cho khoảng cách hiệu suất đáng kể - với Memcached hoạt động nhanh hơn Redis lên đến ba lần trong một số tình huống, mặc dù chỉ xuất hiện tốt hơn một chút trong các biểu đồ.
Nhiều thành viên cộng đồng đã kêu gọi dữ liệu được trình bày lại bằng thang đo tuyến tính để cung cấp một bức tranh rõ ràng hơn về sự khác biệt hiệu suất trong thế giới thực. Phản hồi này làm nổi bật tầm quan trọng của việc trực quan hóa dữ liệu phù hợp khi trình bày các bài kiểm tra kỹ thuật cho cộng đồng.
Các Phát Hiện Hiệu Suất Chính:
- Memcached so với Redis : Lợi thế hiệu suất lên đến 3 lần cho Memcached (bị che khuất bởi tỷ lệ logarit)
- Valkey so với Redis : Hiệu suất vượt trội nhất quán nhờ kiến trúc đa luồng
- Garnet : Hiệu suất pipeline đặc biệt xuất sắc mặc dù được triển khai bằng C
- Mở Rộng Luồng: Hiệu suất đạt ngưỡng ổn định khoảng 6-8 luồng trên hầu hết các hệ thống
- Tác Động Pipeline: Cải thiện hiệu suất đáng kể với các giá trị pipeline cao hơn (1, 10, 100, 1000)
Valkey Nổi Lên Như Một Lựa Chọn Thay Thế Mạnh Mẽ Cho Redis
Một trong những phát hiện đáng chú ý nhất từ các bài kiểm tra là hiệu suất vượt trội nhất quán của Valkey so với Redis trong các tình huống thử nghiệm khác nhau. Lợi thế hiệu suất này dường như bắt nguồn từ kiến trúc đa luồng của Valkey , trái ngược với thiết kế đơn luồng của Redis . Kết quả đã tạo ra sự nhiệt tình trong số các nhà phát triển, những người coi điều này như sự xác nhận cho nhánh phát triển cộng đồng xuất hiện sau những thay đổi cấp phép của Redis .
Khoảng cách hiệu suất giữa Valkey và Redis đã làm ngạc nhiên một số người quan sát, những người chỉ mong đợi sự khác biệt nhỏ giữa hai hệ thống. Tuy nhiên, sự kết hợp của việc tăng tài trợ, sự chú ý của nhà phát triển và cải tiến kiến trúc đã cho phép Valkey vượt lên trước người tiền nhiệm trong các bài kiểm tra tiêu chuẩn này.
Các hệ thống được kiểm tra:
- Memcache: Kho dữ liệu key-value trong bộ nhớ (1 triệu key trên /dev/shm)
- Redis: Kho dữ liệu trong bộ nhớ (1 triệu key trên /dev/shm)
- Valkey: Phiên bản fork của Redis với kiến trúc đa luồng
- Garnet: Bộ nhớ cache tương thích Redis của Microsoft viết bằng C
- SQLite: Cơ sở dữ liệu SQL tuân thủ ACID trong tiến trình (1 nghìn key trong /tmp/)
- RocksDB: Kho key-value bền vững của Facebook (1 triệu key trên /dev/shm)
- WiredTiger: Kho key-value bền vững của MongoDB (1 triệu key trên /dev/shm)
 |
|---|
| Kho lưu trữ GitHub cho " Cache Benchmarks ", bao gồm các bài đánh giá hiệu suất công nghệ bộ nhớ đệm khác nhau, trong đó có Valkey và Redis |
Hiệu Suất Pipeline Đặc Biệt Của Garnet
Có lẽ kết quả thú vị nhất đến từ Garnet , cache tương thích Redis của Microsoft được viết bằng C# , thể hiện hiệu suất đặc biệt trong các tình huống pipeline cao. Mặc dù được xây dựng trên một runtime được quản lý thường liên quan đến chi phí hiệu suất, Garnet đạt được những kết quả này thông qua các kỹ thuật tối ưu hóa tích cực tránh thu gom rác và sử dụng bộ nhớ không được quản lý một cách rộng rãi.
Triết lý thiết kế của hệ thống bao gồm việc tránh chiến lược các mẫu C# điển hình như async/await, thay vào đó chuyển các hoạt động I/O trực tiếp lên các luồng yêu cầu mạng. Cách tiếp cận này, mặc dù tạo ra mã C# không theo thành ngữ, chứng minh cách kỹ thuật cẩn thận có thể vượt qua những hạn chế ngôn ngữ được nhận thức.
Đa luồng: Một thiết kế hệ thống có thể xử lý nhiều tác vụ đồng thời trên các luồng xử lý khác nhau, thường cải thiện hiệu suất cho các hoạt động đồng thời.
Thông số kỹ thuật môi trường kiểm thử:
- CPU: 3.1 GHz 12-Core Intel Xeon W (c8g.8xlarge 32-core ARM64 cho một số bài kiểm thử)
- Bộ nhớ: 64 GB 2666 MHz DDR4
- Nền tảng: Linux (chưa kiểm thử trên Apple Silicon)
- Thời gian kiểm thử: 30 giây cho mỗi benchmark
- Số lượng thao tác: Tổng cộng 1.000.000 thao tác với tỷ lệ đọc 50%
Mối Quan Ngại Về Phương Pháp Kiểm Tra
Phản hồi của cộng đồng cũng đã làm nổi bật các vấn đề tiềm ẩn với phương pháp kiểm tra, đặc biệt liên quan đến lựa chọn giao thức và cấu hình hệ thống. Một số chuyên gia lưu ý rằng Memcached được kiểm tra bằng giao thức văn bản cũ hơn thay vì giao thức nhị phân được khuyến nghị, điều này có thể ảnh hưởng đến tính đại diện của kết quả cho các triển khai hiện đại.
Ngoài ra, các câu hỏi nảy sinh về hành vi của nền tảng kiểm tra, với các cao nguyên hiệu suất xảy ra khoảng 6-8 luồng trên hầu hết các hệ thống mặc dù chạy trên bộ xử lý ARM64 32 lõi. Điều này gợi ý các hạn chế kiến trúc hoặc vấn đề cấu hình có thể không phản ánh hiệu suất tối ưu trong thế giới thực.
Bài kiểm tra cung cấp những hiểu biết có giá trị về hiệu suất cache và cơ sở dữ liệu, nhưng phản ứng của cộng đồng nhấn mạnh tầm quan trọng của việc trình bày dữ liệu rõ ràng và phương pháp kiểm tra toàn diện khi đánh giá hiệu suất hệ thống. Khi những công nghệ này tiếp tục phát triển, các bài kiểm tra như vậy phục vụ như những công cụ quan trọng cho các nhà phát triển đưa ra quyết định cơ sở hạ tầng, miễn là kết quả được trình bày và diễn giải một cách chính xác.
Tham khảo: Cache Benchmarks