Sự phát triển cơ sở dữ liệu của Nextdoor: Một nấc thang mở rộng

Nextdoor hoạt động như một dịch vụ mạng xã hội siêu địa phương (hyper-local), kết nối những người hàng xóm dựa trên vị trí địa lý của họ.

Nền tảng này cho phép mọi người chia sẻ tin tức địa phương, đề xuất các doanh nghiệp địa phương và tổ chức các sự kiện trong khu phố. Vì nền tảng dựa trên các tương tác có độ tin cậy cao trong các cộng đồng cụ thể, dữ liệu phải có tính sẵn sàng cao và cực kỳ chính xác.

Tuy nhiên, khi dịch vụ mở rộng ra hàng triệu người dùng trên khắp hàng nghìn khu phố trên toàn cầu, kiến trúc cơ sở dữ liệu cơ bản đã phải tiến hóa từ một thiết lập đơn giản thành một hệ thống phân tán phức tạp.

Hành trình kỹ thuật này tại Nextdoor nêu bật một quy tắc cơ bản trong thiết kế hệ thống.

Mỗi bước cải thiện hiệu suất đều tạo ra một yêu cầu mới về tính toàn vẹn của dữ liệu. Đội ngũ đã tuân theo một tiến trình có thể dự đoán được, chuyển từ một instance cơ sở dữ liệu duy nhất sang một hệ thống phân cấp phức tạp gồm các connection pooler, read replica, cache được đánh số phiên bản và các trình hòa giải (reconciler) chạy nền. Trong bài viết này, chúng ta sẽ xem xét cách đội ngũ kỹ thuật của Nextdoor đã xử lý sự tiến hóa này và những thách thức mà họ phải đối mặt.

Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các chi tiết được chia sẻ công khai từ Đội ngũ Kỹ thuật của Nextdoor. Vui lòng để lại bình luận nếu bạn nhận thấy bất kỳ điểm nào không chính xác.

Giới hạn của "Big Box"

Trong thời kỳ đầu, Nextdoor dựa vào một instance PostgreSQL duy nhất để xử lý mọi bài đăng, bình luận và cập nhật khu phố.

Đối với nhiều nền tảng đang phát triển, đây là điểm khởi đầu hợp lý nhất. Nó đơn giản để quản lý và PostgreSQL cung cấp một công cụ mạnh mẽ có khả năng xử lý khối lượng công việc đáng kể. Tuy nhiên, khi có nhiều hàng xóm tham gia hơn và khối lượng tương tác đồng thời tăng lên, đội ngũ đã gặp phải một bức tường không liên quan đến tổng lượng dữ liệu được lưu trữ, mà liên quan nhiều hơn đến giới hạn kết nối.

PostgreSQL sử dụng mô hình mỗi kết nối một tiến trình (process-per-connection). Nói cách khác, mỗi khi một application worker muốn giao tiếp với cơ sở dữ liệu, máy chủ sẽ tạo ra một tiến trình hoàn toàn mới để xử lý yêu cầu đó. Nếu một ứng dụng có năm nghìn web worker đang cố gắng truy cập cơ sở dữ liệu cùng lúc, máy chủ phải quản lý năm nghìn tiến trình riêng biệt. Mỗi tiến trình tiêu tốn một phần bộ nhớ và chu kỳ CPU chuyên biệt chỉ để duy trì sự tồn tại của nó.

Việc quản lý hàng nghìn tiến trình tạo ra một gánh nặng (overhead) khổng lồ cho hệ điều hành. Cuối cùng, máy chủ dành nhiều thời gian để chuyển đổi giữa các tiến trình này hơn là thực hiện các truy vấn thực tế giúp vận hành luồng tin tức khu vực (neighborhood feed). Đây thường là thời điểm mà việc mở rộng theo chiều dọc (vertical scaling), hay mua một máy chủ lớn hơn với nhiều nhân (core) hơn, bắt đầu cho thấy hiệu quả giảm dần. Gánh nặng từ mô hình “mỗi kết nối một tiến trình” vẫn là một nút thắt cổ chai bất kể bạn có thêm bao nhiêu phần cứng vào hệ thống.

Để giải quyết vấn đề này, Nextdoor đã giới thiệu một lớp middleware có tên là PgBouncer. Đây là một trình quản lý kết nối (connection pooler) nằm giữa ứng dụng và cơ sở dữ liệu. Thay vì mỗi application worker phải duy trì một đường truyền riêng biệt đến cơ sở dữ liệu, tất cả chúng đều giao tiếp với PgBouncer.

• Giai đoạn Yêu cầu (The Request Phase): Một web worker yêu cầu một kết nối từ PgBouncer để thực thi một truy vấn nhanh.

• Giai đoạn Phân bổ (The Assignment Phase): PgBouncer chỉ định một kết nối nhàn rỗi từ pool đã được thiết lập sẵn thay vì bắt buộc cơ sở dữ liệu phải tạo ra một tiến trình mới.

• Giai đoạn Thực thi (The Execution Phase): Truy vấn chạy trên cơ sở dữ liệu bằng cách sử dụng kết nối được chia sẻ đó.

• Giai đoạn Giải phóng (The Release Phase): Worker hoàn thành công việc của mình và kết nối quay trở lại pool ngay lập tức để worker tiếp theo sử dụng.

Điều này cho phép hàng nghìn application worker chia sẻ vài trăm kết nối cơ sở dữ liệu đang "ấm" (warm). Điều này đã loại bỏ hiệu quả nút thắt cổ chai về kết nối và cho phép cơ sở dữ liệu chính tập trung hoàn toàn vào việc xử lý dữ liệu.

Phân chia công việc và vấn đề về "Độ trễ" (Lag)

Sau khi việc quản lý kết nối đã ổn định, nút thắt tiếp theo xuất hiện dưới dạng lưu lượng truy cập đọc (read traffic).

Trong một mạng xã hội như Nextdoor, tỷ lệ người đọc tin tức so với người viết bài bị lệch rất lớn. Cứ mỗi người lưu một cập nhật khu vực mới, thì hàng trăm người khác có thể xem nó. Một máy chủ cơ sở dữ liệu duy nhất phải xử lý cả "Ghi" (Writes) và "Đọc" (Reads) cùng một lúc. Điều này tạo ra sự tranh chấp tài nguyên, nơi các truy vấn đọc nặng có thể làm chậm khả năng lưu dữ liệu mới của hệ thống.

Giải pháp là chuyển sang kiến trúc Primary-Replica. Trong thiết lập này, một máy chủ cơ sở dữ liệu được chỉ định là Primary (Chính). Đây là máy chủ duy nhất được phép sửa đổi hoặc thay đổi dữ liệu. Một số máy chủ khác, được gọi là Read Replicas (Bản sao đọc), duy trì các bản sao dữ liệu từ Primary. Tất cả lưu lượng truy cập "Đọc" từ ứng dụng được chuyển hướng đến các bản sao này, trong khi chỉ có lưu lượng "Ghi" mới được gửi đến Primary.

Xem sơ đồ bên dưới:

Việc phân tách công việc này cho phép mở rộng quy mô đọc theo chiều ngang (horizontal scaling) một cách mạnh mẽ. Tuy nhiên, điều này tạo ra thách thức về Asynchronous Replication (Sao chép bất đồng bộ). Cơ sở dữ liệu Primary sẽ gửi các thay đổi của nó đến các bản sao (replicas) bằng cách sử dụng luồng nhật ký (log stream). Cần một khoảng thời gian để bài đăng mới được lưu trên Primary truyền qua mạng và xuất hiện trên các replica. Độ trễ này được gọi là replication lag (độ trễ sao chép).

Xem sơ đồ dưới đây để thấy sự khác biệt giữa sao chép đồng bộ và bất đồng bộ:

Để giải quyết vấn đề người dùng đăng bài xong rồi thấy nó biến mất khi tải lại trang, Nextdoor sử dụng Time-Based Dynamic Routing (Định tuyến động dựa trên thời gian). Đây là một logic định tuyến thông minh đảm bảo người dùng luôn thấy kết quả từ các hành động của chính họ. Cơ chế hoạt động như sau:

• The Write Marker (Dấu vết ghi): Khi người dùng thực hiện một hành động ghi, chẳng hạn như đăng một bình luận, ứng dụng sẽ ghi lại dấu thời gian chính xác của sự kiện đó.

• The Protected Window (Cửa sổ được bảo vệ): Trong một khoảng thời gian cụ thể sau khi ghi, thường là vài giây, hệ thống sẽ coi người dùng đó là đối tượng nhạy cảm.

• Dynamic Routing (Định tuyến động): Trong khoảng thời gian này, mọi yêu cầu đọc từ người dùng đó sẽ được định tuyến động trực tiếp đến cơ sở dữ liệu Primary thay vì replica.

• The Handover (Chuyển giao): Khi cửa sổ thời gian kết thúc và hệ thống xác nhận rằng các replica đã cập nhật kịp với Primary, lưu lượng truy cập của người dùng sẽ được định tuyến lại về các replica để tiết kiệm tài nguyên.

Điều này đảm bảo rằng trong khi những người dùng khác trong khu vực thấy dữ liệu nhất quán theo thời gian (eventually consistent), thì chính người đã thực hiện thay đổi đó luôn thấy dữ liệu nhất quán mạnh (strongly consistent).

Thư viện Tốc độ cao

Ngay cả khi có nhiều bản sao (replica), việc truy cập vào cơ sở dữ liệu cho mỗi lần tải trang là một hoạt động tốn kém.

Các cơ sở dữ liệu phải đọc dữ liệu từ ổ đĩa hoặc một bộ nhớ đệm lớn và thường thực hiện các lệnh join phức tạp giữa các bảng khác nhau để tập hợp thành một bản ghi duy nhất. Để đạt được tốc độ phản hồi tính bằng mili giây như người dùng mong đợi, Nextdoor đã triển khai một lớp cache sử dụng Valkey. Đây là một kho lưu trữ dữ liệu hiệu suất cao mã nguồn mở, lưu trữ thông tin trong RAM để truy cập gần như tức thời.

Đội ngũ này sử dụng mô hình Look-aside Cache. Khi ứng dụng cần dữ liệu, nó sẽ thực hiện theo một trình tự cụ thể:

• Kiểm tra Cache: Ứng dụng tìm kiếm dữ liệu trong Valkey bằng một khóa (key) duy nhất.

• Cache Hit: Nếu tìm thấy dữ liệu, nó được trả về ngay lập tức cho người dùng mà không cần chạm vào cơ sở dữ liệu.

• Cache Miss: Nếu không có dữ liệu, ứng dụng sẽ truy vấn cơ sở dữ liệu PostgreSQL để tìm thông tin chính xác.

• Bước Nạp dữ liệu: Ứng dụng lấy kết quả từ cơ sở dữ liệu, lưu một bản sao vào Valkey cho các yêu cầu trong tương lai, sau đó trả dữ liệu về cho người dùng.