Cách tốt nhất để phân tích các bảng MySQL là không nên làm điều đó trừ khi hoàn toàn không thể tránh khỏi việc làm đó.
Khi bạn đang viết một ứng dụng, bạn thường muốn làm như vậy theo cách tối đa hóa tốc độ, tốc độ của nhà phát triển. Bạn chỉ tối ưu hóa độ trễ (thời gian cho đến khi câu trả lời sẵn sàng) hoặc thông lượng (số câu trả lời trên mỗi đơn vị thời gian) khi cần thiết.
Bạn phân vùng và sau đó chỉ định phân vùng cho các máy chủ khác nhau (=shard) khi tổng của tất cả các phân vùng này không còn phù hợp với một phiên bản máy chủ cơ sở dữ liệu duy nhất - lý do cho việc ghi hoặc đọc.
Trường hợp ghi là a) tần suất ghi đang làm quá tải ổ đĩa máy chủ này vĩnh viễn hoặc b) có quá nhiều lần ghi đang diễn ra khiến quá trình sao chép bị trì hoãn vĩnh viễn trong hệ thống phân cấp sao chép này.
Trường hợp đọc đối với sharding là khi kích thước của dữ liệu quá lớn đến mức tập hợp hoạt động của nó không còn phù hợp với bộ nhớ và các lần đọc dữ liệu bắt đầu đi vào đĩa thay vì được cung cấp từ bộ nhớ trong hầu hết thời gian.
Chỉ khi bạn có để chia nhỏ bạn làm điều đó.
Thời điểm bạn chia nhỏ, bạn đang trả tiền cho điều đó bằng nhiều cách:
Phần lớn SQL của bạn không còn mang tính khai báo nữa.
Thông thường, trong SQL, bạn đang cho cơ sở dữ liệu biết bạn muốn dữ liệu nào và để nó cho trình tối ưu hóa để biến thông số kỹ thuật đó thành một chương trình truy cập dữ liệu. Đó là một điều tốt, bởi vì nó linh hoạt và bởi vì việc viết những chương trình truy cập dữ liệu này là một công việc nhàm chán gây hại cho tốc độ.
Với môi trường phân đoạn, bạn có thể đang tham gia một bảng trên nút A với dữ liệu trên nút B hoặc bạn có một bảng lớn hơn một nút, trên các nút A và B và đang kết hợp dữ liệu từ nó với dữ liệu trên nút B và C. Bạn đang bắt đầu viết các độ phân giải tham gia dựa trên băm phía ứng dụng theo cách thủ công để giải quyết điều đó (hoặc bạn đang phát minh lại cụm MySQL), nghĩa là bạn kết thúc với rất nhiều SQL không còn mang tính khai báo, nhưng đang thể hiện chức năng SQL theo cách thủ tục (ví dụ:bạn đang sử dụng câu lệnh SELECT trong các vòng lặp).
Bạn đang phải chịu nhiều độ trễ mạng.
Thông thường, một truy vấn SQL có thể được giải quyết cục bộ và trình tối ưu hóa biết về chi phí liên quan đến truy cập đĩa cục bộ và giải quyết truy vấn theo cách giảm thiểu chi phí cho việc đó.
Trong môi trường phân đoạn, các truy vấn được giải quyết bằng cách chạy các truy cập khóa-giá trị trên mạng tới nhiều nút (hy vọng với các truy cập khóa theo đợt chứ không phải tra cứu khóa riêng lẻ trên mỗi chuyến khứ hồi) hoặc bằng cách đẩy các phần của WHERE mệnh đề chuyển tiếp đến các nút nơi chúng có thể được áp dụng (được gọi là 'điều kiện đẩy xuống') hoặc cả hai.
Nhưng ngay cả trong những trường hợp tốt nhất, điều này liên quan đến nhiều chuyến đi vòng quanh mạng hơn mà một tình huống cục bộ, và nó phức tạp hơn. Đặc biệt là vì trình tối ưu hóa MySQL không biết gì về độ trễ của mạng (Ok, cụm MySQL đang dần trở nên tốt hơn, nhưng đối với MySQL vani bên ngoài cụm thì điều đó vẫn đúng).
Bạn đang đánh mất rất nhiều sức mạnh biểu đạt của SQL.
Được rồi, điều đó có lẽ ít quan trọng hơn, nhưng các ràng buộc khóa ngoại và các cơ chế SQL khác để toàn vẹn dữ liệu không có khả năng mở rộng nhiều phân đoạn.
MySQL không có API cho phép các truy vấn không đồng bộ theo thứ tự hoạt động.
Khi dữ liệu cùng loại nằm trên nhiều nút (ví dụ:dữ liệu người dùng trên các nút A, B và C), các truy vấn ngang thường cần được giải quyết dựa trên tất cả các nút này ("Tìm tất cả tài khoản người dùng chưa đăng nhập trong 90 ngày Hoặc nhiều hơn"). Thời gian truy cập dữ liệu tăng tuyến tính với số lượng nút, trừ khi có thể yêu cầu nhiều nút song song và kết quả được tổng hợp khi chúng xuất hiện ("Map-Reduce").
Điều kiện tiên quyết cho điều đó là một API giao tiếp không đồng bộ, không tồn tại cho MySQL ở trạng thái hoạt động tốt. Phương pháp thay thế là rất nhiều nhánh và kết nối trong các quy trình trẻ em, đang tham quan thế giới của sự hấp dẫn khi vượt qua mùa giải.
Khi bạn bắt đầu sharding, cấu trúc dữ liệu và cấu trúc liên kết mạng sẽ hiển thị dưới dạng điểm hiệu suất cho ứng dụng của bạn. Để hoạt động tốt một cách hợp lý, ứng dụng của bạn cần phải lưu ý những điều này và điều đó có nghĩa là chỉ có phân cấp ứng dụng thực sự mới có ý nghĩa.
Câu hỏi đặt ra nhiều hơn nếu bạn muốn tự động phân đoạn (xác định hàng đi vào nút nào bằng cách băm các khóa chính chẳng hạn) hoặc nếu bạn muốn phân chia theo chức năng theo cách thủ công ("Các bảng liên quan đến câu chuyện người dùng xyz chuyển đến mục này master, trong khi abc và các bảng liên quan đến def chuyển đến master đó ").
Chức năng sharding có lợi thế là, nếu được thực hiện đúng, hầu hết các nhà phát triển sẽ không nhìn thấy nó vì tất cả các bảng liên quan đến câu chuyện người dùng của họ sẽ có sẵn tại địa phương. Điều đó cho phép họ vẫn được hưởng lợi từ SQL khai báo càng lâu càng tốt và cũng sẽ ít phải chịu độ trễ mạng hơn vì số lần truyền giữa các mạng được giữ ở mức tối thiểu.
Hàm sharding có nhược điểm là nó không cho phép bất kỳ bảng nào lớn hơn một phiên bản và nó đòi hỏi sự chú ý thủ công của người thiết kế.
Chức năng sharding có ưu điểm là nó được thực hiện tương đối dễ dàng với cơ sở mã hiện có với một số thay đổi không quá lớn. http://Booking.com đã thực hiện nó nhiều lần trong những năm qua và nó hoạt động hiệu quả đối với họ.
Đã nói tất cả những điều đó, nhìn vào câu hỏi của bạn, tôi tin rằng bạn đang đặt câu hỏi sai, hoặc tôi hoàn toàn hiểu sai vấn đề của bạn.
