Database Design Mistakes I Made So You Don't Have To \u2014 COD-AI.com

Ba năm trước, tôi đã chứng kiến cơ sở dữ liệu của công ty khởi nghiệp của chúng tôi dừng lại trong một lần ra mắt sản phẩm. Chúng tôi đã có 50,000 người dùng cố gắng đăng ký cùng một lúc, và thời gian phản hồi của chúng tôi phình lên từ 200ms đến 47 giây. Thủ phạm? Một loạt các sai lầm trong thiết kế cơ sở dữ liệu mà tôi đã mắc phải sáu tháng trước khi chúng tôi chỉ có năm người trong một nhà để xe. Đêm hôm đó đã khiến chúng tôi mất 180,000 đô la trong doanh thu và gần như đã tiêu diệt danh tiếng của chúng tôi trước khi chúng tôi thậm chí còn bắt đầu.

Tôi là Marcus Chen, và tôi đã dành 12 năm qua như một kiến trúc sư cơ sở dữ liệu, bảy năm gần đây đặc biệt giúp các công ty SaaS mở rộng từ con số không đến hàng triệu người dùng. Tôi đã thiết kế các hệ thống cho các nền tảng fintech xử lý 2 triệu giao dịch mỗi ngày, các ứng dụng chăm sóc sức khỏe quản lý 15TB dữ liệu bệnh nhân và các trang thương mại điện tử xử lý những đợt lưu lượng cao vào ngày Black Friday. Nhưng giáo dục quý giá nhất của tôi đến từ những sai lầm tôi đã mắc phải sớm trong sự nghiệp—những sai lầm đã dạy tôi nhiều hơn bất kỳ chứng chỉ hay sách giáo khoa nào có thể.

Bài viết này không phải về các thực hành tốt lý thuyết. Nó đề cập đến những sai lầm cụ thể, đau đớn, tốn kém mà tôi đã mắc phải trong các môi trường sản xuất, và những bài học khó khăn mà theo sau. Nếu bạn đang xây dựng bất cứ thứ gì lưu trữ dữ liệu—cho dù đó là một dự án cuối tuần hay một kỳ lân tiếp theo—những bài học này có thể cứu bạn khỏi hàng tháng chỉnh sửa và vô số đêm mất ngủ.

Bẫy Chuẩn hóa: Khi Thiết Kế "Đúng" Trở Thành Cơn Ác Mộng Hiệu Suất

Vừa ra khỏi trường đại học, tôi đã bị ám ảnh bởi việc chuẩn hóa cơ sở dữ liệu. Dạng chuẩn thứ ba không chỉ là một hướng dẫn—nó là giáo lý. Khi tôi gia nhập một công ty khởi nghiệp logistics vào năm 2013, tôi thiết kế hệ thống theo dõi lô hàng của chúng tôi với sự tuân thủ nghiêm ngặt vào các nguyên tắc chuẩn hóa. Mỗi mảnh dữ liệu có bảng riêng, mỗi mối quan hệ được mô hình hóa hoàn hảo, và không có một dấu hiệu nào của sự dư thừa ở đâu cả.

Hệ thống thật sự đẹp về mặt học thuật. Nó cũng cực kỳ chậm.

Để hiển thị chi tiết của một lô hàng duy nhất—điều mà người dùng thực hiện hàng nghìn lần mỗi giờ—cần phải kết hợp 11 bảng. Thời gian truy vấn trung bình của chúng tôi là 3.2 giây. Đối với một trang theo dõi. Người dùng đã rời bỏ trang web trước khi trang này thậm chí còn tải. Giám đốc điều hành của chúng tôi đã gọi tôi vào văn phòng và hỏi một câu hỏi vẫn còn ám ảnh tôi: "Tại sao FedEx tải ngay lập tức nhưng trang của chúng tôi mất nhiều thời gian hơn để thực sự giao hàng?"

Dưới đây là điều tôi đã học được: chuẩn hóa là một công cụ, không phải là một tôn giáo. dạng chuẩn thứ ba được thiết kế để ngăn ngừa các bất thường dữ liệu và giảm chi phí lưu trữ—những mối quan tâm đã có lý khi không gian đĩa tốn 10,000 đô la mỗi gigabyte vào năm 1985. Vào năm 2026, lưu trữ hầu như miễn phí, nhưng thời gian chú ý của người dùng được đo bằng mili giây. Một vài kilobyte dữ liệu dư thừa là một chi phí không đáng kể so với việc mất người dùng vì thời gian tải chậm.

Giải pháp yêu cầu chúng tôi phải phi chuẩn hóa dữ liệu được truy cập nhiều nhất. Chúng tôi đã tạo một bảng shipment_summary chứa thông tin từ nhiều bảng đã được chuẩn hóa. Vâng, điều đó vi phạm dạng chuẩn thứ ba. Vâng, nó yêu cầu logic bổ sung để giữ cho chúng đồng bộ. Nhưng thời gian truy vấn đã giảm từ 3.2 giây xuống 180 mili giây—mức cải thiện 94%. Các chỉ số tương tác người dùng của chúng tôi đã phục hồi trong vòng một tuần.

Bài học không phải là từ bỏ hoàn toàn chuẩn hóa. Nó là để hiểu rằng thiết kế cơ sở dữ liệu liên quan đến các sự đánh đổi. Hãy chuẩn hóa dữ liệu giao dịch của bạn nơi mà tính nhất quán là rất quan trọng. Hãy phi chuẩn hóa dữ liệu nặng đọc nơi mà hiệu suất quan trọng hơn. Trong trường hợp của chúng tôi, chúng tôi giữ cấu trúc chuẩn hóa cho dữ liệu nhập và cập nhật, nhưng duy trì các chế độ xem phi chuẩn hóa cho các truy vấn hướng đến người dùng. Cách tiếp cận kết hợp này đã đem lại cho chúng tôi cả tính toàn vẹn dữ liệu và hiệu suất.

Ngày nay, khi tôi tư vấn cho các công ty khởi nghiệp, tôi thấy cùng một sai lầm lặp đi lặp lại. Các nhà phát triển mới vào nghề, vừa mới tốt nghiệp từ các khóa học về cơ sở dữ liệu, đã chuẩn hóa mọi thứ quá mức. Họ tạo ra các hệ thống lý thuyết hoàn hảo nhưng thực tế không sử dụng được. Quy tắc của tôi: nếu một truy vấn thông thường yêu cầu nhiều hơn ba phép kết hợp, bạn có thể đang chuẩn hóa quá mức cho trường hợp sử dụng đó. Thiết kế theo các mẫu truy cập thực tế của bạn, không phải cho sự tinh khiết lý thuyết.

Thảm Họa UUID: Khi "Thực Hành Tốt Nhất" Phá Hủy Hiệu Suất Của Bạn

Vào năm 2016, tôi đang xây dựng một nền tảng phân tích mạng xã hội. Chúng tôi dự kiến mở rộng toàn cầu, nên tôi đã đưa ra quyết định có vẻ thông minh: sử dụng UUID làm khóa chính thay vì các số nguyên tự động tăng. Mọi bài viết tôi đọc đều khuyến nghị UUID cho các hệ thống phân tán. Chúng toàn cầu duy nhất, ngăn chặn các cuộc tấn công liệt kê và cho phép bạn tạo ID ở phía client. Thì điều gì có thể sai chứ?

"Chuẩn hóa là một công cụ, không phải là một tôn giáo. Đúng ngay khi bạn ưu tiên sự tinh khiết lý thuyết hơn hiệu suất thực tế, bạn đã thất bại trong trận chiến."

Tất cả, đúng như vậy.

Sáu tháng sau khi ra mắt, với 2 triệu người dùng và 500 triệu bản ghi, hiệu suất cơ sở dữ liệu của chúng tôi đang suy giảm một cách bí ẩn. Các truy vấn lẽ ra phải nhanh thì lại mất vài giây. Kích thước cơ sở dữ liệu của chúng tôi đã phình lên đến 340GB—lớn hơn nhiều so với khối lượng dữ liệu mà chúng tôi đã đề xuất. Điều đáng lo ngại hơn, hiệu suất chèn của chúng tôi đã giảm 60% so với những ngày đầu, mặc dù chúng tôi đã nâng cấp lên phần cứng mạnh mẽ hơn.

Vấn đề là sự phân mảnh chỉ mục. UUID là ngẫu nhiên, có nghĩa là mỗi lần chèn đi đến một vị trí ngẫu nhiên trong chỉ mục B-tree. Với các số nguyên tự động tăng, các bản ghi mới được thêm vào cuối chỉ mục—một thao tác nhanh. Với UUID, cơ sở dữ liệu liên tục chia và cân bằng lại các trang chỉ mục, gây ra sự phân mảnh lớn. Các chỉ mục của chúng tôi lớn gấp 3.2 lần so với những gì nó nên có, và mỗi truy vấn đều phải đi qua cấu trúc phình to, bị phân mảnh này.

Tác động hiệu suất là thảm khốc. Chỉ riêng chỉ mục khóa chính đã tiêu tốn 47GB—đối với một bảng mà dữ liệu thực tế chỉ là 12GB. Việc duy trì chỉ mục đã tiêu tốn 40% thời gian CPU của cơ sở dữ liệu của chúng tôi. Tệ hơn nữa, mẫu I/O ngẫu nhiên có nghĩa là chúng tôi không thể hiệu quả sử dụng bộ nhớ cache. Với các ID tuần tự, các bản ghi được chèn gần đây có khả năng được truy cập cùng nhau. Với UUID, mỗi lần truy cập về cơ bản là ngẫu nhiên, phá hủy tỷ lệ trúng cache của chúng tôi.

Cuối cùng, chúng tôi đã chuyển sang một giải pháp kết hợp: ID tuần tự nội bộ, với một cột UUID riêng cho các API bên ngoài. Việc di chuyển này tốn ba tuần lập kế hoạch và thực hiện cẩn thận, trong đó chúng tôi phải duy trì cả hai hệ thống đồng thời. Nó đã khiến chúng tôi tốn khoảng 85,000 đô la cho thời gian kỹ thuật và chi phí cơ sở hạ tầng. Cải thiện hiệu suất là ngay lập tức và đáng kể—hiệu suất chèn tăng 240%, thời gian truy vấn giảm 55%, và kích thước cơ sở dữ liệu của chúng tôi giảm 30% sau khi tái lập chỉ mục.

Bài học ở đây là tinh tế. UUID không thực sự xấu—chúng chỉ đắt đỏ. Nếu bạn thực sự cần tạo ID phân tán hoặc bạn đang xây dựng một hệ thống đa người thuê mà sự dự đoán ID là mối quan tâm bảo mật, UUID có thể xứng đáng với chi phí đó. Nhưng đối với hầu hết các ứng dụng, đặc biệt là trong các giai đoạn đầu, ID tuần tự hiệu quả hơn nhiều. Bạn luôn có thể thêm một cột UUID sau nếu bạn cần các định danh bên ngoài. Bắt đầu với UUID chỉ vì đó là "thực hành tốt nhất" là kỹ thuật tôn thờ hàng hóa mà sẽ...