Freechat Tổ Chức Bảng Vừa Đủ

Câu hỏi nhức nhối!

Gần đây mình nhận được rất nhiều ý kiến đóng góp về việc tạo nhiều bảng để phân tán dữ liệu. Vì mình cũng nhận được rất nhiều câu hỏi kiểu như: Tôi có một bảng khách hàng, khách hàng có một số loại nhất định, vậy bây giờ tôi có nên chia mỗi loại khách hàng ra thành một bảng để tăng hiệu năng không? Vậy bây giờ chúng ta cùng đi phân tích các vấn đề nhé!

Quản lý bảng

Với Freechat là một ứng dụng cần có hàng nghìn người, nếu may mắn sẽ có hàng triệu người dùng vậy nên số lượng tin nhắn cũng có thể lên đến hàng triệu, hàng tỉ tin nhắn, bây giờ nếu chúng ta chia mỗi channel ra thành 1 bảng, vậy thì cũng sẽ có đến hàng triệu, thậm chí hàng tỉ bảng được tạo ra, vậy bây giờ chúng ta sẽ quản lý kiểu gì? Làm sao chúng ta có thể sử dụng các công cụ như MySQL workbench, Mongo Compass để quản lý các bảng được nhỉ? Ngay cả cái việc lấy danh sách các bảng về thôi đã là điểu không thể rồi.

Truy vấn dữ liệu

Sẽ có 2 loại truy vấn cần phải xem xét đó là truy vấn để tìm kiếm dữ liệu và truy vấn để tổng hợp dữ liệu

Tìm kiếm

Nếu bây giờ có một khách hàng gọi điện đến công ty phàn nàn rằng họ không thể gửi được tin nhắn, và chúng ta cần phải tìm ra kênh chat nào khách hàng đang bị lỗi, với trường hợp 1 bảng thì chúng ta có thể truy vấn bằng câu lệnh:

select message where message.sender = 'user'

Vậy bây giờ mỗi kênh chat một bảng thì truy vấn kiểu gì giờ? Gần như đó là điều không thể, trừ khi chúng ta tự viết công cụ truy vấn lấy danh sách các bảng về và foreach nhưng hãy cẩn thận việc foreach như vậy có thể sẽ không thể thực hiện được khi chúng ta có đến hàng tỉ bảng.

Thống kê

Giả sử bây giờ chúng ta cần liệt kê 50 channel có số lượng message nhiều nhất thì sao? Với một bảng chúng ta sẽ chỉ cần một câu lệnh:

select channelId, count(messageId) group by channelId limit 50

Nhưng khi chia ra nhiều bảng thì sao, lại phải đi foreach danh sách các bảng, count số lượng tin nhắn và sắp xếp theo thứ tự, sau đó mới lấy được 50 channel cần tìm. Tất cả công việc này sẽ cần thực hiện ở application server, và lại một lần nữa có thể sẽ không thể thực hiện được khi chúng ta có đến hàng tỉ bảng.

Trong cả 2 trường hợp truy vấn, ngay cả khi số lượng bảng của bạn rất ít, nhưng bạn vẫn phải thực hiện việc lấy danh sách bảng từ database về, sau đó foreach trên đống bảng này. Làm như vậy bạn sẽ không tận dụng được cơ chế đánh index mà database nào cũng hỗ trợ, từ đó mà hiệu năng chương trình của bạn sẽ bị giảm đi rất nhiều. Thêm vào nữa là các thư viện như Spring hay JavaEE sẽ tự động tạo cho mỗi bảng một đối tượng Repository duy nhất, vậy bạn có tự tin là bạn sẽ viết tốt hơn họ phần thư viện truy xuất database?

Đồng bộ dữ liệu

Thông thường, chúng ta sẽ có nhu cầu đồng bộ tin nhắn sang các hệ thống đánh index như elasticsearch để cung cấp các API tìm kiếm tin nhắn, nếu chỉ có một bảng thì mọi chuyện tương đối dễ dàng với câu lệnh:

select message 
where 
    message.updateTime > lastUpdatetime or 
    (message.updateTime == lastSyncUpdateTime and message.id > lastSyncId) 
order by message.updatetime desc, message.id desc

Nhưng bây giờ với hàng triệu, hàng tỉ bảng, chúng ta sẽ cần foreach cả tỉ bảng, đó gần như là điều bất khả thi.

Bảo vệ dữ liệu

Khi chúng ta đã cấp quyền cho một user được phép tạo bảng, nghĩa là user này có quyền rất cao, có thể tạo và xoá bảng, điều gì xảy ra khi dev mắc sai lầm và tạo ra các bảng không liên quan hay xoá nhầm bảng? Khi đó dữ liệu sẽ bị sai lệch hoặc vĩnh viễn mất đi, lúc đó thì ai sẽ là người chịu trách nhiệm và làm thế nào để truy vết được cái gì đã gây ra?

Ai cho bạn tạo bảng?

Việc tạo bảng không phải là một trò đùa, và nó không hề dễ dàng đối với một tổ chức lớn. Để tạo được bảng bạn sẽ cần phải tạo workflow, nêu rõ lý do tạo bảng, vì đã là bảng biểu là liên quan đến dữ liệu, thứ quý giá nhất trong nghành công nghệ thông tin này. Nếu việc tạo bảng diễn ra bừa bãi, đến một ngày bạn dev nào đó uất ức nghỉ việc, bạn ấy sẽ tạo một bảng để ghi dữ liệu nào đó không được phép ghi vào cơ sở dữ liệu thì sao?

Kết luận

Với việc thiết kế cơ sở dữ liệu, hãy thiết kế đủ bảng, không nhiều hơn, không ít hơn để đảm bảo vừa đủ cho nghiệp vụ của bạn. Việc tạo quá nhiều bảng sẽ làm cho bạn mất khả năng quản lý, giảm thiểu khả năng truy vấn và đồng bộ dữ liệu. Thêm vào nữa là nguy cơ dev mắc sai lầm dẫn đến việc mất dữ liệu là hiện hữu. Với có sở dữ liệu, càng ổn định bao nhiêu, càng cẩn thận bao nhiêu thì càng tốt bấy nhiêu. Nếu bạn có nhu cầu scale hệ thống, bạn có thể phân mảnh (sharding) dữ liệu bằng cách sử dụng nhiều server để tổ chức thành một cụm (cluster), từ đó dữ liệu có thể lưu trên nhiều máy khác nhau, đó là ý tưởng hay hơn rất nhiều (mình sẽ có bài viết về vấn đề này nhé).