#171 - TimescaleDB cải thiện hiệu suất của PostgreSQL bằng Skip Scan

Grokking Vietnam

May 17, 2021

Những bài viết hay

Optimizing web servers for high throughput and low latency - Dropbox — dropbox.tech

Dropbox Edge Network là một tầng proxy được dựa trên nginx mà các kỹ sư ở Dropbox xây dựng để đáp ứng được các yêu cầu về tính độ trễ thấp và băng thông cao. Để đạt được điều này thì các kỹ sư ở Dropbox cần phải tối ưu hóa hiệu suất và lựa chọn thiết kế đúng đắn từ tầng ứng dụng cho tới tầng phần cứng của các web servers ở Dropbox.

Bài viết sau đây được Alexey Ivanov, một kỹ sư ở nhóm Dropbox Traffic, trình bày cụ thể những cách tối ưu hóa mà Dropbox đã áp dụng trên máy chủ của họ ở các phần như là: hardware, operating system, và application level. Một vài ví dụ điển hình như là:

Các tác vụ cần độ trễ thấp thì nên lựa chọn các loại memory có tốc độ xử lý nhanh hơn. Trong khi các tác vụ cần băng thông cao thì nên lựa chọn nhiều dung lượng memory hơn
Nếu bạn dùng Intel CPUs thì nên xem xét Turbo Boost có được bật lên hay chưa
Để kiểm chứng độ hiệu quả của các cách thức tối ưu được bạn áp dụng bên mảng network thì bạn có thể xem qua các TCP metrics ở /proc/net/snmp và /proc/net/netstat
Cho dữ liệu static thì bạn có thể pre-compress trong quá trình build để tối ưu hóa dữ liệu. Trong khi các dữ liệu dynamic thì bạn nên cẩn thận ở việc cân bằng thời gian compress dữ liệu ở máy chủ, thời gian truyền dữ liệu, và thời gian decompress dữ liệu ở client

How we made DISTINCT queries up to 8000x faster on PostgreSQL — blog.timescale.com

Chắc hẳn các bạn cũng không còn xa lạ gì với từ khóa DISTINCT trong các câu lệnh SQL khi mà chúng ta cần tìm các giá trị khác biệt ở một cột dữ liệu. Tuy nhiên, ở thời điểm hiện tại của bài viết này thì PostgreSQL có vài hạn chế về hiệu suất cho các câu lệnh có từ khóa DISTINCT khi mà bảng dữ liệu của bạn cần chứa đến hơn vài chục triệu dòng dữ liệu. Lý do ở đây là PostgreSQL hiện tại cần phải quét toàn bộ index để tìm tất các giá trị độc nhất ở một cột dữ liệu. Khi mà dữ liệu của bạn càng tăng lên thì việc chạy các câu lệnh có từ khóa DISTINCT sẽ càng ngày chậm đi do cách thức PostgreSQL hoạt động hiện tại.

Có một mánh nhỏ ở đây cho PostgreSQL là chúng ta có thể thay đổi câu lệnh SQL có từ khóa DISTINCT thành các câu lệnh dùng recursive CTEs. Tuy nhiên, để lập ra những câu lệnh recursive CTEs này hiệu quả thì cần đòi hỏi người dùng phải hiểu rõ hơn cách các câu lệnh này hoạt động như thế nào và đồng thời tăng mức độ phức tạp của câu lệnh. So với việc chỉ cần viết một từ khóa DISTINCT thì bạn có thể thấy độ phức của recursive CTEs sẽ cao hơn hẳn.

Ở những databases khác như MySQL/Oracle/DB2, một trong những cách phổ biến để có hiệu suất tốt cho các câu lệnh có từ khóa DISTINCT này là dùng Skip Scan. Với Skip Scan, thay vi phải quét qua hết các index ở một cột dữ liệu thì Skip Scan sẽ từng bước tìm các giá trị trong một ordered index. Khi mà Skip Scan định vị được một giá trị thì nó sẽ nhanh chóng khởi động lại để tìm giá trị lớn hơn tiếp theo.

Bài viết sau đây được các đội ngũ kỹ sư ở TimescaleDB nói về cách họ giới thiệu Skip Scan trên hệ thống của họ như thế nào và các benchmarks họ đã lập ra khi so sánh Skip Scan với Index Only Scan hiện tại của PostgreSQL

Computer Vision @ GIPHY: How we Created an AutoTagging Model Using Deep Learning

Giphy là một kho chứa GIF (Graphics Interchange Format) trên mạng, đặc biệt là các GIF động, do cộng động người dùng đăng tải lên kho chứa này. Giphy giúp người dùng truy vấn và tìm ảnh động nhờ vào tags và captions trên các GIF được đăng lên ứng dụng. Thông thường, người đăng tải GIF phải tự mình đăng nhập các tags của GIF đó cho nên sẽ có một số GIF trên Giphy có thể thiếu một vài tags liên quan tới GIF đó do người đăng tải quên hoặc không cập nhật thông tin tags xác đáng. Nếu không có các tags đúng đắn thì việc tìm kiếm GIF trên kho chứa Giphy sẽ trở nên nan giải hơn.

Do đó, các đội ngũ kỹ sư ở Giphy đã quyết định giải quyết vấn đề này bằng cách tạo một deep learning model để mà dự đoán các tags phù hợp cho một GIF nhất định. Hiện tại, cách thức xây dựng model này được dựa trên bài blog này của Facebook với một vài thay đổi để có thể thích ứng hơn với các nội dung GIF được đăng lên ở Giphy.

Đồng thời, Giphy áp dụng mô hình Teach-Student training setup để xây dựng deep learning model của họ. Một Teacher model sẽ được pre-train trên một weakly supervised datasets và được fine-tuned trên một clean dataset. Sau đó, một Student model sẽ được pre-trained trên một weakly supervised dataset đã được gắn nhãn tự động bởi Teacher model trước đó. Bài viết sau đây được các đội ngũ kỹ sư ở Giphy nói cụ thể hơn về cách họ đã xây dựng model của họ như thế nào để giúp Giphy có thể tự động hóa việc gắn nhãn tags cho các GIF được đăng lên hệ thống của họ. Bạn có thể xem qua bài viết thông qua 2 phần sau đây: phần 1 và phần 2

Góc Database

DynamoDB là một trong các Distributed Database có ảnh hưởng lớn đến thiết kế database hiện đại và là nguồn cảm hứng của nhiều database open source khác như Cassandra, ScyllaDB, ...

Được triển khai dưới dạng serverless nên khi sử dụng DynamoDB chúng ta không cần phải lo lắng quá nhiều về việc scale in, scale out cũng như các tác vụ DBOps thông thường khác. Tuy nhiên giống như các công nghệ khác, để sử dụng DynamoDB hiệu quả thì khi thiết kế chúng ta cần phải lưu ý đến một số giới hạn được đưa ra bởi đội ngũ thiết kế:

Kích thước của một dòng dữ liệu không được vượt quá 400KB.
Khi thực hiện tác vụ Query và Scan, dữ liệu trả về cho mỗi trang truy vấn không vượt quá 1MB.
Mỗi partition chỉ có thể được truy suất với tần suất tối đa là 3000 RCU (Read Capacity Unit) và 1000 WCU (WCU) mỗi giây.

Một điều thú vị về những giới hạn này đó là đây không phải là giới hạn về mặt kỹ thuật của hệ thống DynamoDB, tức là không phải DynamoDB không thể lưu trữ dòng dữ liệu vượt quá 400KB, mà giới hạn được đưa ra để đảm bảo khi bạn sử dụng DynamoDB, thiết kế của bạn sẽ đạt performance tốt.

Mời các bạn đọc bài blog của tác giả Alex để hiểu rõ hơn về các giới hạn này.

Góc Distributed System

The Cockroach Hour: What is CAP Theorem? — www.youtube.com

CAP Theorem là một trong những định lý quan trọng trong lĩnh vực Distributed System. Định lý được phát biểu bởi Eric Brewer vào năm 2000 tại hội nghị chuyên đề của ACM về Distributed System, sau đó được chứng minh vào năm 2002 bởi Seth Gilbert và Nancy Lynch (MIT). CAP Theorem nêu rằng: Trong một hệ thống dữ liệu phân tán, bạn chỉ có thể "strongly support" 2 trong 3 yếu tố: Consistency, Availability và Partition tolerance (nói đúng hơn thì chỉ có thể hỗ trợ là C và P hoặc A và P).

Trong video này, Jim Walker (Cockroach labs) sẽ giới thiệu về định lý CAP và khái niệm Consistency.

Code & Tools

This Week Sponsors

LINE đang tích cực tìm kiếm nhiều nhân tố ở các vị trí chủ chốt để đáp ứng nhu cầu phát triển mạnh mẽ của hệ sinh thái LINE. Đặc biệt, trong vai trò Engineering Manager, các bạn sẽ có cơ hội tác động tích cực đến sự phát triển của con người, tổ chức, sản phẩm và hàng trăm triệu người dùng.

Góc Tuyển Dụng

Xem các vị trí đang đăng tuyển khác tại LINE Technology Vietnam

Quotes

Everything is designed. Few things are designed well.

- Brian Reed