Nhìn vào Redis: Chúng ta có thật sự là những lập trình viên biết phát minh?

Khi nhìn vào hệ sinh thái Redis, tôi lại một lần nữa tự hỏi liệu mình có thể tự tin nói rằng mình thật sự là một lập trình viên biết phát minh hay không.

Sự ra đời của lưu trữ Key-Value

• Từ những năm 2000, khi kỷ nguyên Web 2.0 xuất hiện, các công ty dịch vụ web phải đối mặt với tình huống phải gánh một lượng người dùng khổng lồ
• Để chịu được lưu lượng truy cập khổng lồ này, thứ cần thiết không phải là những máy chủ to lớn hào nhoáng, mà là các hệ thống phân tán quy mô lớn, nhỏ nhưng rẻ
• May mắn là phần lớn cấu trúc dữ liệu đều đơn giản (ví dụ: lấy thông tin userid = 1234)
• Dùng cơ sở dữ liệu quan hệ (RDBMS) thì quá nặng, quá đắt và quá phức tạp
• CAP Theorem xuất hiện
• Vậy thì dù phải bỏ bớt tính nhất quán, chỉ cần nắm lấy tính sẵn sàng và tốc độ là được
• Một cơ sở dữ liệu đơn giản ra đời: đưa key vào thì trả value ra (Memcached-2003, Amazon Dynamo-2007)

Sự ra đời của Redis

• Tại Ý, quê hương của pasta, một lập trình viên tên Salvatore Sanfilippo đang điều hành startup tên là LLOOGG (đúng là chữ Log được viết hai lần)
• LLOOGG cung cấp dịch vụ theo dõi khách truy cập website theo thời gian thực
• Dù quy mô nhỏ nhưng vẫn có người dùng thực tế
• Vào thời điểm đó, phân tích thời gian thực là một việc khá khó
• Dữ liệu bắt đầu tích lũy → RDBMS hiện có ngày càng chậm → không còn đáp ứng được tính phản hồi thời gian thực
• Muốn có phản hồi thời gian thực thì phải dùng bộ nhớ → nhưng Memcached khi đó chỉ hỗ trợ GET, PUT đơn giản ở dạng string
• Cần những chức năng dictionary mở rộng hơn như INCR, DECR, LIST mà lại không có DB nào như vậy? → thôi thì tự làm luôn
• Phiên bản đầu tiên ra đời, chạy trên một TCP server siêu đơn giản (không có những tính năng cao cấp như cluster, AOF hay replication)

Sự tiến hóa của Redis

• Redis không ra đời với mục đích là cache, mà là một kho lưu trữ cấu trúc dữ liệu cho xử lý thời gian thực
• Nhưng rồi mọi người bắt đầu dùng nó làm cache
• Nhu cầu về các cấu trúc dữ liệu vượt ra ngoài cache từ những gã khổng lồ hiện hữu (Facebook, Twitter, GitHub, Stack Overflow, v.v.) ngày càng tăng
• Việc áp dụng dần bắt đầu từ những chức năng nhỏ như lưu session, quản lý token đăng nhập, bộ đếm thời gian thực, hệ thống xếp hạng, số lượt thích
• Các tính năng cần thiết và cấu trúc dữ liệu đủ loại được bổ sung theo hướng tiến hóa (Sorted Set, HASH, Cluster, persistence...)
• Và rồi nó trở thành một nền tảng xử lý dữ liệu linh hoạt

Cộng đồng, UX và triết lý của lập trình viên

• Redis được xây dựng trên triết lý rằng nhiều tính năng nhưng không được phức tạp
• Tài liệu chính thức cung cấp các ví dụ có thể chạy ngay trên CLI và mô tả hành vi rõ ràng
• Các lệnh trực quan (SET, GET, LPUSH, ZADD, HGETALL, v.v.) chỉ cần liếc qua tài liệu chính thức là có thể nắm ngay chúng làm gì
• Tính trực quan này không chỉ dừng ở sự tiện lợi, mà còn có vai trò hạ thấp rào cản tâm lý với công cụ và nâng cao năng suất của lập trình viên
• Tính phổ dụng sinh ra từ cấu trúc như vậy mang lại lợi ích cho cả người dùng, nhà cung cấp cloud lẫn những người đóng góp mã nguồn mở
• Trong một hệ sinh thái được cấu thành từ lợi ích của các bên, Redis đã trở thành tiêu chuẩn thực tế của in-memory DB thông qua một lựa chọn không bị ép buộc

Nhìn vào hệ sinh thái Redis

• Redis khởi đầu như một phương tiện để hiện thực hóa ý tưởng có lẽ khá phổ biến: phân tích khách truy cập theo thời gian thực
• Nó vượt qua giới hạn của phương thức cũ là SQL (chậm và đắt) bằng một cách tiếp cận mới
• Đó không phải là tối ưu hóa các quy tắc cũ như tận dụng quan hệ trong ngành, ép nhà thầu, tuning phần cứng hay giới hạn mức sử dụng
• Mà là tạo ra một quy tắc mới: biến bộ nhớ thành yếu tố cốt lõi của DB
• Muốn tự thiết kế công cụ, đề xuất một luồng làm việc chưa từng có và khiến cả thế giới chấp nhận nó, thì kiến thức nền tảng để ứng dụng là rất quan trọng
• Chỉ cần nhìn vào Amazon Dynamo, được thiết kế để giải quyết bài toán lưu giỏ hàng, cũng thấy rằng phải ứng dụng kiến thức về hệ thống phân tán rất phức tạp
• Khi trở thành chuẩn ngành nhờ sự lựa chọn tự nguyện của mọi người, nó sẽ tạo ra giá trị gia tăng khổng lồ và việc làm
• Chỉ cần nhìn vào nhân lực chuyên về Redis, hạ tầng phần cứng, nội dung học tập, dịch vụ managed (AWS, Azure), giải pháp chuyên biệt (Redis Enterprise) là có thể đồng cảm với điều đó
• Tất cả những điều này không phải do chính sách hay luật pháp của chính phủ kiểu cứu ngành xx hay hỗ trợ doanh nghiệp vừa và nhỏ gì đó tạo ra

Chúng ta cần tự hỏi liệu mình có đang sống với lối tư duy của thời đại công nghiệp chế tạo, trong khi bề ngoài chỉ mới giống một nước phát triển, và nhầm tưởng rằng lập trình viên là người làm trong ngành dịch vụ tri thức hay không.

• Liệu chúng ta có thể chứng minh bằng kết quả vì sao công nghệ nền tảng (ví dụ: thuật toán) lại quan trọng
• Liệu có tồn tại văn hóa lập trình viên và hệ thống giáo dục có thể tự tạo ra công cụ để giải quyết vấn đề hay không
• Ai cũng nói phải nuôi dưỡng một văn hóa chấp nhận thất bại, nhưng liệu bản thân tôi có đang nổi giận hay chửi bới trước sai lầm của người khác hay không
• Liệu chúng ta có thật sự hiểu giá trị gia tăng của ngành dịch vụ tri thức và có thể kiên trì theo đuổi nó đến cùng hay không

Tôi lại tự nhắc mình rằng một lập trình viên thực thụ không chỉ là người dùng công cụ giỏi, mà là người dù công cụ còn vụng về vẫn có thể tự thiết kế công cụ mình cần, rồi làm cho người khác cũng có thể dùng nó dễ dàng, từ đó mở rộng hệ sinh thái và tạo ra giá trị gia tăng.

[roxie]

Tôi thấy mình như đồ giả vậy hu hu

[iolothebard]

Phát minh về tính hữu dụng…