#139 - Những điều chúng ta nên biết nhiều hơn về database
Những bài viết hay
PostgreSQL at Scale: Database Schema Changes without downtime — medium.com
Trong quá trình development, việc thay đổi database schema để đáp ứng các nhu cầu về business là việc thường xuyên xảy ra. Nhưng khi ứng dụng của bạn phải deal với một số lượng data khổng lồ và một số lượng user session cao, việc migrate data cần phải đảm bảo được data consistency và không làm ảnh hưởng đến các process của những request vào database.
Để đạt được điều đó, chúng ta cần phải nắm rõ cách thức hoạt động của một số operations trong database. Trong bài viết này tác giả sẽ đề cập đến một số topic chúng ta cần phải để ý khi thay đổi schema của PostgreSQL database để đảm bảo database không bị downtime:
Transactional DDL: Không nên gộp nhiều DDL statements trong cùng một transaction
Locking: Postgresql hỗ trợ khá nhiều loại lock khác nhau, việc nắm rõ các loại lock này sẽ giúp chúng ta biết được nếu migration của mình có downtime
Table Operations: Các operation với table như rename nếu không có chiến lược migration một cách hợp lý cũng sẽ gây ảnh hưởng, vì nó sẽ áp dụng exclusive lock lên table trong quá trình rename
Column Operations: Các operation với column cũng cần phải được chú ý, việc thêm column với giá trị default hoặc việc xóa column cũng có thể làm database có downtime
Index Operations: Tương tự như các operation đối với table và column, operation index cũng sẽ lock table để update lại index tree, PostgreSQL cũng support concurrently cho các operation với index nhưng nó không phải là silver bullet vì nó có cũng có những điểm hạn chế mà chúng ta cần phải dể ý khi dùng nó.
Constraints: Việc thêm not null constraint cho những dữ liệu hiện tại sẽ lock table và PostgreSQL sẽ quét hết những dữ liệu đó để đảm bảo tính xác thực của dữ liệu
Enum Types: Việc tạo hoặc xóa một enum type sẽ khiến postgresql áp dụng locking để đi check lại xem có chỗ nào đang xài những type này hay không
The journey of deploying Apache Airflow at Grab — engineering.grab.com
Apache Airflow là một trong những hệ thống phổ biến hiện nay được dùng để thiết lập và chạy những data pipelines cho việc chuyển hóa dữ liệu, tạo models cho machine learning, và nhiều công dụng khác. Tại Grab vào năm 2018, họ có khoảng vài teams nội bộ sử dụng Airflow. Tuy nhiên, số lượng teams ngày càng gia tăng và nhu cầu sử dụng Airflow ngày càng tăng. Dẫn tới, việc quản lý những Airflow instances và jobs ngày càng khó khăn hơn.
Hiện tại, Grab đang có gần tới 60k jobs chạy hàng ngày trên Airflow so với mức vài trăm jobs vào năm 2018. Bài viết sau đây được tác giả Chandulal Kavar, một kỹ sư tại Grab, nói về cách họ làm sao để quản lý một số lượng lớn Airflow jobs trên hệ thống kubernetes. Trong bài viết này, tác giả cũng nói về cách Grab thiết kế hệ thống làm việc như thế nào để mở rộng dễ dàng hơn khi nhu cầu nội bộ càng ngày càng gia tăng trong việc sử dụng Apache Airflow.
Data Scientists, The 5 Graph Algorithms that you should know — towardsdatascience.com
Những thuật toán về đồ thị (graph) thường được đề cập khá là nhiều khi đi học, nhưng ít khi được đụng tới nhiều lúc đi làm trừ khi công việc của bạn có liên quan tới lĩnh vực này. Do đó, đôi khi bạn sẽ quên đi một số thuật toán về graphs mặc dù những thuật toán này có thể giúp bạn thành công hơn trong công việc hiện tại. Bài viết sau đây đề cập tới 5 thuật toán phổ biến về graphs và cách chuyển đổi các bài toán trong công việc để áp dụng những thuật toán này:
Connected Components: thuật toán này dùng để tính bao nhiêu thành phần liên thông có trong một graph hoặc là để xem 2 đỉnh nào đó có liên quan tới nhau hay không. Một ứng dụng thường gặp ở đây là để xem thử một người dùng có liên quan trong một nhóm người tiêu dùng nào đó hay không
Shortest Path: thuật toán này dùng để tính thử đường đi ngắn nhất giữa 2 đỉnh là bao nhiêu. Một ứng dụng ở đây là khi Linkedin tính xem thử một tài khoản được giới thiệu là bao xa so với tài khoản của bạn (1st/2nd/3rd degree connection)
Minimum Spanning Tree: thuật toán này dùng để tìm cây bao trùm nhỏ nhất của graph hiện tại. Một ứng dụng ở đây là dùng để phân vùng ảnh khi mỗi pixel được xem là một đỉnh của graph và đoạn đường từ những pixels là độ giống nhau của mỗi pixel đó (như là màu sắc, độ nét, …)
PageRank: nhờ thuật toán này mà công cụ tìm kiếm Google mới có thành công được như ngày hôm nay. Thuật toán này được dùng để tính điểm cho từng đỉnh của graph. Thuật toán này rất là phổ biến để tính điểm cho việc giới thiệu sản phẩm hoặc là bài đọc trong mạng xã hội
Centrality Measures: thuật toán này dùng để tìm những điểm nổi bật của graph. Một ứng dụng điển hình của thuật toán này là dùng để làm một yếu tố cho machine learning model
Góc Database
Things I Wished More Developers Knew About Databases — medium.com
Những điều chúng ta nên biết nhiều hơn về database
Database đóng một vai trò vô cùng quan trọng trong các hệ thống hay ứng dụng ngày nay. Mặc dù không thể bỏ qua cách hoạt động của database, nhưng những vấn đề mà các dev thấy trước và trải nghiệm thường sẽ chỉ là phần nổi của tảng băng chìm. Trong bài viết này, tác giả chia sẻ một số thông tin chi tiết và hữu ích giúp cho việc làm việc với database.
Chúng ta rất may mắn nếu 99.999% network hoạt động tốt. Đó là một cuộc tranh luận mở về mức độ đáng tin cậy của mạng ngày nay và mức độ phổ biến của các hệ thống gặp phải thời gian ngừng hoạt động do mất kết nối mạng.
ACID có rất nhiều ý nghĩa. ACID bao gồm tính nguyên tử (atomicity), tính nhất quán (consistency), tính cô lập (isolation), độ bền (durability). ACID luôn được đảm bảo cho người dùng ngay cả trong trường hợp có sự cố, lỗi, lỗi phần cứng và tương tự. Không phải mỗi database đều hỗ trợ ACID, và kể cả với các database có hỗ trợ ACID thì ACID cũng có thể được hiểu khác nhau. Một trong những lý do tại sao ACID được triển khai khác nhau là những sự đánh đổi liên quan đến việc triển khai các khả năng của ACID.
Mỗi cơ sở dữ liệu có tính nhất quán (consistency) và khả năng cách ly (isolation) khác nhau. Khi chúng ta scale database theo chiều ngang bằng việc thêm nhiều máy, đảm bảo mức độ nhất quán cao có thể cực kỳ khó vì vì chúng ta phải đánh đổi availability hoặc khả năng chịu đựng network partitioning. Với isolation, các database thường cung cấp nhiều lớp cách ly khác nhau để các nhà phát triển ứng dụng có thể chọn lớp hiệu quả nhất về chi phí dựa trên sự cân bằng của chúng. Các mức độ isolation trong SQL: Serializable, Repeatable reads, Read commited, Read uncommitted.
Các exclusive lock có thể bị ảnh hưởng bởi các phân vùng mạng nhiều hơn và gây ra các deadlock khó xác định và giải quyết. Trong trường hợp không thể dễ dàng giữ được Exclusive locks, optimistic locking là một lựa chọn. Optimistic locking là một phương pháp khi bạn đọc một hàng, bạn ghi lại số phiên bản, dấu thời gian sửa đổi lần cuối hoặc checksum. Sau đó, bạn có thể kiểm tra phiên bản đã không thay đổi nguyên bản trước khi thực hiện thay đổi bản ghi.
Có những bất thường khác ngoài dirty reads và data loss. Một trong các ví dụ là write skew. Việc ghi sai xảy ra không do dirty read hay data loss, mà do các rằng buộc logic trên dữ liệu bị xâm phạm.
Bạn có thể không hiểu rõ về ordering trong database. Database có thể thực thi các transactions nhận được không theo thứ tự lập trình mà các nhà phát triển nhìn thấy. Thứ tự thực hiện transaction rất khó dự đoán, đặc biệt là trong các hệ thống có khối lượng lớn.
Cơ chế sharding cấp ứng dụng (application-level sharding) có thể được tách biệt. Khi có thể dự đoán cách dữ liệu sẽ được truy cập, bạn có thể tạo các phân vùng ngang thay vì ủy quyền công việc này cho cơ sở dữ liệu. Đây được gọi là sharding cấp ứng dụng.
Sử dụng AUTO INCREMENT có thể có hại, đặc biệt trong các hệ thống database phân tán.
Clock skew xảy ra giữa bất kỳ nguồn clock nào.
Latency có rất nhiều ý nghĩa. Latency có thể gây ra bởi database hoặc network.
Đánh giá các yêu cầu về hiệu suất trên mỗi transaction. Khi đánh giá một cơ sở dữ liệu mới về hiệu suất, một cách tiếp cận toàn diện hơn là đánh giá các hoạt động quan trọng (mỗi truy vấn và hoặc mỗi transaction) một cách riêng biệt.
Nested transaction có thể gây hại. Không phải database nào cũng hỗ trợ tính năng này, tuy nhiên với những databse có hỗ trợ, chúng có thể gây ra những lỗi rất khó debug cho người dùng.
Transactions không nên chứa trạng thái (state) của ứng dụng.
Query planners có thể nói nhiều điều về database.
Online migration rất phức tạp nhưng hoàn toàn khả thi.
Tăng khối lượng sử dụng lên database có thể gây ra những hệ quả khó lường trước được.
Code & Tools
Quote
Simplicity is the soul of efficiency
- Austin Freeman