shending cơ sở dữ liệu máy chủ sql - phải làm gì với dữ liệu chung / dữ liệu không phân đoạn

Chúng tôi có một cơ sở dữ liệu cấp doanh nghiệp quy mô rất lớn. Là một phần trong mô hình kinh doanh của chúng tôi, tất cả người dùng web truy cập vào các máy chủ web của chúng tôi cùng một lúc mỗi tháng, điều này sẽ làm hỏng hộp sql của chúng tôi. Lưu lượng truy cập rất nặng và tiếp tục phát triển nặng hơn, công ty càng phát triển. tối ưu hóa sql Proc đã được thực hiện và phần cứng đã được mở rộng đến mức rất cao.

Chúng tôi đang tìm cách bảo vệ cơ sở dữ liệu ngay bây giờ để đảm bảo rằng chúng tôi có thể xử lý sự tăng trưởng của công ty và tải trong tương lai.

Chúng tôi đã quyết định những dữ liệu cụ thể nên được loại bỏ. Nó là một tập hợp con của cơ sở dữ liệu của chúng tôi được sử dụng nhiều.

Tuy nhiên, câu hỏi của tôi liên quan đến dữ liệu không phân đoạn là phổ biến / phổ biến. Ví dụ về dữ liệu như thế này có thể là bảng Inventory chẳng hạn hoặc có thể là bảng Nhân viên, bảng người dùng, v.v.

Tôi thấy hai tùy chọn để xử lý dữ liệu phổ biến / phổ biến này:

1) thiết kế 1 - Đặt dữ liệu chung / phổ biến vào cơ sở dữ liệu bên ngoài. Tất cả các bài viết sẽ xảy ra ở đây. Dữ liệu này sau đó sẽ được sao chép xuống từng phân đoạn cho phép mỗi phân đoạn đọc dữ liệu này và tham gia bên trong vào dữ liệu này trong các procs t-sql.

2) thiết kế 2 - Cung cấp cho mỗi phân đoạn bản sao riêng của tất cả dữ liệu chung / phổ biến. Để mỗi phân đoạn ghi cục bộ vào các bảng này và sử dụng bản sao hợp nhất sql để cập nhật / đồng bộ dữ liệu này trên tất cả các phân đoạn khác.

mối quan tâm về thiết kế # 1

1) Các vấn đề về giao dịch: Nếu bạn gặp phải tình huống phải viết hoặc cập nhật dữ liệu trong phân đoạn và sau đó viết / cập nhật bảng chung / phổ biến trong 1 Proc được lưu trữ, bạn sẽ không còn có thể thực hiện việc này một cách dễ dàng. Bây giờ dữ liệu tồn tại trên các trường hợp và cơ sở dữ liệu sql riêng biệt. Bạn có thể cần liên quan đến MS DTS để xem liệu bạn có thể gói các ghi này vào một giao dịch hay không vì chúng nằm trong một cơ sở dữ liệu riêng biệt. Hiệu suất là một mối quan tâm ở đây và có thể viết lại có thể liên quan đến các procs ghi vào dữ liệu phổ biến và phổ biến.

2) mất tính toàn vẹn tham chiếu. Không thể làm toàn vẹn cơ sở dữ liệu tham chiếu chéo.

3) Mã hóa lại các khu vực rộng lớn của hệ thống để nó biết ghi dữ liệu chung vào cơ sở dữ liệu phổ quát mới nhưng đọc dữ liệu chung từ các phân đoạn.

4). tăng chuyến đi cơ sở dữ liệu. Giống như số 1 ở trên, khi bạn gặp phải tình huống phải cập nhật dữ liệu bị phân tách và dữ liệu chung, bạn sẽ thực hiện nhiều chuyến đi khứ hồi để thực hiện việc này vì dữ liệu hiện nằm trong cơ sở dữ liệu riêng biệt. Một số độ trễ mạng ở đây nhưng tôi không lo lắng về vấn đề này nhiều như 3 trên.

mối quan tâm về thiết kế # 2

Trong thiết kế # 2, mỗi phân đoạn sẽ có phiên bản riêng của tất cả dữ liệu chung / phổ biến. Điều này có nghĩa là tất cả các mã tham gia hoặc cập nhật dữ liệu chung tiếp tục hoạt động / chạy giống như hiện nay. Có rất ít mã hóa / viết lại cần thiết từ nhóm phát triển. Tuy nhiên, thiết kế này hoàn toàn phụ thuộc vào sao chép hợp nhất để giữ dữ liệu đồng bộ trên tất cả các phân đoạn. các dbas có tay nghề cao và rất lo ngại rằng sao chép hợp nhất có thể không thể xử lý việc này và nên hợp nhất sao chép thất bại, sự phục hồi từ thất bại này là không lớn và có thể tác động rất xấu đến chúng tôi.

Tôi tò mò muốn biết nếu có ai đã đi với tùy chọn thiết kế # 2. Tôi cũng tò mò muốn biết liệu tôi đang xem xét tùy chọn thiết kế thứ 3 hay thứ 4 mà tôi không thấy.

cảm ơn bạn trước

Câu hỏi của bạn tập trung vào điều này:

Tuy nhiên, câu hỏi của tôi liên quan đến dữ liệu không phân đoạn là phổ biến / phổ biến. Ví dụ về dữ liệu như thế này có thể là bảng Inventory chẳng hạn hoặc có thể là bảng Nhân viên, bảng người dùng, v.v.

Khi bạn đang thực hiện shending và bạn có dữ liệu mà tất cả các phân đoạn cần xem, bạn phải phân loại dữ liệu đó với một vài thuộc tính:

Nó có thay đổi thường xuyên không? Trong ví dụ của bạn, bạn đã liệt kê Hàng tồn kho, Nhân viên và Người dùng. Thông thường hàng tồn kho thay đổi rất nhanh, nhưng hồ sơ nhân viên chỉ thay đổi theo định kỳ (giả sử, vài trăm cập nhật mỗi ngày).

Mỗi phân đoạn có thể chịu đựng được bao nhiêu độ trễ?Mặc dù khoảng không quảng cáo có thể liên tục thay đổi, nhưng bạn thường có thể chịu được một lượng lớn độ trễ (phút hoặc thậm chí vài giờ) trên một bảng như thế. Nếu bạn đang bán các mặt hàng độc đáo với số lượng rất hạn chế mà bạn không bao giờ có thể giới hạn (nghĩ tác phẩm gốc), thì bạn hoàn toàn không nên bỏ dữ liệu đó - bạn chỉ truy vấn cơ sở dữ liệu gốc. Tuy nhiên, trong hầu hết các cửa hàng trực tuyến, bạn không bán hết hàng mỗi ngày và dù sao bạn cũng sẽ nhanh chóng phục hồi mọi thứ, vì vậy bạn không thực sự cần số lượng hàng tồn kho lên đến một phần nghìn giây. Trong thực tế, trong hầu hết các trường hợp, bạn chỉ cần một cờ Trong kho là 0 hoặc 1 và một quy trình trung tâm cập nhật cờ đó. Bằng cách đó, bạn không cần phải đẩy từng phần lên / xuống của vật phẩm để đếm từng mảnh. Mặt khác, dữ liệu nhân viên hoặc người dùng

Bạn sẽ tham gia từ các bảng phân chia đến các bảng không phân chia? Lý tưởng nhất, câu trả lời ở đây là không - bạn nên thực hiện hai truy vấn riêng biệt để lấy dữ liệu và sau đó tham gia chúng ở phía ứng dụng. Điều này trở nên khó khăn hơn rất nhiều từ góc độ ứng dụng, nhưng nó cung cấp cho bạn khả năng để có được dữ liệu mới nhất từ ​​mỗi nguồn.

Đây là dữ liệu gốc, hoặc sao chép?Một cách khác để nghĩ về câu hỏi này: bạn cần sao lưu những gì, và tần suất như thế nào? Thông thường trong một môi trường bảo vệ khối lượng lớn, bạn muốn các bản sao lưu càng nhanh và càng nhỏ càng tốt. (Rốt cuộc, bạn cần bảo vệ từng nút và bạn muốn tất cả các phân đoạn không thành công với DR tại cùng một thời điểm - không có một số phân đoạn có dữ liệu mới hơn các nút khác.) Điều này có nghĩa là dữ liệu được phân đoạn và không dữ liệu được phân chia phải ở trong các cơ sở dữ liệu hoàn toàn riêng biệt - ngay cả khi chúng nằm trên cùng một máy chủ. Tôi có thể cần sao lưu nhật ký giao dịch liên tục của dữ liệu đã phân tách (bản gốc) của mình, nhưng tôi có thể không cần sao lưu dữ liệu không phân đoạn. Có lẽ tôi dễ dàng hơn khi chỉ cần làm mới bảng Nhân viên hoặc Người dùng của mình từ một nguồn sự thật duy nhất thay vì sao lưu nó trên mỗi phân đoạn. Tuy nhiên, nếu tất cả dữ liệu của tôi nằm trong một cơ sở dữ liệu,

Bây giờ, về mối quan tâm của bạn:

"Các vấn đề giao dịch ... bạn sẽ không còn có thể làm điều này một cách dễ dàng." Chính xác. Trong các kịch bản phân đoạn, ném khái niệm giao dịch ra khỏi cửa sổ. Nó cũng trở nên tồi tệ hơn - đối với dữ liệu được phân đoạn, bạn có thể có một phân đoạn và trực tuyến, và một phân đoạn khác tạm thời do chuyển đổi dự phòng cụm hoặc khởi động lại. Bạn cần lập kế hoạch cho sự thất bại của bất kỳ phần nào của hệ thống, bất cứ lúc nào.

"Không thể thực hiện toàn vẹn cơ sở dữ liệu tham chiếu chéo." Chính xác. Khi bạn chia một bảng duy nhất ra nhiều máy chủ, bạn sẽ đặt chiếc quần bé trai của mình lên và nói với máy chủ cơ sở dữ liệu rằng bạn đang đảm nhận các nhiệm vụ khó khăn như sao lưu tại thời điểm, mối quan hệ giữa các bảng và kết hợp dữ liệu từ nhiều nguồn. Đó là vào bạn và mã của bạn bây giờ.

"Giải mã các khu vực rộng lớn của hệ thống để nó biết ghi dữ liệu chung vào cơ sở dữ liệu phổ quát mới nhưng đọc dữ liệu chung từ các phân đoạn." Đúng ở đây là tốt. Không có nút dễ dàng cho việc này, nhưng một khi bạn đã tích hợp nó vào ứng dụng, bạn có thể mở rộng quy mô như điên. Tôi cho rằng cách dễ dàng hơn để làm điều này là phân chia các kết nối của ứng dụng bằng cách đọc .

"chuyến đi cơ sở dữ liệu tăng lên." - Có, nếu bạn chia dữ liệu thành nhiều máy chủ, ứng dụng sẽ phải tiếp cận với mạng nhiều hơn. Điều quan trọng là cũng triển khai bộ nhớ đệm để một số dữ liệu này có thể được lưu trữ trong các hệ thống không có chi phí thấp hơn, thông lượng cao hơn, không khóa. Truy vấn nhanh nhất là một truy vấn bạn không bao giờ thực hiện.

Tôi cũng đã đưa ra nhiều ưu và nhược điểm để phân chia cơ sở dữ liệu nhiều người thuê ở đây , chẳng hạn như điều chỉnh hiệu suất trên các phân đoạn riêng lẻ, các chiến lược sao lưu / phục hồi khác nhau cho mỗi phân đoạn và các thách thức triển khai lược đồ.

Ở cấp độ cao, cách điển hình để phân đoạn dữ liệu (hoặc phân vùng theo chiều ngang) là phân đoạn các bảng giao dịch và sao chép các bảng cấp chính. Giống như hầu hết các giải pháp công nghệ, điều này tất nhiên giải quyết được một bộ vấn đề và tạo ra một loạt vấn đề hoàn toàn mới ... nhưng bây giờ chúng ta đã quen với điều đó, phải không? ;-)

Tuy nhiên, tôi sẽ hỏi liệu SQLServer có phải là giải pháp tốt nhất cho việc này không. Là khối lượng công việc giống như OLTP hoặc giống như DW / BI hơn?

Chúc mừng, Dave Sisk

Một lựa chọn thứ 3 có thể. Sử dụng shending quan hệ (thay vì shending hộp đen), bạn sẽ có thể phân chia và phân phối toàn bộ cơ sở dữ liệu của bạn. Do được xây dựng theo mô hình dữ liệu quan hệ truyền thống, cơ sở dữ liệu biết dữ liệu nào được lưu trữ trên máy chủ nào và do đó tìm thấy nó ở đâu, vì vậy tất cả dữ liệu của bạn có thể được coi là 'chung / phổ biến'. Hãy xem dbShards như một khả năng để làm cho toàn bộ quá trình shending dễ dàng hơn.