Tại sao cơ sở dữ liệu quan hệ có vấn đề về khả năng mở rộng?

Question

Tôi đã đọc một số bài báo trực tuyến cho thấy cơ sở dữ liệu quan hệ có vấn đề mở rộng quy mô và không tốt để sử dụng khi nói đến dữ liệu lớn. Đặc biệt trong điện toán đám mây nơi dữ liệu lớn. Nhưng tôi không thể tìm ra những lý do vững chắc để giải thích tại sao nó không thể mở rộng được nhiều, bởi googling. Bạn có thể giải thích cho tôi những hạn chế của cơ sở dữ liệu quan hệ khi nói đến khả năng mở rộng?

Cảm ơn.

Answer 1

Cơ sở dữ liệu quan hệ cung cấp dịch vụ vững chắc, trưởng thành theo các thuộc tính ACID. Chúng tôi nhận được giao dịch xử lý, đăng nhập hiệu quả để cho phép phục hồi vv Đây là những dịch vụ cốt lõi của các dbs quan hệ, và những cái mà họ giỏi. Chúng khó tùy chỉnh và có thể được coi là nút cổ chai, đặc biệt nếu bạn không cần chúng trong một ứng dụng cụ thể (ví dụ: phân phát nội dung trang web với mức độ quan trọng thấp), trong trường hợp này, MySQL được sử dụng rộng rãi không cung cấp xử lý giao dịch với công cụ lưu trữ mặc định và do đó không đáp ứng ACID). Rất nhiều vấn đề "dữ liệu lớn" không yêu cầu những ràng buộc nghiêm ngặt này, ví dụ như phân tích trang web, tìm kiếm trên web hoặc xử lý quỹ đạo đối tượng chuyển động, vì chúng đã bao gồm sự không chắc chắn của tự nhiên.

Khi đạt đến giới hạn của một máy tính nhất định (bộ nhớ, CPU, đĩa: dữ liệu quá lớn hoặc xử lý dữ liệu quá phức tạp và tốn kém), phân phối dịch vụ là một ý tưởng hay. Rất nhiều cơ sở dữ liệu quan hệ và NoSQL cung cấp lưu trữ phân tán. Tuy nhiên, trong trường hợp này, ACID tỏ ra khó đáp ứng: các trạng thái CAP theorem tương tự nhau, khả năng sẵn sàng, nhất quán và dung sai phân vùng không thể đạt được cùng một lúc. Nếu chúng ta từ bỏ ACID (thỏa mãn BASE ví dụ), khả năng mở rộng có thể được tăng lên. Xem this bài đăng ví dụ: để phân loại các phương pháp lưu trữ theo CAP.

Một nút cổ chai khác có thể là mô hình quan hệ linh hoạt và thông minh với các hoạt động SQL: trong nhiều trường hợp, một mô hình đơn giản hơn với các thao tác đơn giản sẽ đầy đủ và hiệu quả hơn (như các kho khóa-giá trị không được nhập). Mô hình lưu trữ vật lý hàng thông thường cũng có thể bị hạn chế: ví dụ, nó không phải là tối ưu để nén dữ liệu. Tuy nhiên

Có ACID cơ sở dữ liệu quan hệ phù hợp nhanh chóng và khả năng mở rộng, bao gồm cả những cái mới như VoltDB, như công nghệ của cơ sở dữ liệu quan hệ là trưởng thành, cũng được nghiên cứu và phổ biến. Chúng ta chỉ cần chọn một giải pháp thích hợp cho vấn đề đã cho.

Answer 2

Lấy ví dụ đơn giản nhất: chèn hàng có ID được tạo. Vì các ID phải là duy nhất trong bảng, cơ sở dữ liệu phải bằng cách nào đó khóa một số loại truy cập liên tục để không có INSERT nào khác sử dụng cùng một giá trị. Vì vậy, bạn có hai lựa chọn: hoặc chỉ cho phép một cá thể ghi dữ liệu hoặc khóa phân phối. Cả hai giải pháp đều là một chai-beck lớn - và là ví dụ đơn giản nhất!

Answer 3

Một điểm tôi không nghĩ mọi người nghĩ đến là việc phân tích cú pháp SQL có chi phí đáng kể.

Đây là một trong số lý do khiến câu lệnh chuẩn bị hữu ích. Tuy nhiên, trong các ứng dụng kiểu CGI (thời gian chạy ngắn, nhiều trường hợp) như hầu hết các ứng dụng PHP, các câu lệnh chuẩn bị vẫn phải được phân tích cú pháp một lần.

Thường thì bản thân các máy chủ cơ sở dữ liệu thực sự đủ nhanh, nó chỉ là có phí trong phân tích cú pháp SQL. Yoshinori Matsunobu có article tuyệt vời về việc triển khai handlerSocket, trình kết nối noSQL cho MySQL + InnoDB có thể đạt được 750.000 truy vấn mỗi giây cho các lần tra cứu chính, tốt hơn ~ 420.000 truy vấn mỗi giây mà anh ta đã ghi nhớ.

Answer 4

Hãy tưởng tượng hai loại ngã tư khác nhau.

Có đèn giao thông hoặc nhân viên cảnh sát điều chỉnh giao thông, chuyển động trên đường ngang ở tốc độ giới hạn và có một cơ quan giám sát đăng ký chính xác những gì ô tô lái xe trên ngã tư vào thời điểm nào chính xác và hướng đi.

Người kia không có ai trong số đó và mọi người đến ngã tư ở bất kỳ tốc độ nào anh ta lái xe, chỉ cần lao vào và muốn đi qua càng nhanh càng tốt.

Trước đây là bất kỳ công cụ cơ sở dữ liệu truyền thống nào. Ngã tư là chính dữ liệu. Những chiếc xe là các giao dịch muốn truy cập dữ liệu. Đèn giao thông hoặc nhân viên cảnh sát là DBMS. Cơ quan giám sát lưu trữ nhật ký và tạp chí.

Loại thứ hai là loại động cơ NOACID.

Cả hai đều có điểm bão hòa, tại thời điểm đó xe ô tô bắt buộc phải bắt đầu xếp hàng tại các điểm vào. Cả hai đều có thông lượng tối đa. Ngưỡng đó nằm ở một giá trị thấp hơn cho loại ngã tư cũ, và lý do nên rõ ràng.

Lợi thế của loại đường giao nhau cũ cũng nên rõ ràng. Càng ít cơ hội cho các tai nạn xảy ra. Trên loại đường ngang thứ hai, bạn có thể mong đợi các tai nạn không xảy ra chỉ khi mật độ giao thông thấp hơn nhiều so với thông lượng tối đa lý thuyết của ngã tư. Và trong dịch thuật cho các công cụ quản lý dữ liệu, nó chuyển thành một sự bảo đảm về kết quả nhất quán và mạch lạc, mà chỉ có kiểu giao thoa cũ (động cơ cơ sở dữ liệu cổ điển, cho dù có quan hệ hay nối mạng hay phân cấp).

Tương tự có thể được kéo dài hơn nữa. Hãy tưởng tượng những gì sẽ xảy ra nếu một tai nạn xảy ra.Trên loại đường ngang thứ hai, mối quan tâm chính có thể là dọn đường càng nhanh càng tốt, vì vậy giao thông có thể tiếp tục và khi điều đó được thực hiện, thông tin nào vẫn có sẵn để điều tra ai gây ra tai nạn và làm cách nào? Không có gì đâu. Nó sẽ không được biết đến. Ngã tư được mở chỉ chờ đợi cho tai nạn tiếp theo xảy ra. Trên ngã tư được quy định, có cảnh sát điều chỉnh lưu lượng truy cập đã xem những gì đã xảy ra và có thể làm chứng. Có nhật ký cho biết chiếc xe nào được nhập chính xác vào thời điểm nào, tại điểm nhập chính xác, ở tốc độ nào chính xác, rất nhiều tài liệu có sẵn để kiểm tra để xác định nguyên nhân gốc rễ của tai nạn. Nhưng tất nhiên không ai trong số đó đến miễn phí.

Đủ màu sắc làm giải thích?