2010-03-01 63 views
8

Lợi ích của cơ sở dữ liệu không quan hệ (chẳng hạn như bộ nhớ khóa-giá trị) hiển nhiên khi được sử dụng trong bộ dữ liệu quy mô lớn (google, facebook, linkedin). Làm thế nào để bạn nghĩ rằng các ứng dụng nhỏ đến vừa có thể hưởng lợi từ việc sử dụng cơ sở dữ liệu không quan hệ?Cơ sở dữ liệu phi quan hệ (NoSQL) cho các ứng dụng nhỏ và vừa

+2

wiki cộng đồng .... – jldupont

+1

Tôi thừa nhận không có kinh nghiệm thực tế với điều này, nhưng tôi muốn thấy một số liên kết sao lưu xác nhận quyền sở hữu đó hoặc ít nhất giải thích những lựa chọn thay thế là gì. Tôi cũng đồng ý rằng nó có thể là wiki cộng đồng. –

+0

Bạn vui lòng định nghĩa "không quan hệ" là một thứ gì đó không phải là "không quan hệ"? Nếu không, bất kỳ chương trình đặc biệt nào để lưu trữ dữ liệu đều đủ điều kiện. –

Trả lời

6

IBM Mainframes đã có cơ sở dữ liệu "không quan hệ" kể từ thập niên 60 (cơ sở dữ liệu phân cấp như biến thể IMS +). Các cơ sở dữ liệu này vẫn được sử dụng vì chúng cực kỳ nhanh và xử lý tốt quy mô lớn.

Điểm của cơ sở dữ liệu quan hệ là cung cấp phương pháp trừu tượng, thường xuyên để lưu trữ và truy xuất dữ liệu trong đó có thể thực hiện điều chỉnh tương đối độc lập với mô hình dữ liệu (không đúng với IMS). Chúng được thiết kế thay vì phản ứng với việc không có khả năng tổ chức lại cơ sở dữ liệu tìm kiếm dễ dàng. Upside là tổ chức tốt đẹp; Nhược điểm là trung bình, hiệu suất không cao.

Google cung cấp bộ nhớ có thể mở rộng và MapReduce để xử lý tỷ lệ. Nó không quan hệ.

Đã có một sự thúc đẩy rất lớn trong thập kỷ qua để lưu trữ dữ liệu trong XML, về cơ bản là dạng tìm kiếm vì XML hoàn toàn phân cấp. Đó là một sai lầm lớn của IMHO, bởi vì nó lặp đi lặp lại sự bất tiện của cơ sở dữ liệu thừa kế, nhưng không có hiệu suất nào. Tôi không ngạc nhiên khi phong trào này dường như đã chết rất nhiều.

Hầu hết sự thúc đẩy thực tế đối với phi quan hệ dường như đối với tôi về hiệu suất và quy mô. Tôi không thấy làm thế nào điều này giúp các ứng dụng "nhỏ" nhiều.

Mọi người đã đề xuất, nhưng không thực hiện nhiều việc quản lý dữ liệu thực tế bằng cách sử dụng các lược đồ dựa trên tri thức. Doug Lenat của CYC đến tâm trí ở đây. Khả năng của cơ sở dữ liệu để giúp một ứng dụng rút ra kết luận không rõ ràng khiến tôi rất thú vị đối với các ứng dụng "nhỏ" đang cố gắng "thông minh". Nhưng vẫn chưa có nhiều thứ này.

+0

+1 - đóng góp chu đáo – APC

+0

cảm ơn tất cả, rất hữu ích – Victor

2

Điểm ngọt khi sử dụng cơ sở dữ liệu NoSQL ở quy mô đó là khi mô hình cơ sở dữ liệu (khóa-giá trị, tài liệu, v.v.) phù hợp với nhu cầu của ứng dụng và chức năng quan hệ nâng cao là không cần thiết.

Vào cuối nhỏ của quang phổ, hiệu suất là một vấn đề không phải vì mọi thứ đều nhanh chóng. Các công cụ lưu trữ không phải là vấn đề, nếu bạn không cần một công cụ truy vấn phức tạp, việc thiếu sự hỗ trợ SQL là một vấn đề không phải.

Bạn được trái với mức độ phù hợp và mức độ dễ sử dụng. Thành thật mà nói, dụng cụ đã trở thành một vấn đề. Công cụ cơ sở dữ liệu quan hệ đã trưởng thành, công cụ NoSQL ít tính năng phong phú hơn và ít chiến đấu hơn. Thông thường nó là công cụ cuộn của riêng bạn. Chắc chắn xem xét những công cụ bạn sẽ từ bỏ và bao nhiêu bạn cần chúng.

Có một lợi thế bổ sung cho các dự án nhỏ hơn khi xem xét một dịch vụ NoSQL (như Amazon SimpleDB và Microsoft Azure) so với một sản phẩm. Nếu bạn chỉ phải trả tiền cho những gì bạn sử dụng và bạn không sử dụng nhiều, nó có thể rẻ hơn so với chạy một máy chủ chuyên dụng, đi tất cả các con đường xuống để miễn phí cho một cái gì đó giống như mức sử dụng miễn phí SimpleDB.

Bạn cũng tránh một số chi phí bảo trì máy chủ và cơ sở dữ liệu. Đây có thể là một chiến thắng lớn nếu bạn không có DBA hoặc khi các DBA của bạn đã hoạt động. Tất nhiên bạn vẫn sẽ có công việc quản trị để làm, nhưng nó được giảm đáng kể, và thường đơn giản hơn.

1

Khi nói đến cơ sở dữ liệu biểu đồ (như Neo4j - dự án tôi tham gia), chúng nổi trội tại scaling to complexity.Điều này có nghĩa, họ cung cấp "better substrates for modeling business domains" (xem The State of NoSQL, cũng bằng cách Ben Scofield, quá). Như tôi thấy, điều này rất quan trọng trong các ứng dụng nhỏ đến vừa.

Điều này có thể giải thích tốt hơn thông qua các ví dụ, vì vậy đây là một số liên kết đến các ứng dụng ví dụ/mô hình miền:

0

Câu hỏi đặt ra có lẽ đòi hỏi một chút nhiều ngữ cảnh hơn ... giả định môi trường Python, xem xét hướng dẫn tại dự án y_serial: http://yserial.sourceforge.net/

NoSQL không đơn thuần được chấp nhận vì các lý do về khả năng mở rộng. Serialization (của bất kỳ đối tượng Python tùy ý) và persistence là rất thuận tiện ở mọi quy mô - vì vậy hãy xem xét hệ thống khóa-giá trị như một cách tiếp cận.

0

Một trong những vấn đề với RDBMS là bạn cần phải dành nhiều nỗ lực lập bản đồ các mô hình miền ngôn ngữ lập trình của mình cho lược đồ quan hệ của RDBMS của bạn. Nỗ lực này thường dành cho việc cấu hình lớp ORM của bạn.

Với cơ sở dữ liệu NoSQL bạn không bị buộc phải ánh xạ đối tượng của mình vào mô hình quan hệ và trong hầu hết các trường hợp, đối tượng của bạn được sắp xếp theo thứ tự. Do thiếu lược đồ trung gian, data migrations and versioning become easier.

Lợi ích khác là khả năng mở rộng và hiệu suất. Vì hầu hết thời gian dữ liệu của bạn được nhận bởi 'khóa' một cách hiệu quả mọi thứ sử dụng và lập chỉ mục. Có thể thực hiện sharding tầm thường bằng cách thực hiện một% (MOD) trên khóa chống lại số lượng NoSQL sẵn có của bạn cung cấp phân vùng dữ liệu tự nhiên, điều này rất quan trọng cho việc sharding.

Nếu bạn muốn xem cách phát triển với NoSQL khác với RDBMS, tôi có hướng dẫn nơi tôi hiển thị cách đi về designing a simple blog application using Redis.

0

Nếu bạn kết hợp một số dịch vụ đám mây PaaS phổ biến như cửa hàng Key-Value, cửa hàng BLOB và cửa hàng Message Queue, bạn có một số công cụ hữu ích có thể giải phóng các nhà phát triển ứng dụng nhỏ khỏi sự chuyên chế của DBA và cơ sở hạ tầng mọi người.

Ngày nay, các nhà phát triển nhỏ thường sử dụng Jet MDB. Tại sao? Dễ dàng, chia sẻ quyền truy cập dễ dàng như việc lưu trữ tệp MDB trên chia sẻ tệp hiển thị cho toàn bộ cộng đồng ứng dụng. Khi họ có thể thoát khỏi nó (tức là nhận được sự hỗ trợ cần thiết từ những người gác cổng) họ có thể sử dụng SQL Server Express, MySQL, v.v.

Đáng buồn là những người gác cổng có thể khá thù địch để đối phó với một tổ chức lớn. Đề cập đến một "cơ sở dữ liệu" và đột nhiên bạn phải đối mặt với băng đảng DBA và sự chậm trễ liên quan, đánh giá ứng dụng, ưu tiên, vv Đề cập cần một máy chủ và bạn phải đối mặt với đội bắn khác.

Sử dụng giải pháp NoSQL và các dịch vụ đám mây có liên quan có thể loại bỏ một tấn điều này nếu bạn không cần RDBMS.

Đối với một điều, tất cả những gì thực sự bắt buộc là tài khoản với nhà cung cấp dịch vụ đám mây công cộng. Đây là một cái gì đó trở nên khá dễ dàng một khi khái niệm đã được phê duyệt. Và dễ dàng hơn cho bạn với tư cách là nhà phát triển khi bạn đã được phê duyệt và chỉ định một tài khoản, mặc dù tất nhiên có những vấn đề về sổ sách kế toán thông thường.

Nhưng thậm chí hãy đặt sang một bên. Điều gì xảy ra nếu tổ chức của bạn triển khai một đám mây riêng cho những mục đích sử dụng như vậy?Rất nhiều vấn đề về thanh toán bên ngoài biến mất, những lo lắng về mất an ninh dữ liệu biến mất, v.v.

Điều này có thể được thực hiện và cung cấp theo cách bán vô danh, gần như dễ dàng như quản lý chia sẻ tệp. Sự ẩn danh xuất hiện bởi vì một khi bạn đã được chấp thuận phát triển trên đám mây nội bộ, không ai cần phải khai thác chi tiết các hoạt động của bạn bằng cách sử dụng nó nhiều hơn là cần kiểm tra yêu cầu trước khi bạn có thể tạo tệp trên một tệp hiện có .

Rõ ràng sẽ có bộ nhớ và hạn ngạch CPU để quản lý. Không ai có thể đủ khả năng để chỉ tiếp tục mở rộng quy mô không chính xác. Các ứng dụng giả mạo có thể tiêu tốn một lượng lớn tài nguyên. Vì vậy, những gì bạn cần là một số loại hệ thống hạn ngạch để giới hạn sử dụng. Cho dù điều này được giám sát bởi các folks cơ sở hạ tầng là một quyết định thực hiện, hoặc nó có thể được xử lý giống như sử dụng chia sẻ tập tin: chạy ra ngoài và ai đó hét vào lập trình viên, người lần lượt nhìn vào nó và yêu cầu nhiều hơn nếu thích hợp (hoặc sửa lỗi).

Nhưng bạn kết thúc bằng "tính toán tiện ích" và "không sử dụng SQL", bạn không phải chịu chi phí (và các vấn đề) đối phó với các DBA. Họ vẫn có thể ngồi lặng lẽ lướt web trong văn phòng lớn của họ trong khi bạn nhận được một số công việc làm.

0

Amazon SimpleDB có thể hữu ích cho những ai cần một cơ sở dữ liệu phi quan hệ để lưu trữ dữ liệu nhỏ hơn, phi cấu trúc. Amazon SimpleDB đã hạn chế dung lượng lưu trữ tới 10GB trên mỗi miền. Amazon SimpleDB cung cấp sự đơn giản và linh hoạt. SimpleDB tự động lập chỉ mục tất cả dữ liệu. Giá Amazon SimpleDB dựa trên mức sử dụng hộp thực tế của bạn. Bạn có thể lưu trữ bất kỳ dữ liệu chuỗi UTF-8 nào trong Amazon SimpleDB.