Tại sao RDBM không thể phân cụm theo cách NoQuery làm?


88

Một trong những kìm lớn cho DBMS nosql là chúng có thể phân cụm dễ dàng hơn. Giả sử với NoQuery, bạn có thể tạo ra hàng trăm máy giá rẻ lưu trữ các mẩu dữ liệu khác nhau và truy vấn tất cả cùng một lúc.

Câu hỏi của tôi là, tại sao DBMS quan hệ không thể làm điều này như máy chủ mysql hoặc sql? Có phải các nhà cung cấp đã không tìm ra một cách kỹ thuật để làm điều này với sản phẩm hiện có của họ, hoặc có một số vấn đề với mô hình quan hệ ngăn chặn điều này là khả thi? Điều gì tuyệt vời về cách lưu trữ và truy cập dữ liệu của NoQuery (khóa / giá trị, tài liệu, v.v.) giúp cho việc phân cụm dễ dàng hơn, nếu điều này hoàn toàn đúng?


8
Lưu trữ các bit dữ liệu khác nhau trên các máy khác nhau (shending) về mặt kỹ thuật cực kỳ dễ dàng, so với một cái gì đó như Oracle RAC có thể chạy trên 63 nút, mỗi nút trình bày cùng một cơ sở dữ liệu, tất cả đều tuân thủ ACID, v.v. không có ACID, họ sử dụng API độc quyền của riêng họ và chúng tương đối đơn giản.
Phil

6
+ RAC vẫn là một kiến ​​trúc đĩa chia sẻ. Nó vẫn yêu cầu một công tắc SAN trung tâm để bất kỳ nút DBMS nào cũng có thể thấy bất kỳ bộ lưu trữ nào. Tuy nhiên, bạn có thể có nhiều bộ điều khiển SAN biến nó thành kiến ​​trúc M: M. Teradata là một kiến ​​trúc không chia sẻ nhưng nó được tối ưu hóa cho các ứng dụng kho dữ liệu và bạn vẫn có thể sao chép các phần của cơ sở dữ liệu (ví dụ: bảng thứ nguyên) trên tất cả các nút. Netezza thậm chí còn ít hữu ích hơn. Bạn phải tải riêng các phân đoạn của một bảng được phân đoạn.
Mối quan

1
Vì vậy, tôi đã đọc và hiểu (hầu hết) trả lời liên quan dưới đây. Vấn đề dường như có nhiều hơn để làm với ACID sau đó là với mô hình quan hệ. Có giải pháp nào sử dụng mô hình quan hệ, ngay cả khi chúng không tuân thủ hoàn toàn axit, giống như cách NoQuery không? Nó có vẻ như NoSQL thực sự nên được đặt tên NoACID vì nó không có gì để làm với sql hoặc mô hình quan hệ, và tất cả mọi thứ để làm với tính nhất quán, số nguyên tử, truy cập dữ liệu và các địa điểm lưu trữ, vv
fregas

6
@fregas - NoQuery không có bất kỳ định nghĩa chính thức nào. Nó chỉ là một từ thông dụng được áp dụng cho các hệ thống quản lý cơ sở dữ liệu khác nhau. Sao chép đại biểu (tính nhất quán cuối cùng của AKA) được sử dụng bởi nhiều hệ thống như vậy (mặc dù không có nghĩa là tất cả) như là một tối ưu hóa hiệu suất. Tôi không biết về bất kỳ sản phẩm RDBMS nào sử dụng sao chép đại biểu - chắc chắn không có sản phẩm chính nào làm được. Không có lý do lý thuyết tại sao nó không thể được thực hiện, nhưng nó sẽ khá phức tạp và có giá trị đáng ngờ với mức độ khả năng mở rộng có thể đạt được bởi các hệ thống đĩa chia sẻ.
Mối quan tâmOfTunbridgeWells

@ConcernedOfTunbridgeWells Quorum Sao chép không phù hợp với ACID mặc dù đó là lý do tại sao nó sẽ không được thực hiện.
Chris Travers

Câu trả lời:


141

Hệ thống cơ sở dữ liệu phân tán 101

Hoặc, Cơ sở dữ liệu phân tán - FK thực sự ' quy mô web ' nghĩa là gì?

Hệ thống cơ sở dữ liệu phân tán là các sinh vật phức tạp và có nhiều hương vị khác nhau. Nếu tôi tìm hiểu sâu về các nghiên cứu được nhớ đến lờ mờ của mình về vấn đề này tại trường đại học, tôi sẽ cố gắng giải thích một số vấn đề kỹ thuật chính để xây dựng một hệ thống cơ sở dữ liệu phân tán.

Đầu tiên, một số thuật ngữ

Các thuộc tính ACID (Nguyên tử, Tính nhất quán, Cách ly và Độ bền): Đây là các bất biến chính phải được thực thi để giao dịch được thực hiện một cách đáng tin cậy mà không gây ra tác dụng phụ không mong muốn.

Nguyên tử yêu cầu giao dịch hoàn thành hoặc hoàn nguyên. Các giao dịch đã hoàn thành một phần sẽ không bao giờ được nhìn thấy và hệ thống phải được xây dựng theo cách ngăn chặn điều này xảy ra.

Tính nhất quán đòi hỏi một giao dịch không bao giờ được vi phạm bất kỳ bất biến nào (chẳng hạn như tính toàn vẹn tham chiếu khai báo) được đảm bảo bởi lược đồ cơ sở dữ liệu. Ví dụ: nếu khóa ngoại tồn tại, không thể chèn bản ghi con với sự tôn trọng đối với cha mẹ không tồn tại.

Cô lập yêu cầu các giao dịch không nên can thiệp lẫn nhau. Hệ thống sẽ đảm bảo kết quả tương tự nếu các giao dịch được thực hiện song song hoặc tuần tự. Trong thực tế, hầu hết các sản phẩm RDBMS cho phép các chế độ đánh đổi sự cô lập với hiệu suất.

Độ bền đòi hỏi rằng một khi đã cam kết, giao dịch vẫn được lưu trữ liên tục theo cách mạnh mẽ đối với lỗi phần cứng hoặc phần mềm.

Tôi sẽ giải thích một số trở ngại kỹ thuật mà các yêu cầu này có trên các hệ thống phân tán bên dưới.

Kiến trúc đĩa chia sẻ: Một kiến ​​trúc trong đó tất cả các nút xử lý trong một cụm có quyền truy cập vào tất cả các bộ lưu trữ. Điều này có thể trình bày một nút cổ chai trung tâm để truy cập dữ liệu. Một ví dụ về hệ thống chia sẻ đĩa là Oracle RAC hoặc Exadata .

Kiến trúc không chia sẻ: Một kiến ​​trúc trong đó các nút xử lý trong một cụm có lưu trữ cục bộ không thể nhìn thấy đối với các nút cụm khác. Ví dụ về các hệ thống không chia sẻ là Teradata Netezza .

Kiến trúc bộ nhớ dùng chung: Một kiến ​​trúc trong đó nhiều CPU (hoặc nút) có thể truy cập vào nhóm bộ nhớ dùng chung. Hầu hết các máy chủ hiện đại thuộc loại bộ nhớ dùng chung. Bộ nhớ dùng chung tạo điều kiện cho các hoạt động nhất định như bộ nhớ cache hoặc nguyên thủy đồng bộ hóa nguyên tử khó thực hiện hơn trên các hệ thống phân tán.

Đồng bộ hóa: Một thuật ngữ chung mô tả các phương pháp khác nhau để đảm bảo quyền truy cập nhất quán vào tài nguyên được chia sẻ bởi nhiều quy trình hoặc luồng. Điều này khó thực hiện hơn trên các hệ thống phân tán so với các hệ thống bộ nhớ dùng chung, mặc dù một số kiến ​​trúc mạng (ví dụ BYNET của Teradata) có các nguyên tắc đồng bộ hóa trong giao thức mạng. Đồng bộ hóa cũng có thể đi kèm với một lượng chi phí đáng kể.

Semi-Join: Một nguyên thủy được sử dụng trong việc nối dữ liệu được giữ trong hai nút khác nhau của một hệ thống phân tán. Về cơ bản, nó bao gồm đủ thông tin về các hàng để tham gia được gói lại và được truyền bởi một nút khác để giải quyết liên kết. Trên một truy vấn lớn, điều này có thể liên quan đến lưu lượng mạng đáng kể.

Tính nhất quán cuối cùng: Thuật ngữ được sử dụng để mô tả ngữ nghĩa giao dịch nhằm đánh đổi cập nhật tức thời (tính nhất quán về số lần đọc) trên tất cả các nút của hệ thống phân tán để thực hiện (và do đó thông lượng giao dịch cao hơn) trên ghi. Tính nhất quán cuối cùng là tác dụng phụ của việc sử dụng Bản sao đại biểu như một tối ưu hóa hiệu suất để tăng tốc độ cam kết giao dịch trong cơ sở dữ liệu phân tán, nơi nhiều bản sao dữ liệu được giữ trên các nút riêng biệt.

Thuật toán của Lamport: Một thuật toán để thực hiện loại trừ lẫn nhau (đồng bộ hóa) trên các hệ thống không có bộ nhớ dùng chung. Thông thường loại trừ lẫn nhau trong một hệ thống đòi hỏi một nguyên tắc đọc so sánh-ghi hoặc hướng dẫn tương tự của một loại thường chỉ thực tế trên một hệ thống bộ nhớ dùng chung. Các thuật toán đồng bộ hóa phân tán khác tồn tại, nhưng Lamport là một trong những thuật toán đầu tiên và được biết đến nhiều nhất. Giống như hầu hết các cơ chế đồng bộ hóa phân tán, thuật toán của Lamport phụ thuộc rất nhiều vào các nút cụm đồng bộ hóa thời gian và đồng bộ hóa chính xác.

Cam kết hai pha (2PC): Một nhóm các giao thức đảm bảo rằng các cập nhật cơ sở dữ liệu liên quan đến nhiều hệ thống vật lý cam kết hoặc khôi phục một cách nhất quán. Cho dù 2PC được sử dụng trong một hệ thống hay trên nhiều hệ thống thông qua trình quản lý giao dịch, nó sẽ mang một chi phí đáng kể.

Trong giao thức cam kết hai pha, người quản lý giao dịch yêu cầu các nút tham gia tiếp tục duy trì giao dịch theo cách mà họ có thể đảm bảo rằng nó sẽ cam kết, sau đó báo hiệu trạng thái này. Khi tất cả các nút đã trả về trạng thái 'hạnh phúc', nó sẽ báo hiệu cho các nút cam kết. Giao dịch vẫn được coi là mở cho đến khi tất cả các nút gửi trả lời cho biết cam kết đã hoàn tất. Nếu một nút bị hỏng trước khi báo hiệu cam kết hoàn tất, trình quản lý giao dịch sẽ truy vấn lại nút đó khi nó quay trở lại cho đến khi nhận được phản hồi tích cực cho biết giao dịch đã được thực hiện.

Kiểm soát đồng thời nhiều phiên bản (MVCC): Quản lý sự tranh chấp bằng cách viết các phiên bản mới của dữ liệu đến một vị trí khác và cho phép các giao dịch khác xem phiên bản cũ của dữ liệu cho đến khi phiên bản mới được cam kết. Điều này làm giảm sự tranh chấp cơ sở dữ liệu với chi phí của một số lưu lượng ghi bổ sung để viết phiên bản mới và sau đó đánh dấu phiên bản cũ là lỗi thời.

Thuật toán bầu cử: Các hệ thống phân tán liên quan đến nhiều nút vốn đã kém tin cậy hơn một hệ thống đơn lẻ vì có nhiều chế độ thất bại hơn. Trong nhiều trường hợp, một số cơ chế là cần thiết cho các hệ thống phân cụm để đối phó với sự thất bại của một nút. Các thuật toán bầu cử là một lớp các thuật toán được sử dụng để chọn một nhà lãnh đạo để phối hợp tính toán phân tán trong các tình huống trong đó nút 'nhà lãnh đạo' không được xác định hoặc tin cậy 100%.

Phân vùng ngang: Một bảng có thể được phân chia trên nhiều nút hoặc khối lượng lưu trữ bằng khóa của nó. Điều này cho phép một khối lượng dữ liệu lớn được chia thành các phần nhỏ hơn và được phân phối trên các nút lưu trữ.

Shending: Một tập dữ liệu có thể được phân vùng theo chiều ngang trên nhiều nút vật lý trong kiến ​​trúc không chia sẻ. Trường hợp phân vùng này không trong suốt (tức là máy khách phải nhận thức được sơ đồ phân vùng và tìm ra nút nào để truy vấn rõ ràng) điều này được gọi là shending. Một số hệ thống (ví dụ Teradata) thực hiện phân chia dữ liệu giữa các nút nhưng vị trí trong suốt đối với máy khách; thuật ngữ này thường không được sử dụng cùng với loại hệ thống này.

Băm nhất quán: Một thuật toán được sử dụng để phân bổ dữ liệu cho các phân vùng dựa trên khóa. Nó được đặc trưng bởi sự phân phối đồng đều của các khóa băm và khả năng co giãn hoặc giảm số lượng xô một cách hiệu quả. Các thuộc tính này làm cho nó hữu ích cho việc phân vùng dữ liệu hoặc tải trên một cụm các nút trong đó kích thước có thể thay đổi linh hoạt với các nút được thêm hoặc thả khỏi cụm (có thể do lỗi).

Tái tạo đa chủ: Một kỹ thuật cho phép ghi trên nhiều nút trong một cụm được sao chép sang các nút khác. Kỹ thuật này tạo điều kiện mở rộng quy mô bằng cách cho phép một số bảng được phân vùng hoặc phân chia trên các máy chủ và các bảng khác được đồng bộ hóa trên toàn cụm. Các bài viết phải được sao chép cho tất cả các nút chứ không phải là một đại biểu, vì vậy các cam kết giao dịch sẽ tốn kém hơn trên một kiến ​​trúc được sao chép đa chủ so với trên một hệ thống sao chép đại biểu.

Công tắc không chặn: Công tắc mạng sử dụng song song phần cứng bên trong để đạt được thông lượng tỷ lệ thuận với số lượng cổng không có tắc nghẽn bên trong. Việc triển khai ngây thơ có thể sử dụng cơ chế thanh ngang, nhưng điều này có độ phức tạp O (N ^ 2) cho các cổng N, giới hạn nó ở các công tắc nhỏ hơn. Các công tắc lớn hơn có thể sử dụng nhiều cấu trúc liên kết nội bộ phức tạp hơn gọi là công tắc kéo dài tối thiểu không chặn để đạt được tỷ lệ thông lượng tuyến tính mà không cần phần cứng O (N ^ 2).

Tạo một DBMS phân tán - nó có thể khó đến mức nào?

Một số thách thức kỹ thuật làm cho điều này khá khó thực hiện trong thực tế. Ngoài sự phức tạp thêm vào của việc xây dựng một hệ thống phân tán, kiến ​​trúc sư của một DBMS phân tán phải khắc phục một số vấn đề kỹ thuật khó khăn.

Tính nguyên tử trên các hệ thống phân tán: Nếu dữ liệu được cập nhật bởi một giao dịch được trải rộng trên nhiều nút, thì cam kết / khôi phục của các nút phải được phối hợp. Điều này thêm một chi phí đáng kể trên các hệ thống không chia sẻ. Trên các hệ thống đĩa chia sẻ, đây không phải là vấn đề vì tất cả các nút lưu trữ có thể được nhìn thấy bởi tất cả các nút để một nút có thể phối hợp cam kết.

Tính nhất quán trên các hệ thống phân tán: Để lấy ví dụ về khóa ngoại được trích dẫn ở trên, hệ thống phải có khả năng đánh giá trạng thái nhất quán. Ví dụ: nếu cha mẹ và con của mối quan hệ khóa ngoài có thể cư trú trên các nút khác nhau, một số cơ chế khóa phân tán là cần thiết để đảm bảo rằng thông tin lỗi thời không được sử dụng để xác thực giao dịch. Nếu điều này không được thi hành, bạn có thể có (ví dụ) một điều kiện chủng tộc trong đó cha mẹ bị xóa sau khi sự hiện diện của nó được xác minh trước khi cho phép chèn con.

Việc thực thi các ràng buộc bị trì hoãn (nghĩa là chờ đợi cho đến khi cam kết xác nhận DRI) yêu cầu khóa phải được giữ trong suốt thời gian giao dịch. Loại khóa phân tán này đi kèm với một chi phí đáng kể.

Nếu nhiều bản sao dữ liệu được giữ (điều này có thể cần thiết trên các hệ thống không chia sẻ để tránh lưu lượng mạng không cần thiết từ bán kết nối) thì tất cả các bản sao của dữ liệu phải được cập nhật.

Cách ly trên các hệ thống phân tán: Trường hợp dữ liệu bị ảnh hưởng trên một giao dịch nằm trên nhiều nút hệ thống, các khóa và phiên bản (nếu MVCC đang được sử dụng) phải được đồng bộ hóa qua các nút. Đảm bảo tính tuần tự hóa của các hoạt động, đặc biệt là các kiến ​​trúc không chia sẻ, nơi các bản sao dữ liệu dư thừa có thể được lưu trữ đòi hỏi một cơ chế đồng bộ hóa phân tán như Thuật toán của Lamport, cũng đi kèm với lưu lượng truy cập mạng đáng kể.

Độ bền trên các hệ thống phân tán: Trên hệ thống đĩa dùng chung, vấn đề về độ bền về cơ bản giống như hệ thống bộ nhớ dùng chung, ngoại trừ các giao thức đồng bộ hóa phân tán vẫn được yêu cầu trên các nút. DBMS phải ghi nhật ký vào nhật ký và ghi dữ liệu ra một cách nhất quán. Trên hệ thống không chia sẻ, có thể có nhiều bản sao dữ liệu hoặc các phần của dữ liệu được lưu trữ trên các nút khác nhau. Một giao thức cam kết hai pha là cần thiết để đảm bảo rằng cam kết xảy ra chính xác trên các nút. Điều này cũng phát sinh chi phí đáng kể.

Trên hệ thống không chia sẻ, việc mất nút có thể có nghĩa là dữ liệu không có sẵn cho hệ thống. Để giảm thiểu dữ liệu này có thể được sao chép qua nhiều nút. Tính nhất quán trong tình huống này có nghĩa là dữ liệu phải được sao chép vào tất cả các nút nơi thường trú. Điều này có thể phải chịu chi phí đáng kể trên văn bản.

Một tối ưu hóa phổ biến được thực hiện trong các hệ thống NoQuery là sử dụng sao chép đại biểu và tính nhất quán cuối cùng để cho phép dữ liệu được sao chép một cách lười biếng trong khi vẫn đảm bảo mức độ phục hồi nhất định của dữ liệu bằng cách viết vào đại biểu trước khi báo cáo giao dịch như đã cam kết. Dữ liệu sau đó được sao chép một cách lười biếng sang các nút khác nơi các bản sao của dữ liệu cư trú.

Lưu ý rằng "tính nhất quán cuối cùng" là một sự đánh đổi lớn về tính nhất quán có thể không được chấp nhận nếu dữ liệu phải được xem một cách nhất quán ngay khi giao dịch được thực hiện. Ví dụ, trên một ứng dụng tài chính, số dư cập nhật sẽ có sẵn ngay lập tức.

Hệ thống chia sẻ đĩa

Một hệ thống đĩa chia sẻ là một trong đó tất cả các nút có quyền truy cập vào tất cả các bộ lưu trữ. Do đó, tính toán là độc lập với vị trí. Nhiều nền tảng DBMS cũng có thể hoạt động trong chế độ này - Oracle RAC là một ví dụ về kiến ​​trúc như vậy.

Các hệ thống đĩa được chia sẻ có thể mở rộng đáng kể vì chúng có thể hỗ trợ mối quan hệ M: M giữa các nút lưu trữ và các nút xử lý. Một SAN có thể có nhiều bộ điều khiển và nhiều máy chủ có thể chạy cơ sở dữ liệu. Các kiến ​​trúc này có một công tắc như một nút cổ chai trung tâm nhưng các công tắc thanh ngang cho phép công tắc này có nhiều băng thông. Một số xử lý có thể được giảm tải lên các nút lưu trữ (như trong trường hợp Exadata của Oracle) có thể làm giảm lưu lượng trên băng thông lưu trữ.

Mặc dù về mặt lý thuyết, việc chuyển đổi là tắc nghẽn băng thông có sẵn có nghĩa là các kiến ​​trúc đĩa chia sẻ sẽ mở rộng khá hiệu quả với khối lượng giao dịch lớn. Hầu hết các kiến ​​trúc DBMS chính thống đều áp dụng phương pháp này bởi vì nó có khả năng mở rộng 'đủ tốt' và độ tin cậy cao. Với kiến ​​trúc lưu trữ dự phòng như kênh sợi quang, không có điểm thất bại duy nhất vì có ít nhất hai đường dẫn giữa bất kỳ nút xử lý và bất kỳ nút lưu trữ nào.

Hệ thống không chia sẻ

Các hệ thống không chia sẻ là các hệ thống có ít nhất một số dữ liệu được lưu cục bộ vào một nút và không thể hiển thị trực tiếp với các nút khác. Điều này loại bỏ nút cổ chai của một công tắc trung tâm, cho phép cơ sở dữ liệu mở rộng quy mô (ít nhất là trên lý thuyết) với số lượng nút. Phân vùng ngang cho phép dữ liệu được phân chia giữa các nút; điều này có thể trong suốt với khách hàng hay không (xem Shending ở trên).

Vì dữ liệu được phân phối vốn có nên một truy vấn có thể yêu cầu dữ liệu từ nhiều hơn một nút. Nếu một phép nối cần dữ liệu từ các nút khác nhau, thao tác bán tham gia được sử dụng để truyền đủ dữ liệu để hỗ trợ phép nối từ nút này sang nút khác. Điều này có thể dẫn đến một lượng lớn lưu lượng mạng, do đó tối ưu hóa việc phân phối dữ liệu có thể tạo ra sự khác biệt lớn đối với hiệu suất truy vấn.

Thông thường, dữ liệu được sao chép trên các nút của hệ thống không chia sẻ để giảm sự cần thiết cho các liên kết bán. Điều này hoạt động khá tốt trên các thiết bị kho dữ liệu vì kích thước thường có nhiều đơn đặt hàng có độ lớn nhỏ hơn các bảng thực tế và có thể dễ dàng sao chép trên các nút. Chúng cũng thường được tải theo đợt vì vậy chi phí nhân rộng ít gây ra sự cố hơn so với trên ứng dụng giao dịch.

Tính song song vốn có của một kiến ​​trúc không chia sẻ làm cho chúng phù hợp với kiểu truy vấn quét / tổng hợp bảng đặc trưng của kho dữ liệu. Loại hoạt động này có thể mở rộng gần như tuyến tính với số lượng nút xử lý. Các phép nối lớn trên các nút có xu hướng phát sinh nhiều chi phí hơn vì các hoạt động bán tham gia có thể tạo ra nhiều lưu lượng mạng.

Di chuyển khối lượng dữ liệu lớn ít hữu ích hơn cho các ứng dụng xử lý giao dịch, trong đó chi phí chung của nhiều bản cập nhật làm cho loại kiến ​​trúc này kém hấp dẫn hơn so với đĩa chia sẻ. Do đó, kiểu kiến ​​trúc này có xu hướng không được sử dụng rộng rãi trong các ứng dụng kho dữ liệu.

Shending, sao chép đại biểu và tính nhất quán cuối cùng

Bản sao đại biểu là một cơ sở trong đó DBMS sao chép dữ liệu để có tính sẵn sàng cao. Điều này hữu ích cho các hệ thống dự định hoạt động trên phần cứng hàng hóa rẻ hơn không có tính năng sẵn sàng cao như SAN. Trong loại hệ thống này, dữ liệu được sao chép trên nhiều nút lưu trữ để đọc hiệu năng và lưu trữ dự phòng để làm cho hệ thống trở nên linh hoạt trước lỗi phần cứng của một nút.

Tuy nhiên, sao chép ghi vào tất cả các nút là O (M x N) cho các nút M và N ghi. Điều này làm cho việc ghi đắt tiền nếu việc ghi phải được sao chép tới tất cả các nút trước khi giao dịch được phép thực hiện. Sao chép đại biểu là một sự thỏa hiệp cho phép ghi được sao chép vào một tập hợp con của các nút ngay lập tức và sau đó lười biếng viết ra các nút khác bằng một tác vụ nền. Việc ghi có thể được cam kết nhanh hơn, trong khi cung cấp một mức độ dư thừa nhất định bằng cách đảm bảo rằng chúng được sao chép thành một tập hợp con tối thiểu (đại biểu) của các nút trước khi giao dịch được báo cáo như đã cam kết với khách hàng.

Điều này có nghĩa là đọc các nút bên ngoài đại biểu có thể thấy các phiên bản dữ liệu đã lỗi thời cho đến khi quá trình nền hoàn thành việc ghi dữ liệu vào phần còn lại của các nút. Các ngữ nghĩa được gọi là 'Tính nhất quán cuối cùng' và có thể hoặc không thể chấp nhận được tùy thuộc vào yêu cầu của ứng dụng của bạn nhưng có nghĩa là các cam kết giao dịch gần với O (1) hơn so với O (n) trong việc sử dụng tài nguyên.

Shending yêu cầu khách hàng nhận thức được việc phân vùng dữ liệu trong cơ sở dữ liệu, thường sử dụng một loại thuật toán được gọi là 'băm nhất quán'. Trong cơ sở dữ liệu được phân tách, máy khách băm khóa để xác định máy chủ nào trong cụm sẽ đưa ra truy vấn. Vì các yêu cầu được phân phối trên các nút trong cụm, không có nút cổ chai với một nút điều phối truy vấn duy nhất.

Các kỹ thuật này cho phép cơ sở dữ liệu mở rộng ở tốc độ gần tuyến tính bằng cách thêm các nút vào cụm. Về mặt lý thuyết, sao chép đại biểu chỉ cần thiết nếu phương tiện lưu trữ cơ bản được coi là không đáng tin cậy. Điều này hữu ích nếu các máy chủ hàng hóa được sử dụng nhưng ít giá trị hơn nếu cơ chế lưu trữ cơ bản có sơ đồ sẵn sàng cao của riêng nó (ví dụ: SAN với bộ điều khiển được nhân đôi và kết nối nhiều đường dẫn đến máy chủ).

Ví dụ: BigTable của Google không tự triển khai Bản sao đại biểu, mặc dù nó nằm trên GFS, một hệ thống tệp được nhóm sử dụng sao chép đại biểu. BigTable (hoặc bất kỳ hệ thống không chia sẻ nào) có thể sử dụng hệ thống lưu trữ đáng tin cậy với nhiều bộ điều khiển và phân vùng dữ liệu giữa các bộ điều khiển. Truy cập song song sau đó sẽ đạt được thông qua phân vùng dữ liệu.

Quay lại nền tảng RDBMS

Không có lý do cố hữu nào mà các kỹ thuật này không thể được sử dụng với RDBMS. Tuy nhiên, quản lý khóa và phiên bản sẽ khá phức tạp trên một hệ thống như vậy và bất kỳ thị trường nào cho một hệ thống như vậy có thể sẽ khá chuyên biệt. Không có nền tảng RDBMS chính thống nào sử dụng sao chép đại biểu và tôi không biết cụ thể về bất kỳ sản phẩm RDBMS nào (ít nhất là không có bất kỳ sự hấp thụ đáng kể nào).

Hệ thống chia sẻ đĩa và không chia sẻ có thể mở rộng khối lượng công việc rất lớn. Chẳng hạn, Oracle RAC có thể hỗ trợ 63 nút xử lý (có thể là các máy SMP lớn theo cách riêng của họ) và một số lượng bộ điều khiển lưu trữ tùy ý trên SAN. Một IBM Sysplex (một cụm các máy tính lớn của zSeries) có thể hỗ trợ nhiều máy tính lớn (mỗi máy có sức mạnh xử lý đáng kể và băng thông I / O của riêng chúng) và nhiều bộ điều khiển SAN. Các kiến ​​trúc này có thể hỗ trợ khối lượng giao dịch rất lớn với ngữ nghĩa ACID, mặc dù chúng giả định lưu trữ đáng tin cậy. Teradata, Netezza và các nhà cung cấp khác tạo ra các nền tảng phân tích hiệu suất cao dựa trên các thiết kế không chia sẻ có quy mô với khối lượng dữ liệu cực lớn.

Cho đến nay, thị trường cho các nền tảng ACID RDBMS giá rẻ nhưng khối lượng cực lớn hoàn toàn bị chi phối bởi MySQL, hỗ trợ sao chép và sao chép đa chủ. MySQL không sử dụng sao chép đại biểu để tối ưu hóa thông lượng ghi, vì vậy các cam kết giao dịch đắt hơn so với trên hệ thống NoQuery. Shending cho phép thông lượng đọc rất cao (ví dụ Facebook sử dụng rộng rãi MySQL), vì vậy loại kiến ​​trúc này có quy mô tốt trên khối lượng công việc nặng đọc.

Một cuộc tranh luận thú vị

BigTable là một kiến ​​trúc không chia sẻ (về cơ bản là một cặp khóa-giá trị phân tán) như được chỉ ra bởi Michael Hausenblas bên dưới . Đánh giá ban đầu của tôi về nó bao gồm công cụ MapReduce, không phải là một phần của BigTable nhưng thường được sử dụng cùng với nó trong các triển khai phổ biến nhất của nó (ví dụ: khung Hadoop / HBase và MapReduce của Google).

So sánh kiến ​​trúc này với Teradata, có mối quan hệ vật lý giữa lưu trữ và xử lý (nghĩa là các nút có lưu trữ cục bộ chứ không phải SAN chung), bạn có thể lập luận rằng BigTable / MapReduce là kiến ​​trúc đĩa được chia sẻ thông qua hệ thống lưu trữ song song có thể nhìn thấy trên toàn cầu.

Thông lượng xử lý của hệ thống kiểu MapReduce như Hadoop bị hạn chế bởi băng thông của bộ chuyển đổi mạng không chặn. 1 Non-blocking chuyển mạch có thể, tuy nhiên, xử lý uẩn băng thông lớn do sự xử lý song song vốn có trong việc thiết kế, vì vậy chúng hiếm khi một hạn chế thực tế đáng kể về hiệu suất. Điều này có nghĩa là một kiến ​​trúc đĩa chia sẻ (có lẽ được gọi là hệ thống lưu trữ chia sẻ) có thể mở rộng thành khối lượng công việc lớn mặc dù về mặt lý thuyết, chuyển đổi mạng là một nút cổ chai trung tâm.

Điểm ban đầu là lưu ý rằng mặc dù nút cổ chai trung tâm này tồn tại trong các hệ thống đĩa chia sẻ, một hệ thống con lưu trữ được phân vùng với nhiều nút lưu trữ (ví dụ: máy chủ máy tính bảng BigTable hoặc bộ điều khiển SAN) vẫn có thể mở rộng đến khối lượng công việc lớn. Một kiến ​​trúc chuyển mạch không chặn có thể (về lý thuyết) xử lý nhiều kết nối hiện tại như nó có các cổng.

1 Tất nhiên việc xử lý và thông lượng I / O khả dụng cũng tạo thành giới hạn về hiệu suất nhưng chuyển đổi mạng là một điểm trung tâm mà tất cả lưu lượng truy cập đều đi qua.


10
Sử thi. Làm tốt lắm cậu bé.
Mark Storey-Smith

8
Câu trả lời tuyệt vời!
Philᵀᴹ

1
Wow, tôi nghĩ rằng bạn khá nhiều bao phủ nó ở đó!
Mr.Brownstone

2
@Michael Hausenblas Trên suy nghĩ thứ hai, nếu bạn tách riêng BigTable DB, tôi sẽ thực hiện theo yêu cầu không chia sẻ. Tôi đã kết hợp nó với toàn bộ ngăn xếp MapReduce / Hadoop (nơi không có mối quan hệ cụ thể giữa xử lý và lưu trữ) trong bài viết này. Bạn hoàn toàn có thể tranh luận một cách hợp lý sự không phù hợp của sự kết hợp đó.
Mối quan tâmOfTunbridgeWells

3
Một vài suy nghĩ kỹ thuật. Trong thực tế, sao chép đại biểu là những gì được thực hiện trên bản sao phát trực tuyến của PostgreSQL cho các thiết lập chính / phụ. Dữ liệu phải cam kết với chủ chỉ theo mặc định nhưng bạn cũng có thể yêu cầu nó cũng được ghi vào n nô lệ trước khi cam kết được trả về.
Chris Travers

21

Cơ sở dữ liệu quan hệ có thể phân cụm như các giải pháp NoQuery. Việc duy trì các thuộc tính ACID có thể làm cho điều này trở nên phức tạp hơn và người ta phải nhận thức được sự đánh đổi được thực hiện để duy trì các tính chất này. Thật không may, chính xác những gì sự đánh đổi phụ thuộc vào khối lượng công việc và tất nhiên các quyết định được đưa ra trong khi thiết kế phần mềm cơ sở dữ liệu.

Ví dụ, một khối lượng công việc OLTP chủ yếu có thể có độ trễ truy vấn duy nhất bổ sung ngay cả khi thông lượng của cụm có tỷ lệ độc đáo. Độ trễ thêm đó có thể không được chú ý hoặc là một công cụ thỏa thuận thực sự, tất cả phụ thuộc vào ứng dụng. Nói chung, phân cụm sẽ cải thiện thông lượng và làm giảm độ trễ, nhưng ngay cả 'quy tắc' đó cũng bị nghi ngờ nếu các truy vấn của ứng dụng đặc biệt có thể chấp nhận để xử lý song song.

Những gì công ty mà tôi làm việc, Clustrix , cung cấp là một loạt các nút tính toán và lưu trữ đồng nhất được kết nối bởi một mạng tốc độ tương đối cao. Dữ liệu quan hệ là hàm băm được phân phối trên các nút trên cơ sở mỗi chỉ mục trong các khối mà chúng ta gọi là 'lát'. Mỗi lát cắt sẽ có hai hoặc nhiều bản sao trải đều trên toàn cụm để đảm bảo độ bền trong trường hợp hỏng nút hoặc đĩa. Khách hàng có thể kết nối với bất kỳ nút nào trong cụm để đưa ra các truy vấn bằng giao thức dây MySQL.

Thật là không tự nhiên khi nghĩ về các thành phần của cơ sở dữ liệu ACID một cách độc lập vì rất nhiều trong số đó khớp với nhau, nhưng ở đây:

Nguyên tử - Clustrix sử dụng hai cam kết pha để đảm bảo tính nguyên tử. Các hoạt động CẬP NHẬT và XÓA cũng sẽ khóa các hàng thông qua trình quản lý khóa phân tán của chúng tôi bởi vì bên trong chúng tôi biến các hoạt động đó thành CHỌN theo sau là các hoạt động CẬP NHẬT / XÓA chính xác.

Nguyên tử rõ ràng làm tăng lượng tin nhắn giữa các nút tham gia giao dịch và tăng tải cho các nút đó để xử lý giao thức cam kết. Đây là một phần chi phí để có một hệ thống phân tán và sẽ hạn chế khả năng mở rộng nếu mọi nút tham gia vào mọi giao dịch, nhưng các nút chỉ tham gia vào một giao dịch nếu chúng có một trong các bản sao được viết.

Tính nhất quán - Khóa ngoại được thực hiện dưới dạng kích hoạt, được đánh giá tại thời điểm cam kết. Các hoạt động CẬP NHẬT và XÓA phạm vi lớn có thể ảnh hưởng đến hiệu suất của chúng tôi do khóa, nhưng may mắn thay chúng tôi không thấy những điều này thường xuyên. Nó phổ biến hơn nhiều để xem cập nhật giao dịch / xóa một vài hàng và sau đó cam kết.

Phần khác của tính nhất quán là duy trì một đại biểu thông qua giao thức đồng thuận PAXOS , đảm bảo rằng chỉ các cụm với phần lớn các nút đã biết mới có thể ghi. Tất nhiên, một cụm có thể có đại biểu nhưng vẫn thiếu dữ liệu (tất cả các bản sao của một lát ngoại tuyến), điều này sẽ khiến các giao dịch truy cập vào một trong những lát đó bị lỗi.

Cách ly - Clustrix cung cấp cách ly MVCC ở cấp độ chứa. Tính nguyên tử của chúng tôi đảm bảo rằng tất cả các bản sao có thể nhận được một văn bản cụ thể trước khi chúng tôi báo cáo giao dịch được cam kết chủ yếu làm giảm vấn đề cách ly với những gì bạn có trong trường hợp không phân cụm.

Độ bền - Mỗi lát dữ liệu quan hệ được lưu trữ vào hai hoặc nhiều nút để cung cấp khả năng phục hồi trong trường hợp lỗi nút hoặc đĩa. Có lẽ cũng đáng lưu ý ở đây là phiên bản thiết bị của sản phẩm của chúng tôi có thẻ NVRAM nơi WAL được lưu trữ vì lý do hiệu suất. Rất nhiều cơ sở dữ liệu cá thể đơn lẻ sẽ cải thiện hiệu suất của WAL của họ bằng cách kiểm tra điểm theo các khoảng thời gian thay vì tại mỗi lần xác nhận. Cách tiếp cận đó có vấn đề trong một hệ thống phân tán vì làm cho 'phát lại đến đâu?' một câu hỏi phức tạp Chúng tôi vượt qua điều này trong thiết bị bằng cách cung cấp một đảm bảo độ bền cứng.


2
Cảm ơn @Matt - đây chỉ là loại câu trả lời mà chúng tôi đã theo dõi. Bên cạnh đó, tôi đồng ý rằng việc tách ra các thành phần của ACID không phải là điều rất tự nhiên vì tôi đã tìm thấy một điều tương tự khi tôi đang viết bài viết của mình. Một lần nữa, cảm ơn bạn đã dành thời gian và chúng tôi rất vui khi thấy những đóng góp tiếp theo từ bạn và nhóm của bạn.
Mối quan tâmOfTunbridgeWells

14

Câu trả lời cơ bản là mô hình nhất quán là khác nhau. Tôi viết thư này để mở rộng câu trả lời của ConcernedOfTunbridge mà thực sự phải là điểm tham chiếu cho việc này.

Điểm cơ bản của mô hình nhất quán ACID là nó tạo ra một loạt các đảm bảo cơ bản về trạng thái của dữ liệu trên toàn cầu trong hệ thống. Các bảo đảm này tuân theo các giới hạn của định lý CAP, về cơ bản, để làm cho chúng hoạt động, bạn cần phải có tất cả các nguồn có thẩm quyền trên cùng một trang trước khi bạn nói với ứng dụng bạn đã thực hiện giao dịch. Do đó, sao chép đa chủ rất khó thực hiện mà không gặp phải các ràng buộc này. Chắc chắn một khi bạn bắt đầu thực hiện sao chép không đồng bộ trong môi trường đa chủ, các đảm bảo này sẽ xuất hiện ngoài cửa sổ. Mô hình nhất quán ACID là mô hình nhất quán mạnh dành cho thông tin quan trọng hoặc quan trọng.

Mô hình nhất quán BASE là mô hình nhất quán yếu dành cho thông tin không quan trọng. Bởi vì các bảo đảm yếu hơn đáng kể, khả năng cung cấp các bảo đảm yếu như vậy trong các hệ thống đa chủ dễ dàng đạt được hơn vì các bảo đảm là, tốt, yếu.

RDBMS có thể và thực hiện quy mô cũng như các giải pháp NoQuery!

Tuy nhiên, có những trường hợp RDBMS có thể và thực hiện quy mô đến mức mà NoQuery thậm chí không thể sánh được. Nó chỉ làm như vậy khác nhau. Tôi sẽ xem Postgres-XC là ví dụ về cách nhân rộng có thể thực hiện được mà không phải hy sinh các đảm bảo tính nhất quán mạnh mẽ.

Cách thức mà các RDBMS cụ thể này thực hiện là triển khai một thứ gì đó giống như một giải pháp ngăn chặn với proxy và giống như một kiến ​​trúc đĩa chia sẻ nhưng phức tạp hơn đáng kể. Chúng không mở rộng theo cùng một cách với các giải pháp NoQuery và do đó, sự đánh đổi là khác nhau.

Mô hình Postgres-XC, tôi hiểu, được truyền cảm hứng từ Teradata. Nó bao gồm các nút trong hai vai trò khác nhau, như các nút lưu trữ hoặc điều phối viên. Các điều phối viên là đa chủ (không có sự sao chép thực sự) và họ kết nối với các nút lưu trữ để xử lý xử lý dữ liệu thực tế. Các nút lưu trữ sao chép trong một thiết lập chủ-nô. Mỗi nút lưu trữ chứa những gì thực chất là một mảnh vỡ của cơ sở dữ liệu, nhưng các điều phối viên duy trì một bức tranh nhất quán về dữ liệu.

Một sự phân tách đáng kể các trách nhiệm có liên quan ở đây. Các nút lưu trữ quản lý dữ liệu, kiểm tra các ràng buộc, các ràng buộc khóa ngoài có thể thực thi cục bộ và xử lý ít nhất một số tổng hợp dữ liệu. Các điều phối viên xử lý các khóa ngoại không thể thực thi cục bộ, cũng như cửa sổ và các cân nhắc dữ liệu khác có thể lấy từ nhiều nút dữ liệu. Về bản chất, các điều phối viên làm cho ACID có thể có trong các giao dịch phân tán trong một thiết lập đa chủ trong đó người dùng thậm chí không biết các giao dịch được phân phối.

Về vấn đề này, Postgres-XC cung cấp một cái gì đó hơi giống với các tùy chọn chia tỷ lệ NoQuery nhưng có một số phức tạp được thêm vào do các đảm bảo tính nhất quán bổ sung. Tuy nhiên, tôi hiểu rằng có các RDBMS thương mại cung cấp loại khả năng mở rộng này. Teradata làm điều này. Ngoài ra, các hệ thống đĩa được chia sẻ có thể mở rộng theo cách tương tự và cả DB2 và Oracle đều cung cấp các giải pháp như vậy. Vì vậy, hoàn toàn không công bằng khi nói rằng RDBMS không thể làm điều này. Họ có thể. Tuy nhiên, nhu cầu rất nhỏ trong quá khứ đến mức các nền kinh tế có quy mô không đủ để làm cho các giải pháp độc quyền trở nên rất hợp lý với hầu hết người chơi.

Cuối cùng là một ghi chú trên VoltDB. Giống như các giải pháp NoQuery, tôi thấy VoltDB là một công cụ rất chuyên dụng. Nó rất nhanh nhưng với chi phí của các giao dịch nhiều chuyến đi và độ bền trên đĩa. Điều này có nghĩa là bạn có một bộ các mối quan tâm rất khác nhau. VoltDB là những gì bạn nhận được khi những người tiên phong RDBMS xây dựng giải pháp NoQuery ;-). VoltDB nhanh một phần vì nó xác định đồng thời và độ bền ngoài phương trình. Độ bền trở thành một thuộc tính mạng, không phải là thuộc tính lưu trữ nội bộ và đồng thời được quản lý bằng cách chạy từng truy vấn một, song song nội bộ, theo thứ tự tuần tự. Nó không phải là một RDBMS truyền thống (và đó là một điều tốt btw vì nó có thể đặt RDBMS truyền thống không thể, nhưng điều ngược lại cũng rất đúng).

Biên tập: Nó cũng quan trọng để xem xét ý nghĩa của tham gia. Trong một hệ thống cụm, tham gia trở thành một vấn đề hiệu suất rất khác nhau. Nếu mọi thứ nằm trên cùng một nút, chúng có thể cải thiện hiệu suất nhưng nếu bạn phải thực hiện một chuyến đi khứ hồi đến một nút khác thì điều này sẽ gây ra chi phí rất cao. Vì vậy, các mô hình dữ liệu tạo ra sự khác biệt và cách tiếp cận của phân cụm có tác động hiệu suất. Các phương pháp tiếp cận như Postgres-XC và Postgres-XL cho rằng bạn có thể dành một chút thời gian để suy nghĩ mọi thứ để bạn có thể phân chia dữ liệu của mình một cách thích hợp và giữ dữ liệu được nối với nhau. Nhưng điều đó áp đặt thiết kế trên đầu. Mặt khác, thang đo này tốt hơn nhiều so với nhiều giải pháp NoQuery và có thể được điều chỉnh phù hợp. Ví dụ: chúng tôi (tại Điều chỉnh) sử dụng chiến lược phân cụm giống như NoQuery cho 3,5PB dữ liệu của chúng tôi trong PostgreQuery về cơ bản là phân tích nhật ký. Và rất nhiều thiết kế của chúng tôi được truyền cảm hứng sâu sắc bởi các chiến lược phân cụm NoQuery. Vì vậy, đôi khi mô hình dữ liệu cũng hạn chế mô hình phân cụm.


6

Câu trả lời của tôi sẽ không được viết tốt như câu trước, nhưng rồi đây.

Michael Stonebraker của Ingres danh tiếng đã tạo ra một kho lưu trữ cột không chia sẻ MPP (Vertica) và cơ sở dữ liệu SQL mới không chia sẻ MPP (VoltDB) để phân phối dữ liệu giữa các nút khác nhau trong một cụm và duy trì ACID. Vertica đã được mua bởi HP.

Tôi tin rằng các cơ sở dữ liệu SQL mới khác cũng duy trì ACID, mặc dù tôi không chắc có bao nhiêu trong số chúng phân phối các hàng của chúng trên một cụm, v.v.

Đây là một bài nói chuyện Stonebraker đã đưa ra về SQL mới liên quan đến NoQuery và "SQL cũ". http://www.youtube.com/watch?v=uhDM4fcI2aI


2
"SQL mới" và "SQL cũ" này là gì? Bạn có quan tâm để làm rõ?
ypercubeᵀᴹ

1
"Old SQL" sẽ là SQL Server, Oracle, MySQL, PostgreSQL, v.v ... Đây là định nghĩa từ Wikipedia cho NewQuery, điều này khá hay: các hệ thống cho khối lượng công việc OLTP trong khi vẫn duy trì các đảm bảo ACID của hệ thống cơ sở dữ liệu một nút truyền thống. " Tôi đánh giá cao video tôi đã đăng nếu muốn tìm hiểu thêm.
geoffrobinson

Như một lưu ý ở đây và như tôi đã giải thích trong câu trả lời của mình, VoltDB xử lý khả năng mở rộng bằng cách xác định độ bền và đồng thời ra khỏi phương trình. Về bản chất với VoltDB, bạn không nhận được độ bền của hệ thống và không có quyền truy cập đồng thời vào dữ liệu. SQL mới giống như một chiếc xe đua Indie 500, nhưng SQL cũ vẫn là xe tải bán hoặc có thể là động cơ của tàu chở hàng.
Chris Travers

1

Phân cụm MySQL có thể phân đoạn bằng cách sử dụng nhiều bản sao chính và băm phân đoạn trên toàn cụm.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.