Kể từ khi viết blog này, chúng tôi đã phát hành một phiên bản mới của PlanetScale. Tìm hiểu thêm về những gì chúng tôi đã xây dựng và dùng thử. Và hãy chắc chắn kiểm tra tài liệu của chúng tôi
Đối với các nhà phát triển xây dựng ứng dụng web, kho dữ liệu giao dịch là sự lựa chọn rõ ràng và đã được chứng minh, nhưng thành công đi kèm với những hạn chế về quy mô. Cơ sở dữ liệu nguyên khối hoạt động tốt ban đầu, nhưng khi một ứng dụng tăng trưởng, kích thước dữ liệu của nó cuối cùng sẽ tăng vượt quá mức tối ưu cho một máy chủ. Nếu ứng dụng có thể tồn tại với dữ liệu nhất quán cuối cùng, thì việc mở rộng lưu lượng đọc có thể được giải quyết tương đối dễ dàng bằng cách thêm nhiều bản sao hơn. Tuy nhiên, việc mở rộng quy mô lưu lượng ghi khó khăn hơn;
Đây không phải là một thách thức mới, các tổ chức đã phải đối mặt với nó trong nhiều năm và một trong những mô hình chính để giải quyết nó là phân mảnh theo chiều ngang. Phân đoạn ngang đề cập đến việc lấy một cơ sở dữ liệu MySQL duy nhất và phân vùng dữ liệu trên một số máy chủ cơ sở dữ liệu, mỗi máy chủ có lược đồ giống hệt nhau. Điều này phân tán khối lượng công việc của một cơ sở dữ liệu nhất định trên nhiều máy chủ cơ sở dữ liệu, có nghĩa là bạn có thể mở rộng quy mô tuyến tính chỉ bằng cách thêm nhiều máy chủ cơ sở dữ liệu hơn nếu cần. Mỗi máy chủ này được gọi là một “shard”. Có nhiều phân đoạn làm giảm lưu lượng đọc và ghi được xử lý bởi một máy chủ cơ sở dữ liệu duy nhất và có thể giữ dữ liệu trên một máy chủ cơ sở dữ liệu ở kích thước tối ưu. Tuy nhiên, hiện tại, vì bạn đang xử lý nhiều máy chủ chứ không phải một máy chủ, điều này làm tăng thêm độ phức tạp cho định tuyến truy vấn và các tác vụ vận hành như sao lưu và khôi phục, di chuyển lược đồ và giám sát
Nhiều công ty đã triển khai phân đoạn ngang ở cấp ứng dụng. Theo cách tiếp cận này, tất cả logic để định tuyến các truy vấn đến đúng máy chủ cơ sở dữ liệu đều nằm trong ứng dụng. Điều này yêu cầu logic bổ sung ở cấp ứng dụng, phải được cập nhật bất cứ khi nào một tính năng mới được thêm vào. Điều đó cũng có nghĩa là các tính năng phân đoạn chéo cần được triển khai trong ứng dụng. Ngoài ra, khi dữ liệu tăng lên và tập hợp các phân đoạn ban đầu hết dung lượng, việc "phân chia lại" hoặc tăng số lượng phân đoạn trong khi tiếp tục phục vụ lưu lượng truy cập trở thành một thách thức khó khăn trong hoạt động
Pinterest đã thực hiện phương pháp này sau khi dùng thử công nghệ NoSQL có sẵn và xác định rằng nó chưa đủ trưởng thành vào thời điểm đó. Marty Weiner, một kỹ sư phần mềm làm việc trong dự án, lưu ý: “Chúng tôi có một số công nghệ NoSQL, tất cả chúng cuối cùng đều bị hỏng một cách thảm khốc. ” Pinterest đã ánh xạ dữ liệu của họ theo khóa chính và sử dụng khóa đó để ánh xạ dữ liệu tới phân đoạn chứa dữ liệu đó. Sharding theo cách này đã cung cấp quy mô, nhưng đánh đổi các liên kết phân đoạn chéo và việc sử dụng khóa ngoại. Tương tự, Etsy đã thực hiện phương pháp này khi chuyển sang hệ thống cơ sở dữ liệu được phân đoạn, nhưng đã thêm khóa chính tra cứu hai chiều vào shard_id và đóng gói các phân đoạn vào máy chủ, tự động hóa một số công việc quản lý phân đoạn. Tuy nhiên, trong cả hai trường hợp, việc quản lý liên tục các phân đoạn, bao gồm cả việc chia nhỏ các phân đoạn sau lần phân chia lại ban đầu, đã đưa ra những thách thức đáng kể
Bên cạnh sharding ở lớp ứng dụng, một cách tiếp cận khác đối với sharding ngang đã xuất hiện. Các kỹ sư tại YouTube bắt đầu xây dựng dự án mã nguồn mở Vitess vào năm 2010. Vitess nằm giữa ứng dụng và cơ sở dữ liệu MySQL, cho phép cơ sở dữ liệu được phân mảnh theo chiều ngang xuất hiện nguyên khối cho ứng dụng. Ngoài việc loại bỏ sự phức tạp của định tuyến truy vấn khỏi ứng dụng, Vitess còn cung cấp các giải pháp dự phòng và chuyển đổi dự phòng tổng thể giúp loại bỏ sự phức tạp trong hoạt động của một hệ thống bị phân mảnh, cũng như các tính năng như tổng hợp kết nối và viết lại truy vấn để cải thiện hiệu suất
Các công ty như Square [đọc về hành trình của họ], Slack, JD. com và nhiều người khác đã sử dụng Vitess để mở rộng cơ sở dữ liệu MySQL của họ. JD. com, một trong những nhà bán lẻ trực tuyến lớn nhất ở Trung Quốc, đã chứng kiến 35 triệu QPS chạy qua Vitess trong thời gian lưu lượng truy cập cao nhất vào Ngày Độc thân. Slack đã di chuyển gần như tất cả cơ sở dữ liệu của họ sang Vitess, sống sót sau dòng lưu lượng truy cập khổng lồ từ quá trình chuyển đổi sang làm việc tại nhà vào đầu năm nay. Cả Etsy và Pinterst đã chuyển một số khối lượng công việc của họ sang Vitess vì những lợi ích quản lý mà Vitess cung cấp. Vitess đã liên tục chứng minh khả năng chạy trong sản xuất với khối lượng công việc cao
Tuy nhiên, việc vận hành Vitess ở quy mô lớn vẫn cần một nhóm kỹ sư và không phải tất cả các tổ chức đều có chuyên môn sâu như Slack và Square. Tại PlanetScale, chúng tôi đã xây dựng cơ sở dữ liệu dưới dạng dịch vụ trên Vitess để bất kỳ ai cũng có thể truy cập cấp độ quy mô này bằng cơ sở dữ liệu MySQL của họ. Với PlanetScaleDB, bạn có thể bắt đầu với quy mô nhỏ với một phiên bản MySQL duy nhất và mở rộng quy mô khi bạn phát triển. Khi đến thời điểm phân đoạn theo chiều ngang, bạn sẽ cần thiết kế sơ đồ phân đoạn, nhưng sau khi bạn đã quyết định cách tổ chức dữ liệu của mình trên các phân đoạn, bạn sẽ có thể phân đoạn cơ sở dữ liệu của mình thông qua giao diện người dùng của chúng tôi mà không phải thực hiện các thay đổi quan trọng đối với . Chỉ với một vài cú nhấp chuột và thời gian cần thiết để sao chép dữ liệu của bạn, bạn có thể di chuyển từ một máy chủ cơ sở dữ liệu đơn lẻ sang cơ sở dữ liệu được phân đoạn với bao nhiêu phân đoạn tùy ý
Hãy xem bản trình diễn video này để xem cơ sở dữ liệu phát triển từ một phân đoạn thành 128 phân đoạn một cách liền mạch, đồng thời phục vụ lưu lượng truy cập