#223 - Tăng tốc độ Redis bằng compression của DoorDash
Trong số này, chúng ta cùng tìm hiểu về:
Khái niệm Architectural decision records
Tăng tốc độ Redis bằng compression của DoorDash
SQL notebooks của Facebook
Lời giải bài Fraction to Recurring Decimal
Ngoài ra các bạn vẫn có thể tiếp tục đặt mua ấn phẩm Dijkstra tập 2 tại đây nhé.
Những bài viết hay
(by nghialuu)
Khái niệm Architectural decision records (ADR) trong phát triển phần mềm là việc ghi chép lại các quyết định về kiến trúc.
Trong quá trình phát triển sản phẩm, các nhóm kĩ sư cần phải ra những quyết định về kiến trúc để đạt được mục tiêu của họ. Những quyết định này có thể liên quan đến technical, ví dụ như quyết định sử dụng pattern CQRS, hoặc liên quan đến quy trình làm việc, ví dụ như sử dụng GitFlow trong quản lí source code. Những quyết định này thường tốn rất nhiều thời gian và công sức, và có những vấn đề liên quan thường xuất hiện khi phải đưa ra quyết định như:
Không đưa ra quyết định nào cả vì sợ quyết định sai
Quyết định được đưa ra mà không có giải thích gì, làm mọi người không hiểu mục đích tại sao. Việc này thường dẫn tới bàn đi bàn lại một chủ đề nhiều lần.
Quyết định đưa ra nhưng không được lưu trữ lại, dẫn đến các thành viên quên đi hoặc không biết về nó.
ARD giúp giải quyết những vấn đề đó. Việc lưu giữ quyết định, bối cảnh, và những cân nhắc dẫn đến quyết định bằng ADR cho phép các stakeholders hiện tại và tương lai thông tin về quyết định và quá trình suy nghĩ đằng sau nó. ADR đóng vai trò là tài liệu tham chiếu, giúp giảm thời gian phát triển phần mềm, review và ra quyết định khác. ADR còn cung cấp document tốt hơn cho các thành viên tương lai, và giúp các kĩ sư học hỏi thêm và hiểu sâu về các cân nhắc của các team khác.
Bài viết bao gồm giới thiệu, hướng dẫn về quy trình, best practice và các tài liệu tham khảo thêm. Mời các bạn cùng đọc và tìm hiểu nhé.
Speeding Up Redis with Compression
(by quangle)
Doordash là một nền tảng giao và đặt đồ ăn trực tuyến với hơn 20 triệu người dùng theo thống kê vào năm 2021. Một trong những thách thức mà các kỹ sư tại đây phải đối mặt chính là đảm bảo độ trễ API luôn ở mức thấp. Đối với những endpoints có lượng truy cập cao như danh sách menu của các nhà hàng, họ cached dữ liệu vào Redis vừa đảm bảo performance vừa hạn chế call trực tiếp liên tục vào database.
Vào dịp khuyến mãi khi các nhà hàng đua nhau tung ra danh sách thực đơn phong phú, dữ liệu được cached có kích thước lên đến nửa MB. Lượng truy cập cao cùng với dữ liệu lớn làm cho việc đọc từ Redis mất nhiều thời gian gây ra độ trễ và tắc nghẽn hệ thống.
Vậy đội ngũ Doordash đã giải quyết bài toán trên thế nào? Thuật toán nén là lời giải của team trong trường hợp này. Sau quá trình đánh giá và xem xét các giải pháp như Zlib, ZStandard và Brotli, v.v, họ nhận thấy LZ4 và Snappy là hai lựa chọn phù hợp đáp ứng được tốc độ nén/giải nén, mức sử dụng CPU và tỉ lệ nén tốt.
Trước khi deploy production, họ tiến hành kiểm tra tốc độ của thao tác đọc-ghi Redis với tập ngẫu nhiên 10.000 menu (có kích thước 9.5KB - 709KB) trong ba trường hợp cụ thể:
Không nén
Nén với Snappy
Nén với LZ4
Qua số liệu thống kê, rõ ràng việc áp dụng thuật toán nén đã giúp cải thiện performance cho hệ thống rất tốt. Để tìm hiểu chi tiết về hướng giải quyết, mời bạn đọc cùng tham khảo bài viết.
SQL Notebooks: Combining the power of Jupyter and SQL editors for data analytics
(by curioustien)
Jupyter Notebook là một trong những tool phổ biến hiện nay cho các data scientist để mà họ có thể truy vấn, phân tích, và xử lý dữ liệu một cách dễ dàng. Có thể nói, Jupyter Notebook đã thay đổi cục diện cách mà các data scientist có thể sử dụng Python một cách hiệu quả trên một web UI. Tuy nhiên, các notebooks này vẫn có vài hạn chế về scalability khi mà các process này đa số được chạy trên local machine. Đồng thời, việc chia sẻ và thông báo các dữ liệu trong Jupyter cũng khó khăn hơn khi mà nó chỉ chạy trên local machine.
Do đó, các đội ngũ kỹ sư ở Facebook đã thiết kế một hệ thống nội bộ để các data scientists có thể dễ dàng viết Python và SQL trong cùng một notebook (được gọi là SQL notebooks). SQL notebooks được thiết kế để các data scientists ở Facebook có thể dễ dàng truy vấn dữ liệu từ Presto, Spark, … và kết nối các dữ liệu này với nhau. Mời các bạn đọc bài viết sau đây để biết thêm chi tiết.
Góc Lập Trình
Đề ra tuần này: Add Two Numbers II
Tóm tắt: Cho 2 số nguyên được biểu diễn bằng LinkedList, hãy tính tổng của 2 số và trả lại kết quả cũng là LinkedList.
Ví dụ:
l1 = 7 → 2 → 4 → 3
l2 = 5 → 6 → 4
Tổng của hai số là 7243 + 564 = 7807
Biểu diễn bằng LinkedList: 7 → 8 → 0 → 7
Lời giải đề bài tuần trước: Fraction to Recurring Decimal
(by phucnh)
Đây là một bài áp dụng cách chia 2 số nguyên. Ta cùng ôn lại cách chia.
Giả sử ta có phân số 4/9, tử số (numerator) là 4, phân số (denominator) là 9, để biểu diễn phân số dưới dạng số thực, ta thực hiện 4 chia 9 như sau:
Phần nguyên = tử số / mẫu số - 4 / 9 = 0, dư 4
Phần thập phân = số dư * 10 / mẫu số
4 * 10 / 9 = 4, ta có kết quả = 0.4, dư 4
4 * 10 / 9 = 4, ta có kết quả = 0.44, dư 4
4 * 10 / 9 = 4, ta có kết quả = 0.444, dư 4
...
Nếu ta cứ tiếp tục thực hiện phép chia, ta luôn luôn thu được số dư là 4, và phần thập phân là một chuỗi số 4 vô hạn. Theo đề bài, ta cần biểu diễn dưới dạng "0.(4)".
Bạn đọc có thể thực hiện tương tự để biểu diễn các phân số 1/3, 2/3, 4/333...
Ta nhận thấy, nếu ta gặp số dư lặp lại, ta sẽ được kết quả chia giống với kết quả chia trước đó, và độ dài của số thập phân là vô hạn. Như vậy ta hoàn toàn có thể sử dụng hashmap để kiểm tra xem đã gặp số dư trước đó chưa. Thuật toán được thực hiện như sau: https://pastebin.com/ucpPX8T2
Code & Tools
50projects50days - 50+ dự án web nhỏ sử dụng HTML, CSS, và JS
Flutter - một Google's SDK đa nền tảng để việc xây dựng ứng dụng trên mobile, web, và desktop một cách dễ dàng hơn
Quotes
The most important property of a program is whether it accomplishes the intention of its user.
― C.A.R. Hoare
Feedback
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)