Redis và cái giá của tham vọng

 (charlesleifer.com)
4 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Redis đang xem xét cả một PR lớn cho array type vào năm 2026, cho thấy nó đã chuyển từ một máy chủ cấu trúc dữ liệu đơn giản thành một sản phẩm muốn bao trùm nhiều lĩnh vực
  • Redis thời kỳ đầu, đúng như tên gọi Remote Dictionary Server, đã nhanh chóng có chỗ đứng trong web stack nhờ một từ điển in-memory tốc độ cao, tập lệnh hẹp và giao thức đơn giản
  • Trong 10 năm qua, Redis đã mở rộng với Streams, JSON, search, graph, time-series, Redis-Raft, vector sets... và ngày càng mang định hướng database rõ rệt
  • Sự phình to về tính năng làm suy yếu sự đơn giản và tính nhất quán vốn là thế mạnh của Redis, đồng thời gia tăng các tích hợp nửa vời ở những lĩnh vực vốn cần công cụ chuyên biệt
  • Valkey thay vì chạy theo các tính năng hào nhoáng lại tập trung vào hiệu năng đa luồng, hiệu quả bộ nhớ và độ tin cậy của cluster, nhắm tới nhóm người dùng Redis kiểu 2011

Bản sắc mà Redis đã đánh mất

  • Redis đã đi đến mức vào năm 2026 còn xem xét bổ sung array type qua một PR lớn, điều này tượng trưng cho sự chuyển đổi từ một máy chủ cấu trúc dữ liệu đơn giản sang một sản phẩm muốn bao phủ nhiều lĩnh vực
  • array type PR của antirez bắt đầu từ vấn đề rằng Hash, List và Stream mỗi loại đều mạnh ở truy cập ngẫu nhiên, append/trim và sự kiện append-only, nhưng không thể đồng thời cung cấp truy cập giữa chừng và khả năng quan sát theo phạm vi như mảng
  • Redis đã có những tính năng có thể dùng gần giống mảng như JSON array, time-series và sorted-set, nhưng việc vẫn muốn thêm một kiểu mới nữa cho thấy rất rõ bản chất của xu hướng mở rộng tính năng
  • Vấn đề cốt lõi là sự đơn giản, giao thức rõ ràng, tập lệnh hẹp và trực giao, cùng tính nhất quán về mặt khái niệm, vốn là lý do khiến Redis thành công ban đầu, nay đang suy yếu

Những thay đổi trong 10 năm qua

  • Giấy phép và định hướng của công ty

    • Redis Inc đã ngừng giấy phép BSD vào năm 2024, rồi lùi về hệ thống ba giấy phép trong đó AGPLv3 là lựa chọn OSI duy nhất
    • Nhờ AGPLv3, Redis Inc vẫn có thể nói mình là mã nguồn mở, nhưng đây là một loại giấy phép có tính chất rất khác so với BSD
    • Công ty được VC hậu thuẫn đứng sau Redis ban đầu là Garantia Data, một dịch vụ cloud hosting NoSQL; sau đó họ chuyển sang hosting Redis, đổi tên theo hệ sinh thái Redis và đưa antirez vào để tăng tính chính danh
    • Quá trình tiếp nhận quyền thương hiệu vài năm sau đó trở thành nền tảng cho đợt chuyển đổi giấy phép về sau, và các bài viết cùng bình luận liên quan trong quá khứ nay trông đã lỗi thời theo cách có thể đoán trước

  • Sự phình to của tính năng và định vị sản phẩm

    • Redis khởi đầu với một số ít kiểu dữ liệu hữu ích, nhưng theo thời gian lại ôm thêm các cấu trúc dữ liệu kỳ lạ, các hệ thống stateful phức tạp như Streams, và cả các module mang tính bán độc quyền tùy theo phiên bản
    • Định vị trên landing page của Redis năm 2026 đã đổi thành “The Real-Time Context Engine for AI Apps”
    • Trên landing page có đồng thời các nút “Try Redis for Free” và “Get a Demo”, điều này cũng thấy được trong ảnh chụp màn hình

  • Định hướng cơ sở dữ liệu web-scale

    • Các tính năng như Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® cho thấy Redis đã theo đuổi hình ảnh một “web-scale database”

  • Thay đổi giao thức và client-side caching

    • RESP3 phá vỡ khá nhiều tiền đề cơ bản của mô hình request/response vốn có ở RESP2, và bị đánh giá là gần với kiểu thất bại của “hệ thống thứ hai” mà Brooks từng nói tới
    • Redis vốn được dùng rộng rãi như một cache, nhưng giờ đã tới mức cần cả một giao thức mới để hỗ trợ client-side caching

Vì sao Redis thời kỳ đầu lại khớp đến thế

  • Bối cảnh thời đại

    • Vào khoảng năm 2011, trong giới phát triển web nổi lên mạnh mẽ các làn sóng như NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST và JSON
    • Redis rất hợp với bầu không khí đó, và gần như chỉ sau một đêm đã xuất hiện trong rất nhiều stack
    • Cuối năm 2011, phần giới thiệu Redis mô tả nó là advanced key-value store và data structure server, hoàn toàn chưa có từ “database”

  • Một remote dictionary tốt hơn Memcached

    • memcached là hạ tầng thiết yếu chạy âm thầm trong rất nhiều web server, và ngoài caching còn thường được dùng tạm cho lock, counter, rate limit...
    • Khi đó Redis được nhìn nhận gần như là “memcached but way better”, và chính cái tên Remote Dictionary Server cũng nhấn mạnh bản chất của một từ điển in-memory tốc độ cao
    • Thay vì chỉ có byte blob, Redis còn cung cấp các cấu trúc dữ liệu được chọn lọc tốt như linked-list, hash-table, set, sorted-set, từ đó mở rộng đáng kể các trường hợp dùng tạm thời nhưng thực dụng

  • Giao thức đơn giản mà đủ sức biểu đạt

    • Giao thức wire của Redis đủ đơn giản để có thể hiểu và tự triển khai trong vòng một giờ, nhưng vẫn đủ mạnh để biểu diễn nhiều kiểu dữ liệu
    • Việc hiện thực thư viện client cũng rất đơn giản và gọn gàng, còn bản thân giao thức thì được đánh giá là tự nhiên
    • Bài hướng dẫn write your own Redis về cách tự làm một Redis protocol và máy chủ đơn giản vẫn là một bài viết nổi tiếng từ khoảng 10 năm trước

  • Đơn luồng, hướng sự kiện, in-memory

    • Thiết kế đơn luồng của Redis đảm bảo tính nguyên tử cho mọi thao tác, từ đó giảm đáng kể độ phức tạp và giúp việc suy luận trở nên dễ hơn
    • Để thiết kế đơn luồng hoạt động hiệu quả, máy chủ phải được viết bằng non-blocking I/O, còn các thao tác dữ liệu cũng phải cực nhanh
    • Sự kết hợp này cho phép một key/value store rất nhanh, có thể phục vụ nhiều client, vẫn chạy được chỉ với một luồng

  • Cấu trúc dữ liệu phù hợp với ứng dụng web

    • String cùng thời gian hết hạn phù hợp cho cache, list phù hợp cho queue, còn hash phù hợp cho dữ liệu có cấu trúc
    • Các nhu cầu như lock, counter, rate limiting, liveness, monitoring hay leaderboard cũng có thể được dựng lên dễ dàng chỉ từ các kiểu dữ liệu tích hợp sẵn

Tham vọng trở thành cơ sở dữ liệu

  • Redis được chấp nhận rất nhanh và thành công lớn, nhưng đến một thời điểm nào đó, tham vọng của dự án đã chuyển sang hướng trở thành một database
  • Một số tính năng thực sự hữu ích; chẳng hạn BZPOPMIN được thêm vào Redis 5.0 cho phép blocking pop khi dùng sorted-set như priority queue, nhờ đó tăng tính thực dụng
  • Ngược lại, những tính năng như ACL lại trông không còn “rất Redis”, và nhìn chung có thể thấy rõ ham muốn biến Redis thành mọi thứ cho mọi người
  • Việc bổ sung tính năng trong Redis có nhiều nét giống với cách các nhà phát triển trong 10 năm qua chạy theo “mốt mới nhất” trên Hacker News
    • MongoDB lưu JSON, vậy Redis cũng phải trở thành document database
    • ElasticSearch cung cấp full-text search, vậy Redis cũng phải thành search engine
    • Khi graph database được chú ý, Redis cũng muốn thành graph database, nhưng sau đó lại đi tới RedisGraph EOL
    • Khi Kafka được quan tâm, Redis cũng muốn thành event streaming platform
    • Khi ZooKeeper và các cơ sở dữ liệu strong consistency trở nên quan trọng, Redis-Raft xuất hiện, và bài phân tích Jepsen của Aphyr gần như là tài liệu bắt buộc phải đọc
    • Khi InfluxDB được chú ý, Redis cũng muốn thành time series database
    • Để không tụt lại trước làn sóng AI, Redis cũng phải có các tính năng liên quan đến AI như vector sets

Cái giá của việc mở rộng tính năng

  • Vấn đề thứ nhất là Redis đang tự làm suy yếu chính những yếu tố từng khiến nó trở thành công cụ thiết yếu trong stack của mọi người
    • Redis vốn đơn giản, tập lệnh trực giao và định nghĩa hẹp, giao thức sạch sẽ, và là một công cụ nhất quán về mặt khái niệm
  • Vấn đề thứ hai là những người thực sự muốn tích hợp nghiêm túc full-text search, event stream processing, key/value strong-consistency, time-series hay vector storage sẽ cần công cụ chuyên biệt, chứ không phải các module nửa vời mang theo mọi giới hạn sẵn có của Redis
  • High availability của Redis rất phức tạp, tính bền vững dữ liệu có những đánh đổi tinh vi, còn gánh nặng giao thức và sự phân mảnh phía client cũng là các rào cản thực tế
  • Quan điểm ở đây là Redis không phải công cụ để thay thế Postgres, còn các hệ thống như ElasticSearch và RabbitMQ vẫn nên giữ vai trò trụ cột riêng của chúng
  • Phân tích ban đầu của Aphyr về hiện thực Redis-Raft từng ghi nhận 21 vấn đề
    • Không khả dụng trong thời gian dài ngay cả khi cluster vẫn khỏe mạnh
    • 8 vụ crash
    • 3 lần stale read
    • 1 lần aborted read
    • 5 lỗi dẫn tới mất các cập nhật đã commit
    • 1 vòng lặp vô hạn
    • 2 vấn đề có thể gửi phản hồi hỏng về mặt logic cho client
    • Phiên bản đầu tiên được kiểm thử là 1b3fbf6 bị đánh giá là trên thực tế không thể sử dụng được
  • Redis với tư cách cache và data structure server khác về bản chất với “Redis như một etcd” hay Redis theo đuổi các cơ sở dữ liệu chuyên biệt khác, và khoảng cách đó chính là vấn đề trọng tâm

Disque cho thấy cùng một mô thức

  • Năm 2015, antirez công bố Disque, và khi đó ông thừa nhận đây không phải là dự án xuất phát từ trường hợp sử dụng thực tế, mà được thiết kế ở “astronaut mode” sau khi nhìn thấy người ta dùng Redis như message queue và nhìn thấy các message queue khác
  • Một dự án được làm như thử thách cá nhân hay bài tập học hỏi mà không có use case thực tế vẫn có thể rất tuyệt, nhưng việc có tiếp tục giải quyết được cái đuôi dài của những vấn đề khó xuất hiện khi người dùng tăng lên hay không lại là chuyện khác
  • Việc phân phối thông điệp với high availability là một bài toán khó để giải cho đúng, và dù tối ưu theo phía nào của định lý CAP thì vẫn không thể tránh được các đánh đổi và những vấn đề hóc búa
  • Tới năm 2015 đã có rất nhiều message broker trưởng thành, và lý do người ta dùng Redis như message broker là vì họ đã dùng Redis sẵn rồi và nó đủ đơn giản
  • Điều cần thiết không phải là một message broker mới, cũng không phải việc Redis trở thành một message broker phức tạp hơn
  • Disque gần như trở thành abandonware ngay sau khi ra mắt, và dù đạt 8K stars trên GitHub vẫn bị bỏ mặc
  • Sau đó nó được viết lại thành một Redis module, nhưng dự án ấy cũng tiếp tục bị bỏ bê suốt 7-8 năm qua

Valkey cho thấy một hướng đi khác

  • Những lực đẩy đã dẫn dắt quỹ đạo của Redis được gói lại trong ba loại tham vọng: tham vọng của nhà phát triển muốn giải các bài toán phức tạp, tham vọng trở thành mọi thứ cho mọi người, và tham vọng của chủ sở hữu Redis muốn khai thác tối đa doanh thu trước khi thua AWS và GCP
  • Bản thân tham vọng không phải vấn đề, nhưng nó trở thành vấn đề khi khiến Redis đánh mất lý do thành công của mình
  • Sự tồn tại và mức độ chấp nhận của Valkey được nêu ra như phán quyết cuối cùng của thị trường rộng lớn hơn đối với động lực đó
  • Thay vì chạy đua tính năng hay thêm các gạch đầu dòng trong bảng so sánh, Valkey đầu tư vào những việc ít hào nhoáng hơn như hiệu năng đa luồng, hiệu quả bộ nhớ, độ tin cậy của cluster và cải thiện thông lượng
  • Benchmark hiệu năng của Valkey rất ấn tượng, và nó nhắm thẳng vào 80% người dùng Redis, những người chỉ cần đúng bộ tính năng mà Redis năm 2011 từng cung cấp
  • Trong thế giới của Valkey, kết luận đi đến là không cần một array type mới

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Với góc nhìn của người đã từng mở rộng mã nguồn mở đến quy mô khá lớn, lập công ty, trải qua doanh thu hàng trăm triệu đô, IPO, bán lại với giá hàng tỷ đô, và trong quá trình đó cũng đã từng đổi giấy phép rời khỏi OSS, thì cách Redis định vị mình là “công cụ context thời gian thực cho ứng dụng AI” có vẻ đúng hướng
    Trong việc mua phần mềm có người dùng trực tiếp và người ra quyết định kỹ thuật (TDM), còn trang đích của Redis trông giống một site nhắm đến TDM có quyền ngân sách hơn là các lập trình viên sử dụng trực tiếp. Nhiều TDM thích những quyết định kiểu “không ai bị sa thải vì chọn IBM”, và nếu Gartner hay McKinsey nhấn mạnh chiến lược AI cùng quản lý context thì “Context Engine cho ứng dụng AI” trở thành một lý do mua hàng có thể tự bảo vệ được
    Ở HashiCorp cũng từng cố tách terraform.io cho người làm thực tế và hashicorp.com cho TDM, điều này có hiệu quả ở một mức độ nào đó nhưng cũng có giới hạn. Đây là vấn đề khó với các công ty OSS do lập trình viên dẫn dắt
    Các nút “dùng Redis miễn phí” và “nhận demo” cũng không lạ nếu nhìn từ góc độ TDM. TDM không muốn chịu trách nhiệm cho quyết định kỹ thuật và ngược lại thường muốn trả tiền để mua phần mềm, nên phần miễn phí được hạ xuống như bản dùng thử còn lời kêu gọi hành động để kết nối với con người được đẩy ra phía trước
    Có vẻ ban lãnh đạo Redis Inc. đã kết luận rằng việc hấp dẫn TDM quan trọng hơn hấp dẫn lập trình viên/người vận hành; không có dữ liệu nội bộ thì khó nói đúng sai, nhưng đây hẳn không phải chiến lược làm ra mà không có chủ đích
    Việc cứ tiếp tục gắn thêm tính năng cũng là vì chi phí mở rộng công cụ hiện có thấp hơn rất nhiều so với chi phí đưa vào một công cụ mới. Ngay cả khi không có động cơ thương mại, các ngôn ngữ lập trình cũng thường trở thành mẫu số chung tối thiểu của mọi tính năng thay vì giữ bản sắc cốt lõi, còn ở công ty thương mại thì chiến lược “land and expand” hoạt động rất mạnh. Sau khi chốt được hợp đồng đầu tiên bằng tính năng chủ lực, họ có thể bán thêm các tính năng phụ ở mức trung bình vì bộ phận mua sắm xử lý việc mở rộng hợp đồng cũ dễ hơn nhiều so với ký hợp đồng mới
    Lập luận rằng “khách hàng nghiêm túc sẽ muốn sản phẩm chuyên dụng thật sự cho tìm kiếm chuyên biệt / event stream / KV nhất quán mạnh / time-series / vector store” cũng rất gây tranh cãi. Chỉ nhìn vào dữ liệu của các công ty phần mềm đại chúng thôi cũng thấy khách hàng thường xuyên chọn phương án tệ hơn vì những lý do phi kỹ thuật
    Cũng khó khẳng định Valkey là phán quyết cuối cùng của thị trường. Valkey đang làm tốt hơn rất nhiều so với một bản fork trung bình (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), nhưng công ty Redis nhìn từ bên ngoài cũng có vẻ vẫn trụ vững. Nếu nhìn các công ty như ElasticSearch hay MongoDB, vốn đã đổi giấy phép và bị fork nhưng định giá trên thị trường đại chúng không bị ảnh hưởng lớn, thì cũng có thể đi đến kết luận khác. Trong bong bóng lập trình viên có thể nhìn khác, nhưng nếu doanh thu là chỉ báo trễ cuối cùng thì cũng có thể hỏi “điều đó thực sự quan trọng đến thế sao?”
    Không phải để biện hộ cho lợi ích thương mại, chỉ là chia sẻ góc nhìn từ phía đó. Cũng giống như với cùng một nông sản, người đi chợ và nông dân sẽ nhìn bằng những câu hỏi và mục tiêu hoàn toàn khác nhau

    • Phần “vì sao” từ góc nhìn thương mại đã được giải thích khá rõ, và có thêm bối cảnh rằng Redis không tồn tại trong môi trường chân không thuần phần mềm, OSS nerd không phải đối tượng mục tiêu, và người ra quyết định có tiêu chí khác với kỹ sư hệ thống
      Tuy vậy, lập luận này có cảm giác mặc định rằng mục tiêu của mọi người là tiền. Tham vọng kiếm thật nhiều tiền từ Redis chỉ là một kiểu tham vọng cụ thể, còn với thái độ antirez thể hiện trong bài viết thì không giống người quá bận tâm đến tiền
      Có một phản ví dụ là SQLite. Họ không nói về doanh thu hàng triệu hay bán công ty giá hàng tỷ đô, mà tập trung lặng lẽ cung cấp một thứ được định nghĩa rõ ràng. SQLite không đánh mất lý do khiến nó trở thành cơ sở dữ liệu nhúng phổ biến nhất, và ở phía cơ sở dữ liệu lớn hơn thì Postgres cũng tương tự. Cũng như trong thế giới tiền bạc và lợi ích thương mại, ở thế giới này ta cũng có thể đưa ra phản ví dụ
      Với Redis, có vẻ “đã dùng AWS/GCP rồi thì dùng luôn thứ giống Redis bên đó” là kết quả tự nhiên của mở rộng theo chiều ngang. Con đường kiểu IBM hơn là chọn nhà cung cấp đám mây rồi dùng Redis của họ, mà dạo này điều đó lại thành Valkey
      Chuyện mọi người chọn phương án tệ hơn không phải điểm để tranh cãi mà là sự thật, và việc Redis mở rộng theo kiểu đó chính là một ví dụ về tham vọng và trôi dạt mà tôi muốn nhấn mạnh
    • Tôi từng làm ở Redis Labs nên gần như theo nghĩa đen là đứng ở phía “devil’s developer advocate”. Khi nghỉ việc tôi không thực hiện các quyền chọn đã vest, và vì sống rất xa Silicon Valley nên có thể nói mà không phải lo đã đốt quá nhiều cây cầu
      Trước đây redis.com là site cho TDM còn redis.io là cho lập trình viên, nhưng sau khi Redis Labs lấy được redis.io từ antirez thì họ làm hỏng nó đến mức gần như không tìm nổi cả liên kết tải xuống, và giờ cả hai URL đều đưa tới site cho TDM. Đến bây giờ vẫn khó tìm liên kết tải Redis, đến mức tôi muốn bảo bạn tự thử mà xem
      Vấn đề cốt lõi là Redis Labs từ trước đến nay luôn tuyển lãnh đạo marketing rất tệ. Các CMO và VP đến, đốt sạch thiện cảm trong thời gian ngắn nhất có thể, rồi 6 tháng sau lại rời đi đến “cuộc phiêu lưu tiếp theo”. Khi thấy lưu lượng vào redis.io cao hơn redis.com rất nhiều, họ phá redis.io với hy vọng những người không tìm thấy liên kết tải xuống sẽ bấm “try free”; đó có vẻ là kiểu tham lam click ngắn hạn điển hình
      Việc bán thêm tính năng phụ cũng giúp khác biệt với đối thủ trên bảng checklist. Điều này đặc biệt đúng khi khó cạnh tranh bằng giá, còn AWS thì có thể bó ElastiCache với mức giảm giá đám mây rất mạnh, trong khi đối thủ tệ nhất lại là Redis mã nguồn mở miễn phí
      Valkey đang được rót nhiều tiền hơn rất nhiều so với một bản fork thông thường. Ví dụ, cựu phụ trách quan hệ lập trình viên của Redis Labs hiện đang làm Valkey ở AWS
      Tuy vậy, tôi thấy tiếc khi Valkey bị đánh giá là chỉ làm “công việc không hào nhoáng”. Redis thực ra đã đa luồng từ lâu rồi; control plane vẫn đơn luồng nhưng I/O là đa luồng, nên công việc của Valkey không mới như tác giả bài viết nghĩ
      Valkey nói thẳng ra là một chiến dịch để các công ty đám mây như AWS có thể tiếp tục bán Redis mà không phải trả tiền cho ai cả. Những lập luận khác chỉ là công cụ marketing để thuyết phục rằng điều họ muốn tiếp tục làm là chính đáng; nếu họ thấy việc phá vỡ tương thích với Redis có lợi về thương mại thì họ sẽ làm vậy. Tôi cũng sẵn sàng cược là hai bên có lẽ đã phần nào làm thế rồi, chỉ là tôi chưa theo dõi đủ kỹ
      Nếu muốn một bản fork Redis thực sự cố làm “công việc không hào nhoáng” trong khi vẫn giữ sự đơn giản, thì có redict
      Dù vậy, tôi vẫn nghĩ thời của Redis đang dần khép lại. Trong địa hình thương mại kỳ quặc hiện nay, mỗi bản fork đều khập khiễng ở một điểm nào đó. Ngay cả redict, bản có đạo đức nhất, cũng thiếu sự quan tâm thật sự đến việc đẩy Redis tiến lên theo cách mà antirez từng làm với dự án gốc như một nhà độc tài nhân từ. Điều đó không có nghĩa phần mềm “hoàn thiện” là xấu, nhưng tôi tin Redis vẫn còn những vùng chưa khám phá rất thú vị, và tôi nghi ngờ các bản fork thương mại sẽ tạo ra được hệ sinh thái như vậy. Dĩ nhiên tôi cũng có thể đang đánh giá thấp giá trị của Arrays và các ứng dụng liên quan đến AI, nên vẫn muốn giữ đầu óc cởi mở
      Nghĩ lại thì thật đáng ngạc nhiên khi Redis Labs đã làm hỏng tất cả chuyện này nghiêm trọng đến thế, và cũng may là đủ thời gian đã trôi qua để giờ tôi bớt giận hơn
    • Tôi đoán các công ty chỉ đang cố lấy nhiều nhất có thể mà không phải trả tiền. Chẳng phải vì thế mà Redis, MongoDB, HashiCorp cuối cùng đều đổi giấy phép sao

  • Ở công ty tôi đang làm một hệ thống hàng đợi công việc công bằng hơn bằng Lua script, và Redis tạo cảm giác rất kỳ lạ. Mô hình trong đầu tôi lúc nào cũng là “một kho key-value đơn giản”, nhưng rồi lại phải học đủ loại tính năng như chạy Lua script bên trong global lock
    Nhưng tài liệu thì nằm trên một website bóng bẩy và không nói rõ ràng. Ngay cả các giá trị cấu hình cũng kiểu chỉ được giải thích bên trong file mẫu cấu hình
    Tôi biết Redis chạy tốt và ai cũng nói vậy, nhưng trải nghiệm học các tính năng Redis khá khó chịu. Cảm giác như có ai đó đã tạo ra một chương trình thực sự tốt, rồi lại quên mất phần tài liệu tuyệt vời mà một chương trình tốt thường nên có
    Đây đúng là một lời phàn nàn hơi lạ. Redis có vẻ chạy cực kỳ tốt, và tôi thích kiểu tài liệu giải thích “mọi thứ” như tài liệu Postgres

    • Tôi tự hỏi liệu tài liệu của một sản phẩm ít thiên về TDM hơn có dễ hiểu hơn không: https://valkey.io/topics/programmability/
      Nhiều dự án mã nguồn mở cũng nổi tiếng là tài liệu yếu, nên có lẽ trong thí nghiệm này không chỉ có mỗi biến số sếp đầu nhọn
    • Redis trước đây từng có đủ loại tài liệu, và may là có thể dùng Wayback Machine để đảo ngược phần thiệt hại do Redis Labs gây ra. Có thể bạn sẽ tìm được thứ mình muốn ở đây: https://web.archive.org/web/20190725152042/…
      Tài liệu của redict cũng có vẻ tốt: https://redict.io/docs/scripting/