TĂNG HIỆU SUẤT LÀM VIỆC VỚI SQL (Phần 1)

16/06/2020 513
CODEWELL

SQL (Structured Query Language) ngôn ngữ truy vấn mang tính cấu trúc, chuyên dùng để đọc, ghi, cập nhật, xoá dữ liệu trên các cơ sở dữ liệu quan hệ (relational database). Phần lớn các hệ thống phần mềm đều sử dụng SQL, thông qua các vendor khác nhau như Postgres, MySql, SqlServer, OracleDB… Mỗi hệ quản trị cơ sở dữ liệu lại có tính năng, ưu thế riêng biệt, như opensource, stable, big data… Việc lựa chọn vendor nào phụ thuộc vào nhiều yếu tố, ở đây chúng ta bỏ qua sự khác nhau này và tập trung vào phần lõi: SQL.

SQL Overview

Trong quá trình phát triển phần mềm (gọi chung cho tất cả các platforms: web, app, mobile…), rất nhiều vấn đề xảy ra liên quan tới cơ sở dữ liệu như: việc truy xuất dữ liệu tốn quá nhiều thời gian, ghi dữ liệu bất đồng bộ, chi phí quản lý cơ sở dữ liệu quá cao, redundant data… dẫn tới giảm hiệu năng của phần mềm, tạo ra những trải nghiệm hạn chế cho người dùng. Đặt trường hợp khách hàng muốn xem danh sách các orders của họ, mà việc truy vấn dữ liệu mất hơn 1 phút dể hoàn thành, thì chắc hẳn họ sẽ ko muốn dùng hệ thống của bạn. Lúc này, việc tối ưu SQL sẽ giúp giải quyết vấn đề.

 

Một số lợi ích của việc tối ưu SQL:

  • Tăng tốc độ, cải thiện hiệu suất làm việc của hệ thống
  • Giảm tải cho cho server
  • Giảm chi phí cài đặt server (việc phải xử lý quá nhiều yêu cầu nhiều tài nguyên về CPU/RAM)

Ở phần này, chúng ta sẽ nói về những phương án mà dev thường xuyên bỏ qua khi nói về cải thiện hiệu suất SQL.

 

  • Cập nhật phần cứng

Đây là giải pháp đơn giản & hiệu quả, effort vừa phải, nhưng thường bị xem nhẹ. Developer thường chú ý tới các giải pháp mang tính programing khi nói về database tuning. Nhưng thực tế, nhiều hệ thống server chỉ chạy với CPU lõi đơn, 512MB ram, thậm chí một số server CPU load và RAM load liên tục ở mức cao, hoặc trường hợp cài đặt quá nhiều ứng dụng trên server cũng dẫn tới tài nguyên cho RDBMS (Related Database Management System – Hệ thống quản lý cơ sở dữ liệu quan hệ) bị hạn chế, làm giảm hiệu quả chung của toàn hệ thống.

Ổ cứng SSD, RAM với bus cao, CPU đa nhân sẽ giúp tăng tốc độ rất nhiều cho RDBMS và cả cho toàn bộ hệ thống của khách hàng. GPU cũng mang lại nhiều giá trị trong những hệ thống cần truy xuất dữ liệu thường xuyên.

 

SSD-to-GPU direct SQL

 

  • Sử dụng kết hợp nhiều database khác nhau cho từng mục đích

Đi kèm với sự phát triển của điện toán đám mây, Cloud DB ra đời, việc dùng nhiều DB trong một hệ thống trở nên đơn giản hơn, điều này tạo tiền đề tốt cho việc tối ưu hoá SQL.

Tiki, Facebook, Pinterest… đều sử dụng nhiều loại & nhiều RDBMS khác nhau, tuỳ từng mục đích sử dụng, developer có thể sẽ bỏ nhiều effort hơn để quản lý connection tới từng DB server, nhưng bù lại, data có thể được truy xuất nhanh hơn, vì lúc này số lượng record trong mỗi DB ít hơn.

Bằng việc dùng nhiều DB khác nhau để quản lý Users, Pictures, Logs, tốc độ đọc, ghi data sẽ tăng lên đáng kể. Trong từng trường hợp, mà người quản trị có thể xem xét scale up từng hệ thống riêng lẻ như Log, Pictures, trong khi vẫn giữ Users DB như cũ.

Pinterest “Pick for you” Feature Architect

  • Backup database

Có hàng chục lý do để backup DB, như: bảo đảm an toàn dữ liệu, phục hồi dữ liệu khi cần thiết, bảo vệ khách hàng, bảo vệ thành quả kinh doanh… Với việc sử dụng Cloud DB, việc backup DB lại trở nên đơn giản hơn bao giờ hết. Các hệ thống dịch vụ Cloud DB đều hỗ trợ backup schedule, quản trị viên có thể setup thời gian bảo trì của DB, nơi lưu trữ, thời gian lưu trữ, một số nhà cung cấp thậm chí còn cho phép backup DB một cách tự động.

Việc backup DB đơn thuần sẽ không giúp ích trực tiếp trong việc tối ưu SQL, nhưng kết hợp với xoá dữ liệu, tốc độ truy xuất & an toàn dữ liệu sẽ tăng lên rất nhiều.

AWS backup architecture

 

  • Lưu trữ dữ liệu cũ (Archive Inactive Data)

Một trong những phương án dễ bị lãng quên trong quá trình tối ưu hoá SQL đó là lưu trữ dữ liệu cũ. Nói chính xác hơn là move/delete những dữ liệu không còn cần thiết, dữ liệu không quan trọng như log, history, messages… vào những nơi phù hợp hơn, thay vì để nó nằm trong DB hiện hành.

Sau hàng tháng (năm) phục vụ, hệ thống sinh ra rất nhiều file logs, message, soft-delete records, invalid-data, những dữ liệu này không được sử dụng, nhưng vẫn sử dụng tài nguyên RDBMS, quá trình truy xuất các dữ liệu có dính dáng tới các phần này thường sẽ mất nhiều thời gian khi số lượng record lên tới hàng triệu. Bằng việc backup DB, ta có thể chuyển những record này vào nơi backup, từ đó giảm được số record trong DB hiện hành, tốc độ truy vấn/insert dữ liệu sẽ tăng lên rất nhiều. Khi cần thiết, ta hoàn toàn có thể restore lại bằng các bản backup hoặc các kỹ thuật restoration khác.

View archived data flow

Lưu ý: Ta sẽ hoàn toàn không xoá dữ liệu, mà sẽ chuyển nó qua 1 storage khác để có thể phục vụ các mục đích khác. Ví dụ:

  • Chuyển các dữ liệu mua hàng của người dùng sang analytic DB, và sử dụng dữ liệu này cho việc phân tích hành vi tiêu dùng. (Tiki)
  • Tạo các bản sao lưu lịch sử chat của người dùng. (Zalo)

Kết luận

Những giải pháp nêu ra trong phần này chủ yếu giải quyết ở phía phần cứng, less programming, tính khả thi cao, các giải pháp có thể dùng riêng lẻ hoặc kết hợp với nhau để ra được kết quả tốt hơn & phù hợp với trường hợp của bạn.

Xem thêm các bài viết của CO-WELL Asia tại đây.

Tham khảo thêm các chia sẻ công nghệ của chuyên gia CO-WELL Asia tại: https://co-well.vn/nhat-ky-cong-nghe/

 

Nguyên HK – CO-WELL Asia