2012-01-04 7 views
18

Tôi đã đọc các văn bản sau đây trong một technical blog thảo luận về những ưu điểm và nhược điểm của NoSQLTại sao NoSQL lại tốt hơn trong việc "mở rộng quy mô" hơn RDBMS?

" Trong nhiều năm qua, để cải thiện hiệu suất trên các máy chủ cơ sở dữ liệu, quản trị cơ sở dữ liệu đã có để mua các máy chủ lớn hơn như tải cơ sở dữ liệu RDBMS thường không dễ dàng mở rộng quy mô, nhưng các cơ sở dữ liệu NoSQL mới hơn được thiết kế để mở rộng dễ dàng để tận dụng các nút mới và thường được thiết kế với phần cứng hàng hóa chi phí thấp trong tâm trí. "

Tôi trở nên bối rối về khả năng mở rộng của RDBMS và NoSQL.

nhầm lẫn của tôi là:

  1. Tại sao RDBMS là ít có khả năng mở rộng quy mô ra? Và lý do mua máy chủ lớn hơn thay vì mua các máy chủ rẻ hơn.
  2. Tại sao NoSQL có thể mở rộng quy mô hơn?

Trả lời

24

RDBMS có ACID (http://en.wikipedia.org/wiki/ACID) và hỗ trợ giao dịch. Mở rộng quy mô "với" RDBMS khó thực hiện hơn do các khái niệm này.

Các giải pháp NoSQL thường cung cấp nguyên tử mức kỷ lục, nhưng không thể đảm bảo một loạt các hoạt động sẽ thành công (giao dịch).

Nó đi đến: để giữ cho dữ liệu toàn vẹn và hỗ trợ giao dịch, RDBMS đa máy chủ cần phải có kênh truyền thông phụ trợ nhanh để đồng bộ hóa tất cả các giao dịch có thể và ghi, trong khi ngăn chặn/xử lý bế tắc.

Đây là lý do tại sao bạn thường chỉ thấy 1 chủ (người viết) và nhiều người nô lệ (người đọc).

+1

RavenDB [hỗ trợ giao dịch] (http://ravendb.net/documentation/docs-api-transactions), mặc dù không theo nghĩa truyền thống. – vcsjones

+0

Cảm ơn, nó có ý nghĩa với tôi. Tôi có thể hỏi nếu thiếu sự hỗ trợ của giao dịch là một bất lợi của NoSQL? Và có trường hợp nào hỗ trợ giao dịch không quan trọng hay ít sử dụng để thiếu sự hỗ trợ này không phải là một bất lợi? – xiaohan2012

+4

Nó sẽ là một disavantage nếu bạn cần nó: (NoSql so với sql là một sự cân bằng dễ dàng khả năng mở rộng, so với dễ quản lý giao dịch.Vì vậy, nếu bạn nói tôi cần giao dịch và đi sql, khả năng mở rộng chỉ có khó khăn hơn, nếu bạn đi nosql và sau đó –

6

RDBMS điển hình thực hiện bảo hành mạnh mẽ về tính nhất quán. Điều này đòi hỏi một số mở rộng giao tiếp giữa các nút cho mỗi giao dịch. Điều này hạn chế khả năng mở rộng quy mô, bởi vì nhiều nút hơn có nghĩa là nhiều giao tiếp hơn

Các hệ thống NoSql thực hiện các giao dịch khác nhau. Ví dụ: họ không đảm bảo rằng phiên thứ hai sẽ thấy dữ liệu ngay lập tức được cam kết bởi phiên đầu tiên. Qua đó tách giao dịch lưu trữ một số dữ liệu từ quá trình tạo dữ liệu đó cho mọi người dùng. Google "cuối cùng nhất quán". Vì vậy, một giao dịch duy nhất không cần phải chờ đợi cho bất kỳ liên lạc nút nào (hoặc ít hơn nhiều). Vì vậy, họ có thể sử dụng một số lượng lớn các nút dễ dàng hơn nhiều.

+1

Những sự đánh đổi khác nhau cũng có thể được cấu hình trong các hệ thống RDBMS, nhưng không nhiều người biết điều này. Xem: http://tqdev.com/2016-trading-durability-for-performance-without-nosql – mevdschee

15

Vì vậy, tôi đã cố gắng tìm ra điểm mấu chốt thực sự khi nói đến NoSQL vs RDBMS bản thân mình, và luôn luôn kết thúc với một phản ứng mà không hoàn toàn cắt nó. Trong tìm kiếm của tôi, có 2 sự khác biệt chính giữa NoSQL và SQL, với chỉ 1 là một lợi thế thực sự.

  1. ACID vs CƠ SỞ - NoSQL thường lá ra một số tính năng ACID của SQL, loại 'gian lận' đó là cách để hiệu suất cao hơn bằng cách để lại lớp trừu tượng này để các lập trình viên. Điều này đã được bao phủ bởi các áp phích trước đó.

  2. Chia tỷ lệ ngang - Lợi thế thực sự của NoSQL là chia tỷ lệ ngang, còn gọi là sharding.Xem xét các tài liệu NoSQL là một đối tượng 'khép kín', các đối tượng có thể nằm trên các máy chủ khác nhau mà không phải lo lắng về việc nối các hàng từ nhiều máy chủ, như trường hợp với mô hình quan hệ.

Hãy nói rằng chúng ta muốn trả về một đối tượng như thế này:

post { 
    id: 1 
    title: 'My post' 
    content: 'The content' 
    comments: { 
     comment: { 
     id: 1 
     } 
     comment: { 
     id: 2 
     } 
     ... 

    views: { 
     view: { 
     user: 1 
     } 
     view: { 
     user: 2 
     } 
     ... 
    } 
} 

Trong NoSQL, đối tượng đó sẽ cơ bản được lưu trữ như là, và do đó có thể nằm trên một máy chủ duy nhất như là một loại tự đối tượng -contained, mà không cần phải tham gia với dữ liệu từ các bảng khác có thể nằm trên các máy chủ DB khác.

Tuy nhiên, với DB quan hệ, bài đăng sẽ cần tham gia với các nhận xét từ bảng comments cũng như lượt xem từ bảng views. Đây không phải là một vấn đề trong SQL ~ UNTIL ~ DB được chia thành các mảnh, trong đó case 'comment 1' có thể nằm trên một máy chủ DB, trong khi 'bình luận 2' trên một máy chủ DB khác. Điều này làm cho việc tạo đối tượng rất giống nhau trong RDBMS trở nên khó khăn hơn nhiều so với trong một NoSQL DB.

Có chuyên gia DB nào ngoài đó xác nhận hoặc tranh luận những điểm này không?

+1

Điều gì xảy ra nếu có một bảng duy nhất để giữ dữ liệu bài đăng bao gồm các nhận xét, lượt xem trong RDBMS? – Anand

+1

Có, khử chuẩn hóa cơ sở dữ liệu đó là một giải pháp có thể cho các vấn đề liên quan đến hiệu suất, rõ ràng là với chi phí của bất kỳ sự không chuẩn hóa dữ liệu (dự phòng, chi phí cập nhật, kích thước, v.v ...). Mà bằng cách này, đó là ý tưởng lỗ của một giải pháp noSQL theo định hướng tổng hợp như khóa-giá trị, định hướng cột và tài liệu. – jsign

-1

Đối với một NO SQL, 1.Tất cả các con liên quan đến một bộ sưu tập là ở cùng một vị trí và như vậy trên cùng một máy chủ và không có hoạt động tham gia để tra cứu dữ liệu từ máy chủ khác.

2.Không có lược đồ để không có Khóa cần thiết trên bất kỳ máy chủ nào và việc xử lý giao dịch được để lại cho khách hàng.

2 ở trên tiết kiệm rất nhiều chi phí cho việc mở rộng quy mô trong NO-SQL.