GoonCách Notion Giải Quyết Khủng Hoảng Khả Năng Phát Triển
Năm 2021, sự phổ biến của Notion tăng vọt, nhưng dịch vụ của nó trở nên chậm chạp không thể chịu đựng được. Cơ sở dữ liệu hậu khủng hoảng của công ty có dung lượng hàng terabyte, ngay cả khi được nén, và sắp bị quá tải. Đối mặt với nguy cơ mất khách hàng, Notion cần giải quyết vấn đề này nhanh chóng.
Về cơ bản, mọi thứ trong Notion đều là một khối, có thể là một đoạn văn bản, một hình ảnh, hoặc toàn bộ một trang. Mỗi khối được lưu trữ dưới dạng RLE trong PostgreSQL với ID duy nhất của nó. Các khối có thể được lồng vào trong các khối khác để tạo ra các cấu trúc dạng cây phức tạp, cho phép tính linh hoạt đáng kinh ngạc. Tuy nhiên, cấu trúc này cũng đồng nghĩa với việc ngay cả một tài liệu đơn giản cũng có thể dẫn đến hàng trăm hoặc hàng nghìn mục nhập cơ sở dữ liệu.
Với hàng triệu người dùng, cơ sở dữ liệu của Notion đã bị quá tải, dẫn đến độ trễ tăng lên và phản hồi chậm. Cơ sở dữ liệu đơn khối duy nhất của công ty không còn có thể xử lý được tải, và chi phí tăng theo cấp số nhân.
Giải pháp: Phân mảnh Ngang
Notion quyết định phân mảnh tất cả các bảng được liên kết với bảng khối thông qua khóa ngoại. Điều này bao gồm các không gian làm việc, các cuộc thảo luận và bình luận, giữ dữ liệu liên quan trong cùng một phân mảnh. Khóa phân vùng được chọn là ID không gian làm việc, vì người dùng thường yêu cầu dữ liệu cho một không gian làm việc duy nhất tại một thời điểm.
Thiết lập phân mảnh mới cần xử lý dữ liệu hiện có và mở rộng để đáp ứng sự tăng trưởng dự kiến trong ít nhất hai năm. Loại instance cần ít nhất 60k tổng IOPs, và để duy trì sao chép RDS, họ đặt giới hạn 500 GB cho mỗi bảng và 10 terabyte cho mỗi instance vật lý.
Sau khi xem xét kỹ lưỡng, Notion đã chọn tạo 32 instance cơ sở dữ liệu vật lý, với mỗi instance chứa 15 phân mảnh logic riêng biệt. Điều này dẫn đến tổng cộng 480 phân mảnh trên 32 cơ sở dữ liệu vật lý.
Cơ chế Định tuyến
Cơ chế định tuyến được xác định ở cấp độ ứng dụng để xác định vị trí lưu trữ dữ liệu. Ứng dụng sử dụng phân bổ tải cung cấp các instance nhỏ hơn cho các phân mảnh mới và hy vọng sẽ giảm CPU, IOPS và chi phí.
Kế hoạch Di chuyển
Kế hoạch di chuyển của Notion bao gồm việc thêm 96 mục nhập mới vào PG bouncer, tạm thời phản ánh chúng vào 32 phân mảnh hiện có. Điều này cho phép họ dần dần di chuyển dữ liệu sang các phân mảnh mới khi dữ liệu được ghi vào cơ sở dữ liệu mới.
Tuy nhiên, quá trình thử nghiệm đã phát hiện ra một vấn đề nghiêm trọng: vì mỗi phân mảnh cũ được ánh xạ đến ba phân mảnh mới, họ hoặc là cần giảm số lượng kết nối trên mỗi instance PG bouncer hoặc tăng nó lên gấp 3 lần. Giải pháp là lập biểu đồ cụm PG bouncer của chính họ, tạo ra bốn cụm mới, mỗi cụm quản lý 24 cơ sở dữ liệu. Điều này cho phép họ tăng kết nối trên mỗi PG bouncer cho mỗi phân mảnh lên 8, giới hạn tổng số kết nối trên mỗi instance Postgres lên 200.
Đọc Ẩn và Thử nghiệm
Trước khi triển khai những thay đổi này vào sản xuất, Notion đã triển khai đọc ẩn để thử nghiệm. Họ đã thêm chức năng để lấy dữ liệu từ cả DB cũ và mới khi các yêu cầu được thực hiện, so sánh kết quả về tính nhất quán và khóa bất kỳ sự khác biệt nào để tránh ảnh hưởng đến trải nghiệm của người dùng.
Quá trình Chuyển đổi Khẩn cấp
Quá trình chuyển đổi khẩn cấp bao gồm tạm dừng lưu lượng truy cập, tạm dừng các kết nối mới trong khi cho phép các truy vấn đang diễn ra hoàn thành, kiểm tra sao chép, đảm bảo các cơ sở dữ liệu mới đã được cập nhật đầy đủ và cập nhật cấu hình. Truy cập ứng dụng vào các cơ sở dữ liệu cũ đã bị thu hồi, và PG bouncer đã được cập nhật để trỏ đến các cơ sở dữ liệu mới, đảo ngược hướng sao chép bằng cách truyền phát các thay đổi từ DB mới sang DB cũ trong trường hợp khẩn cấp.
Kết quả
Dự án lập biểu đồ lại là một thành công đáng kể đối với Notion. Kết quả chính bao gồm:
- Năng lực tăng lên
- Hiệu suất được cải thiện
- Việc sử dụng CPU và IOPS giảm mạnh, với việc sử dụng mới ở mức khoảng 20% trong giờ cao điểm, so với mức 90% trước đây.
Kiến trúc mới này định vị Notion để xử lý sự tăng trưởng người dùng và nhu cầu dữ liệu liên tục.
