Lưu Quang Triệu

Không ngừng sáng tạo thì sẽ không sợ bị diệt vong

MySpace Và SQL Server

Posted by millionking on January 10, 2012

Tạp chí SQL Server Magazine (sqlmag.com), số 1/2010 đã có bài phỏng vấn nhóm kiến trúc sư dữ liệu của MySpace về việc họ đã sử dụng SQL Server như thế nào cho website của họ. Tôi biết MySpace sử dụng Windows Server và SQL Server từ ngày đầu và thấy hơi ngạc nhiên về điều này. Những website tiên phong về web2.0 như MySpace thường dùng phần mềm mở, vì họ thường sẽ đòi hỏi rất nhiều chức năng vốn không có sẵn và phải tự phát triển. Phần mềm mở giúp việc này dễ dàng hơn phần mềm đóng. Một lý do nữa là với lượng dữ liệu cực lớn như vậy, có lẽ các hệ thống dữ liệu kiểu key/value như facebook, linkedin phát triển và sử dụng sẽ thích hợp hơn, vì chúng có khả năng mở rộng (scalable) tốt hơn nhiều so với các hệ CSDL quan hệ, trong khi không đòi hỏi độ toàn vẹn dữ liệu cao (kiểu như ACID transaction) vốn là thế mạnh của các hệ CSDL quan hệ. Tuy nhiên họ đã chọn SQL Server và đã xây dựng thành công một hệ thống SQL Server khổng lồ. Bản online chỉ những người đặt mua báo mới được truy nhập. Dưới đây là một số chi tiết đáng chú ý.

Lý do chọn SQL Server: vì nó cung cấp một môi trường phát triển mau lẹ (rapid development environment).

Version bắt đầu sử dụng là SQL Server 2000. Hiện đang chạy bản 2005 và đang kế hoạch nâng cấp lên 2008.

Tổng cộng có 450 server và 1200 database, bao gồm các database về user profile, các database hỗ trợ các tính năng cho user, các database cân bằng tải, các database cho hạ tầng gửi tin nhắn. Đây là hệ thống cài đặt SQL Server lớn nhất thế giới, tính về lượng giao dịch và kích thước dữ liệu.

Các production database server không dùng virtualization. Ở môi trường development và staging thì dùng virtualization rất nhiều.

Kiến trúc ban đầu dựa vào replication, trong đó một số loại dữ liệu được replicate đến tất cả các database chứa user profile. Họ đã thay đổi qua nhiều mô hình khác nhau để đáp ứng với lượng giao dịch ngày càng tăng. Trong quá trình này, họ đã phát hiện ra rất nhiều lỗi trong hệ thống replication, và làm việc cùng với nhóm phát triển SQL Server của Microsoft trong việc sửa các lỗi đó. Đến khi số lượng user đạt mốc 100 triệu thì replication không đáp ứng nổi vì độ trễ quá lớn (dẫn đến timeout), và mỗi khi bị lỗi thì đòi hỏi rất nhiều thời gian để xây dựng lại.

Cuối cùng họ chuyển sang dùng Service Broker, khai thác tính không đồng bộ của nó (nên không có vấn đề về timeout). Các ưu điểm khác là khả năng khôi phục nhanh hơn khi bị lỗi, và tính phi tập trung của nó (mỗi node đều có thể khởi tạo yêu cầu). Họ xây dựng một module gọi là Service Dispatcher dựa trên nền Service Broker và mở rộng tính năng của nó, như quản lý tuyến dữ liệu tập trung (centralized route management) và truyền tin multicast (nhiều đối tượng nhận đồng thời).

Phát triển các script để dò tìm và xử lý các sự cố trong database: tìm ra các tiến trình tốn kém nhất theo các tiêu chí thời lượng CPU, lượng bộ nhớ sử dụng, và IO, và biên dịch lại các thủ tục đứng đằng sau nó. Sau đó nó tự động cập nhật lại statistics và xây dựng lại index cho các bảng mà thủ tục đó sử dụng, rồi lấy mẫu lại CPU để kiểm tra. Nếu vẫn không khắc phục được, nó gửi thông báo (qua email/SMS) cho DBA trực ca đó để trực tiếp giải quyết.

Áp dụng trending (dò hướng) trong quản lý database, vừa để phát hiện những thay đổi diễn ra đột ngột, vừa để nhận ra mức độ thay đổi trong một khoảng thời gian nhất định.  Ví dụ, trong việc thống kê sử dụng đĩa (disk utilization), trending giúp họ thấy tốc độ tăng trưởng thông thường của các bảng dữ liệu. Khi độ tăng trưởng này thay đổi khác với tốc độ thường lệ, nhóm phụ trách lưu trữ sẽ nhận được thông báo. Nhóm này sẽ làm việc cùng các DBA và developer để xem có cần bổ sung thêm đĩa, hay bảng dữ liệu có vấn đề gì cần khắc phục.

Phát triển một ứng dụng gọi là ExecuteSQL, là một công cụ để chạy SQL script đồng thời trên nhiều database. Từ một điểm duy nhất điều khiển execution của SQL script trên 500 database. Có thể điều khiển mức độ song song; các ứng xử khác nhau khi gặp lỗi; chạy các tiến trình không đồng bộ trên các database.

Cả nhóm phát triển database gồm có 24 người. Phần lớn trong số họ phát triển code để phục vụ các ứng dụng front-end. Chỉ có 3 người kiến trúc toàn bộ hạ tầng dữ liệu và thực hiện các công việc quản trị hệ thống CSDL, cũng như phát triển các module mở rộng.

Với kiến trúc hiện tại, downtime là không tránh khỏi vì các server thường xuyên phải cập nhật service pack và các bản vá lỗi; lỗi phần cứng cũng xảy ra thường xuyên (tuy nhiên chỉ các user có dữ liệu trên server bị down mới bị ảnh hưởng, không phải downtime trên toàn site). Khi nâng cấp lên Windows Server 2008 họ sẽ dùng clustering, trong đó với mỗi 10 node hoạt động (active) sẽ có 1 node dự phòng. Khi 1 node cần cập nhật hoặc bị hỏng phần cứng thì các tiến trình được chuyển sang node dự phòng, khi nào hoàn tất thì chuyển ngược lại. Vì thế sẽ tránh được downtime.

Một vài con số (tập hợp từ cả nguồn này):

  • Tổng số server: 450. Toàn bộ môi trường là 64-bit. Các server đều là HP DL585, 8 đường, 4 dual core CPU và 64GB RAM.
  • Tổng số database: 1200
  • Tổng lượng dữ liệu: 1 petabyte (bằng 1000 terabyte)
  • Tổng số bản ghi: 870 tỷ
  • Số user truy nhập mỗi tháng: 130 triệu (trong tổng số 300 triệu user tại thời điểm hiện tại).
  • Số user truy nhập đồng thời: 4,4 triệu tại giờ cao điểm
  • User mới: 300 000 user mới đăng ký mỗi ngày

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: