Tôi yêu công nghệ không máy chủ. Tôi chơi xung quanh và tạo ra rất nhiều ứng dụng không máy chủ khác nhau để thử nghiệm với công nghệ thú vị khác. Trong cụm công nghệ khổng lồ mà tôi sử dụng / thử nghiệm, PlanetScale is cơ sở dữ liệu mà tôi chủ yếu sử dụng cho các dự án phụ cá nhân của mình, vì không có bất kỳ tùy chọn "tốt" nào khác mà Prisma ORM hỗ trợ .

PlanetScale là một nền tảng MySQL serverless chỉ đơn giản là bán Vitess, một hệ thống phân cụm cơ sở dữ liệu để mở rộng quy mô theo chiều ngang của MySQL. Họ không viết cơ sở dữ liệu của riêng mình - có thể đã đóng góp vào nó, nhưng họ đã không viết nó. Từ tài liệu Vitess:

Vitess được tạo vào 2010 để giải quyết các thách thức về khả năng mở rộng MySQL mà nhóm tại YouTube phải đối mặt.

Trong bài viết này, chúng ta sẽ hướng tới việc tìm hiểu cấu trúc của các cơ sở dữ liệu được phân đoạn kế thừa không phải ACID này, tại sao chúng không thể hỗ trợ một thứ quan trọng như tính toàn vẹn tham chiếu và tại sao chúng ta nên tránh sử dụng chúng trong các ứng dụng của mình. Bài viết này nói nhiều hơn về công nghệ của Vitess, mặc dù tôi đã bao gồm PlanetScale trong tiêu đề vì, như tôi đã đề cập ở trên, nó chỉ bán Vitess (với một số công cụ) như một dịch vụ và họ đã đạt được sức hút trong những tháng tiếp theo. cơ sở dữ liệu không máy chủ "đáng tin cậy".

Bối cảnh

Câu hỏi ban đầu của tôi là tại sao nó nói rằng không thể mở rộng cơ sở dữ liệu PlanetScale với tính toàn vẹn tham chiếu như trong tài liệu của họ có ghi rằng:

Cách FOREIGN KEY các ràng buộc được thực hiện trong MySQL (hay nói đúng hơn là trong công cụ lưu trữ InnoDB) can thiệp vào các hoạt động DDL Trực tuyến. Tìm hiểu thêm trong bài đăng trên blog Vitess này.

Giới hạn trong phạm vi máy chủ MySQL duy nhất, FOREIGN KEY không thể duy trì các ràng buộc một khi dữ liệu của bạn phát triển và được phân chia trên nhiều máy chủ cơ sở dữ liệu. Điều này thường xảy ra khi bạn giới thiệu phân vùng chức năng / phân vùng và / hoặc phân vùng theo chiều ngang.

Điều này khiến tôi nghĩ:làm FOREIGN KEY hạn chế ảnh hưởng đến khả năng mở rộng nói chung? và nếu vậy, làm thế nào?

Tôi nghĩ rằng điều quan trọng là phải nhận ra rằng các phép nối bảng SQL khá tốn kém, nhưng theo hiểu biết của tôi thì nó không bị ảnh hưởng nhiều bởi tính toàn vẹn tham chiếu? Bây giờ, nếu chúng ta đang làm điều gì đó như phân tích dữ liệu, rõ ràng là chúng ta không cần tính toàn vẹn tham chiếu vì chúng ta chỉ muốn dồn dữ liệu của mình vào một bảng duy nhất, nhưng PlanetScale và Vitess tự hào về việc được sử dụng bởi các ứng dụng web lớn chẳng hạn như YouTube.

Điều này khiến tôi bối rối không biết tại sao họ lại đánh rơi FOREIGN KEY hạn chế vì các cơ sở dữ liệu như CockroachDB và Spanner vẫn duy trì tính toàn vẹn tham chiếu cùng với khả năng mở rộng.

Toàn vẹn tham chiếu là gì và tại sao nó lại quan trọng?

Hãy bắt đầu với những điều cơ bản, trong trường hợp bạn là người mới. Tôi đoán hầu hết mọi người đọc bài đăng này đều có ý tưởng công bằng về những gì họ đang nói, nhưng tôi sẽ giải thích như một hình thức. Nói một cách dễ hiểu, FOREIGN KEY ràng buộc là một khóa cơ sở dữ liệu mà chúng ta có thể sử dụng để tạo quan hệ giữa hai bảng khác nhau bằng cách tham chiếu đến một cột hoặc một tập hợp các cột. Tính toàn vẹn tham chiếu chỉ đơn giản là đề cập đến trạng thái của cơ sở dữ liệu trong đó tất cả các giá trị của tất cả các khóa đều hợp lệ.

Tại sao nó lại quan trọng?

Bây giờ chúng ta đã có một chút ý tưởng về chúng là gì, hãy chuyển sang phần thứ hai:tại sao chúng lại quan trọng?

Tính toàn vẹn của tham chiếu rất quan trọng vì nó giúp bạn không đưa các lỗi mới vào cơ sở dữ liệu của mình. Đây là một tính năng thường được cung cấp bởi cơ sở dữ liệu quan hệ ngăn người dùng hoặc ứng dụng nhập dữ liệu không nhất quán vào cơ sở dữ liệu. Điều này dẫn đến chất lượng dữ liệu được cải thiện, phát triển nhanh hơn, ít lỗi hơn và nhất quán trên ứng dụng của bạn.

Tại sao Vitess không có?

Vì vậy, để hiểu tại sao Vitess không thể hỗ trợ tính toàn vẹn tham chiếu, chúng ta phải đi sâu vào kiến trúc của cơ sở dữ liệu. Vitess là một cơ sở dữ liệu SQL không phải ACID được phân đoạn, không phải là một cơ sở dữ liệu SQL ACID phân tán thực sự.

Bây giờ, bạn phải tự hỏi những điều khoản đó là gì. Hãy để tôi chia nhỏ chúng cho bạn:ACID là từ viết tắt của Tính nguyên tử, Tính nhất quán, Tính cô lập và Độ bền.

Ở đây, tính nguyên tử đề cập đến một hành động hoàn thành hoặc thất bại hoàn toàn - không hoàn thành một phần giao dịch. Tính nhất quán đề cập đến giao dịch rời khỏi cơ sở dữ liệu ở trạng thái hợp lệ. Cô lập đơn giản có nghĩa là hai giao dịch được thực hiện mà không có bất kỳ sự can thiệp nào với nhau và độ bền có nghĩa là các thay đổi của giao dịch được lưu lại.

Phân đoạn là một phân vùng dữ liệu nằm ngang trong cơ sở dữ liệu và mỗi phân đoạn được giữ trên một phiên bản máy chủ cơ sở dữ liệu riêng biệt để phân chia tải. Vì vậy, khi chúng ta đề cập đến một cơ sở dữ liệu được chia nhỏ, chúng ta đang nói về một cái gì đó như thế này. Như tôi đã nói trước đó, Vitess là một cơ sở dữ liệu SQL không có ACID, về cơ bản có nghĩa là nó KHÔNG đảm bảo các thuộc tính ACID của các giao dịch.

Tại sao lại bỏ nó?

Chà, vấn đề bắt đầu khi bạn có một cơ sở dữ liệu MySQL với một lược đồ được xác định rõ ràng và dịch vụ của bạn trở nên phổ biến với vấn đề quá nhiều lần đọc đánh vào cơ sở dữ liệu. Điều mà hầu hết mọi người làm ở đây là họ bắt đầu lưu vào bộ nhớ đệm các truy vấn được thực thi thường xuyên, nhưng các lần đọc không còn ACIDic nữa.

Cùng với việc đọc quá nhiều, việc ghi quá nhiều vào cơ sở dữ liệu của bạn là một vấn đề nghiêm trọng mà nhiều người có thể gặp phải. Giả sử chúng tôi đã sẵn sàng đốt cháy túi tiền của mình - chúng tôi có thể mở rộng quy mô theo chiều dọc, bổ sung thêm RAM, bộ xử lý 16 lõi và vô số ổ cứng thể rắn thực sự nhanh.

Tất nhiên, chúng tôi vẫn gặp vấn đề về các phép nối bảng SQL ngày càng phức tạp, vì vậy bạn hãy bắt đầu chuẩn hóa lại để tránh các phép nối giữa các bảng.

Tôi đã nói chuyện tại Prisma Meetup một thời gian trước, nơi tôi giải thích các nguyên tắc cơ bản của việc thiết kế một cơ sở dữ liệu quan hệ. Một chủ đề mà tôi đề cập ở đây là không chuẩn hóa, nếu bạn quan tâm, hãy chắc chắn kiểm tra điều này.

Nhưng bất chuẩn hóa về cơ bản là quá trình bạn thêm dữ liệu dư thừa vào các bảng trong cơ sở dữ liệu của mình, điều này giúp cải thiện hiệu suất với chi phí dung lượng ổ đĩa khi bạn không còn sử dụng sức mạnh CPU cho các phép nối. Trong khi quá trình tiêu chuẩn hóa cải thiện tốc độ đọc, điều quan trọng là phải nhận ra rằng nó làm cho việc ghi chậm hơn.

Tuy nhiên, bất chấp tất cả những điều này, cơ sở dữ liệu của chúng tôi vẫn còn chậm, vì vậy chúng tôi chuyển các tính toán cơ sở dữ liệu sang máy khách, chẳng hạn như tạo UUID hoặc ấn định ngày.

Ngay cả sau tất cả những điều này, các truy vấn vẫn sẽ chậm - vì vậy chúng tôi giữ kết quả của dữ liệu được truy vấn nhiều nhất luôn sẵn sàng trong một quá trình được gọi là cơ sở dữ liệu hóa cơ sở dữ liệu. Bây giờ đọc có thể nhanh hơn, nhưng viết ngày càng chậm hơn. Tình huống hợp lý duy nhất bây giờ là giảm các chỉ mục phụ.

Vì vậy, tại thời điểm này, cơ sở dữ liệu của chúng tôi có

Không có thuộc tính ACID do bộ nhớ đệm
Không có giản đồ chuẩn hóa
Không có trình kích hoạt
Không tính toán cơ sở dữ liệu
Không có chỉ mục phụ

Điều này đã mở đường cho cơ sở dữ liệu Vitess và NoSQL, vì các công ty đang gặp vấn đề với việc mở rộng cơ sở dữ liệu của họ. Theo cách mà nó được thiết kế, họ không thể duy trì tính nhất quán của dữ liệu, một thuộc tính ACID, khi các giao dịch kéo dài một số phân đoạn khác nhau. Tính toàn vẹn tham chiếu là tất cả về tính nhất quán khi dữ liệu trải dài trên nhiều phân đoạn, do đó, có nghĩa là chúng không thể hỗ trợ tốt.

Chúng ta có thể đi sâu vào cấu trúc của cơ sở dữ liệu NoSQL không có FOREIGN KEY hạn chế và các vấn đề mà chúng ta sẽ gặp phải khi áp dụng mô hình đó, nhưng đó là chủ đề cho một bài đăng khác.

Nó không chỉ là Vitess, nó là một thực hành tiêu chuẩn cho cơ sở dữ liệu phân đoạn để tránh tính toàn vẹn tham chiếu vì đơn giản là không có sự lựa chọn nào khác. Về mô hình ACID, tài liệu của họ nói rằng họ đảm bảo tính nguyên tử nhưng không cô lập, và thậm chí còn đi xa hơn khi nói:

Đảm bảo Cách ly ACID rất dễ gây tranh cãi và có chi phí cao. Việc cung cấp nó theo mặc định sẽ khiến Vitess không thực tế đối với các trường hợp sử dụng phổ biến nhất.

Hãy nói ngắn gọn về ACID Isolation là gì. Có bốn cấp độ đối với nó (theo tiêu chuẩn SQL-92), bao gồm khả năng tuần tự hóa, đọc cam kết, đọc không cam kết và đọc lặp lại. Như đã nói, có nhiều mức độ cô lập hơn, chẳng hạn như cách ly Snapshot không phải là tiêu chuẩn SQL mặc dù được sử dụng bởi một số cơ sở dữ liệu như Firebase hoặc MongoDB. Nếu bạn quan tâm hơn nữa đến điều này, tôi khuyên bạn nên đọc bài đăng này. Để giữ cho nó ngắn gọn, tôi sẽ không đi qua mọi cấp độ cô lập có / nghĩa là gì, nhưng nếu bạn muốn đọc thêm về điều đó, hãy xem trang này từ Tài liệu MySQL.

Cách ly ACID đề cập đến các giao dịch cơ sở dữ liệu là ACIDic, điều này quan trọng vì chúng đảm bảo rằng các hoạt động hoạt động theo cách mà các nhà phát triển mong đợi. Tôi không chắc về ý của họ khi họ nói "Đảm bảo Cách ly ACID là rất dễ gây tranh cãi và có chi phí cao", nhưng nếu họ muốn nói rằng Bảo đảm Cách ly ACID có chi phí cao đối với bất kỳ sản phẩm nào , họ sai. Một số cơ sở dữ liệu phân tán tuân thủ ACID có mức độ cô lập cao nhất (các giao dịch có thể tuần tự hóa) trong khi vẫn hoạt động tốt với tốc độ đọc / ghi nhanh. Tuy nhiên, trong ngữ cảnh của Vitess, chúng không sai vì các giao dịch trên nhiều phân đoạn không thể đáp ứng bất kỳ mức độ cô lập nào.

Kết luận

Với tất cả những điều này, bạn phải tự hỏi:tại sao mọi người lại muốn sử dụng PlanetScale hoặc Vitess? Chà, tôi cũng tự hỏi như vậy. Với nhiều công ty và trang web, lý do là họ đã chọn Vitess trở lại khi không có bất kỳ lựa chọn nào tốt hơn. Nếu bạn đi đến phần đầu của bài viết, hãy chú ý cách nó được tạo ra vào năm 2010. Bây giờ chúng ta có thể tận hưởng cơ sở dữ liệu có thể mở rộng tuân thủ ACID với tính toàn vẹn tham chiếu, chúng tôi sẽ có lợi nhất khi chuyển sang các cơ sở dữ liệu mới này, và tôi đã bắt đầu làm như vậy rồi! Công nghệ thay đổi nhanh chóng và giữ cho cơ sở dữ liệu của bạn luôn cập nhật tốc độ là một thành phần quan trọng của bất kỳ ứng dụng nào.