Ra mắt DiceDB

 (dicedb.io)
5 điểm bởi GN⁺ 2025-03-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • DiceDB là cơ sở dữ liệu in-memory mã nguồn mở, hiệu năng cao và có tính phản hồi cao
  • Chủ yếu được օգտագործ như bộ nhớ đệm và cung cấp cập nhật dữ liệu theo thời gian thực thông qua đăng ký truy vấn (query subscription)
  • Được tối ưu cho phần cứng hiện đại để mang lại thông lượng cao và độ trễ thấp
  • Cung cấp giao diện dễ dùng, quen thuộc và là mã nguồn mở
  • Benchmark hiệu năng
    • Thông lượng và độ trễ GET/SET được so sánh với các cơ sở dữ liệu in-memory khác trên máy Hetzner CCX23 (4 vCPU, 16GB RAM)
    • Thông lượng (ops/sec): DiceDB 15655, Redis 12267
    • GET p50(ms): DiceDB 0.227327, Redis 0.270335
    • GET p90(ms): DiceDB 0.337919, Redis 0.329727
    • SET p50(ms): DiceDB 0.230399, Redis 0.272383
    • SET p90(ms): DiceDB 0.339967, Redis 0.331775

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-03-18
Ý kiến trên Hacker News

  • Có khá nhiều lỗi trong đoạn mã này

    • Ví dụ, hàm ExpandID không khóa mutex toàn cục của package khi đọc từ cycleMap
    • Trong khi đó, hàm NextID có khóa mutex toàn cục của package khi ghi vào cycleMap
    • Các thao tác ghi được đồng bộ với nhau, nhưng không được đồng bộ với thao tác đọc, nên có thể phát sinh race condition khi ExpandID và NextID được gọi đồng thời
    • Làm dự án sở thích thì ổn, nhưng còn xa mới đạt mức hệ thống có thể dùng trong production

  • Tôi có một vài câu hỏi về thiết kế khi xem codebase của DiceDB

    • Tôi muốn hiểu mục tiêu của dự án và logic đằng sau thiết kế này
    • Kho lưu trữ chính trong bộ nhớ có vẻ là một map Go tiêu chuẩn có khóa
    • Tôi tò mò không biết đây là lựa chọn tạm thời để phục vụ phát triển lặp, hay có kế hoạch dài hạn chuyển sang cấu trúc dữ liệu được tối ưu hơn
    • Cơ chế reactive của DiceDB khá thú vị, đặc biệt là việc thực thi lại toàn bộ lệnh theo dõi
    • Hàm Eval có vẻ thực thi lệnh ở phía client, và điều này dường như đang đặt nền móng cho các lệnh theo dõi phức tạp hơn
    • Tôi muốn biết động lực chính đằng sau việc thực thi lại toàn bộ lệnh là gì
    • Việc chạy lại có thể là tác vụ tốn kém về mặt tính toán, nên tôi muốn biết họ xử lý các điểm nghẽn hiệu năng như thế nào
    • Tôi cũng muốn biết cách tiếp cận "thực thi lại" này so với các phương pháp khác ra sao về khả năng mở rộng và tính nhất quán
    • Ngoài GET.WATCH, có kế hoạch hỗ trợ các lệnh theo dõi phức tạp hơn không
    • Tôi tò mò về các trade-off của lựa chọn thiết kế này và liệu nó có phù hợp với mục tiêu của dự án hay không

  • Tôi thắc mắc liệu có câu nào giải thích công nghệ này thực chất là gì hay không

  • Dùng công cụ của sự ngẫu nhiên làm tên cho công nghệ lưu trữ dữ liệu nghe khá vui

  • DiceDB nghe như tên của một cơ sở dữ liệu đùa cợt chuyên trả về kết quả ngẫu nhiên

  • Kết quả benchmark trên 4vCPU với num_clients=4 không khác biệt nhiều

    • Tính reactive có vẻ đầy hứa hẹn, nhưng tính thực dụng với vai trò cache thì có vẻ thấp
    • Ví dụ, nếu máy bị sập trong khi client đang subscribe thì tính reactive sẽ ra sao, tôi khá tò mò

  • So sánh hiệu năng giữa DiceDB và Redis

    • Throughput của DiceDB là 15655 ops/giây, Redis là 12267 ops/giây
    • So sánh thời gian phản hồi của GET p50 và p90, cùng SET p50 và p90

  • Tôi không hiểu vì sao một yêu cầu GET lại mất 20ms

    • Tôi không có nhiều kinh nghiệm với các triển khai mã nguồn mở hiện có, nhưng ở công ty cũ, thời gian phản hồi trong bộ nhớ thường chỉ ở mức vài chục đến vài trăm micro giây
    • Tôi kỳ vọng dùng io_uring sẽ cho ra timing tốt hơn
    • Nếu đọc từ NVMe và thực hiện khôi phục trên 6 node thì mất vài chục mili giây còn có thể hiểu được
    • Nhưng với một RAM DB một node thì tôi không hiểu vì sao lại ra những con số như vậy

  • Tôi muốn biết có ai có kinh nghiệm với các key-value store mã nguồn mở có độ trễ thấp, throughput cao hay không

    • Có thể gợi ý một triển khai cụ thể nào không

  • Tôi muốn biết về ngữ nghĩa phân phối của PubSub

    • Đây là best-effort / at-most-once hay có cơ chế retry
    • Tôi muốn biết trong những kịch bản nào thông điệp có thể được phân phối hoặc thất bại

  • 15655 ops/giây trên máy Hetzner CCX23 là chậm đối với một cơ sở dữ liệu trong bộ nhớ

    • Không thể đổ cho độ trễ mạng
    • supermassivedb.com được viết bằng Go và cho hiệu năng cao hơn nhiều
    • Cần điều tra điểm nghẽn của Dice

  • Chậm hơn Nubmq rất nhiều