#69 - Sử dụng kỹ thuật stream replication để scale PostgreSQL database tốt hơn
Cảm ơn bạn ledongthuc đã đóng góp ý kiến cho câu hỏi tuần trước (xem bên dưới). Tuần này, mời các bạn cùng đóng góp ý kiến cho câu hỏi:
"Bạn có đồng ý việc chia sẽ thông tin cá nhân cho các hãng công nghệ như FB để sử dụng vào mục đích nâng cao trải nghiệm người dùng"
Nếu bạn thấy email này bổ ích, hãy forward đến 3 người bạn của bạn nhé (để team biên tập có động lực duy trì và cải tiến newsletter nhiều hơn nữa).
Những bài viết hay
Big Web App? Compile It! — kripken.github.io
Khi các dự án web front-end càng ngày càng lớn và phức tạp, một hướng tiếp cận đang dần phổ biến là chuyển sang xây dựng web bằng một ngôn ngữ lập trình khác, sau đó compile lại thành javascript. Trong slide này, tác giả (đến từ Mozilla) chia sẻ góc nhìn về lợi ích của cách tiếp cận này.
Deriving Data Structures — www.ebayinc.com
Bắt đầu từ array, linked-list, hash, những cấu trúc dữ liệu đang dần dần tiến hoá thành các cấu trúc dữ liệu phức tạp hơn để phục vụ cho nhiều bài toán khác nhau. Trong bài viết này, tác giả chia sẻ góc nhìn của mình về lý do và nhu cầu dẫn đến sự tiến hoá này.
High availability and scalable reads in PostgreSQL — blog.timescale.com
PostgreSQL, DBMS phát triển nhanh nhất trong năm 2017, đang dần trở thành một lựa chọn phổ biến. Tuy nhiên, khi xây dựng các hệ thống big scale, nhiều team vẫn quyết định lựa chọn No-SQL nhiều hơn vì tin rằng nó sẽ scale tốt hơn, và chấp nhận những khuyết điểm của No-SQL như query performance kém hơn khi cần query nhiều bảng liên quan, thiết kế khó hơn do thiết nhiều lệnh mà SQL có, ... Tuy nhiên, liệu PostgreSQL có thực sự khó scale, hay là do chúng ta vẫn chưa dùng hết tính năng của nó. Trong bài viết này, tác giả chia sẻ kỹ thuật "streaming replication" nhằm phần nào trả lời cho thắc mắc trên.
Có thể bạn chưa biết
Upstream và downstream là hai thuật ngữ để ám chỉ vị trí tương đối của components trong một hệ thống trong chuỗi phụ thuộc lẫn nhau. Ví dụ như một hệ thống có 4 services A, B, C, D với mối quan hệ như sau:
Mũi tên từ service A đến server B có nghĩa là service B sẽ cần truy xuất đến service A -> service B phụ thuộc vào service A.
Trong sơ đồ này, service A sẽ được gọi là Upstream của service B, tương tự service B sẽ được gọi là upstream của service D.
Downstream có ý nghĩa tương tự, nhưng là cho chiều ngược lại.
Đọc thêm: https://reflectoring.io/upstream-downstream/
Your voice
Chúng tôi đã nhận được ý kiến từ bạn ledongthuc cho câu hỏi "Bạn nghĩ sao về những mục cơ bản cần phải có của bản thiết kế một tính năng trong phần mềm?". Cảm ơn bạn ledongthuc đã đóng góp ý kiến.
1. Business flow chart: dùng để mô tả lại flow business của tính năng cần thiết kế
2. Components Flow charts: Dùng để mô tả các components/service trong hệ thống giao tiếp với nhau như thế nào. Trong này cũng định nghĩa luôn các component của 3rd mình cần giao tiếp.
3. Flowcase: Gần như flow chart nhưng detail từng cases. Success flow ra sao, fail flow ra sao, retry ra sao, retry fail ra sao, rollback ra sao, fail rollback ra sao, timeout running ra sao, unreachable 3rd service thì ra sao.
4. Screens + Screen flow: Nếu đổi liên quan tới UI thì trông nó sẽ nào. Bấm cái gì ra cái gì, quẹt cái gì ra cái gì.
5. API: những API nào cần thêm/đổi, API đó là kiểu gì, socket, webservice, REST, ... Giao tiếp ra sao, method thế lào, data nhưng nào. Auth kiểu gì, vpn hay sao, bla bla bla
6. Storage design: Lưu data như thế nào, db gì, table gì, column ra sao. Caching ra sao. Index db ra sao, bla bla bla
7. Những tech liên quan hoặc cần chú ý: Nếu feature có những phần đặc thù cần note ra: xài encryption abcxyz, key kiểu gì, có amoured hay ko, xài protocal ISO 8583. Hoặc những gì mà cái ở trên chưa cover dc thì thêm dưới này.
8. Document versioning, ko có cái này sẽ cãi nhau suốt giữa tech team vs business team.
Code & Tools
https://github.com/radondb/radon A ‘cloud-native’ database supporting distributed transactions, automatic table sharding, and as of this week, distributed joins. Written in Go.
https://github.com/google/leveldb A fast key-value storage library
https://github.com/nokia/memory-profiler A new memory profiler for Linux from Nokia written in Rust
Quotable
"Every great developer you know got there by solving problems they were unqualified to solve until they actually did it."
- Patrick McKenzie