cơ sở dữ liệu NoSQL đang có để giải quyết một vài điều, chủ yếu là:
(buzz) BigData => nghĩ TB, PB, vv ..
Làm việc với Hệ thống phân phối/datasets => nói rằng bạn có 42 sản phẩm, vì vậy, 13 sản phẩm sẽ sống ở trung tâm dữ liệu Chicago, 21 ở NY và 8 ở một nơi khác ở Nhật Bản, nhưng khi bạn truy vấn tất cả 42 sản phẩm, bạn sẽ không cần biết vị trí của chúng: NoSQL DB sẽ. Điều này cũng cho phép để thu hút nhiều hơn nữa sức mạnh não (máy chủ) để giải quyết vấn đề tính toán cứng [dường như không nó sẽ phù hợp với trường hợp sử dụng của bạn, nhưng nó là một điều thú vị cần lưu ý]
Phân vùng => có bạn DB dễ dàng phân phối, ngoài 8 sản phẩm mát mẻ ở Nhật Bản, cũng cho phép sao chép dữ liệu dễ dàng, vì vậy 42 sản phẩm đó sẽ được nhân rộng với hệ số 3, nghĩa là bạn DB sẽ có 3 bản sao cho mỗi sản phẩm. Do đó nếu một cái gì đó đi xuống, không có vấn đề => đây là một bản sao có sẵn. Đây là nơi các cơ sở dữ liệu NoSQL thực sự tỏa sáng so với RDBMS. Cấp cho bạn có thể phân mảnh, phân vùng và cụm Oracle/MySQL/PostgreSQL/etc .. NHƯNG nó là một số quy trình phức tạp hơn và thường là một nhức đầu bảo trì cho hầu hết mọi người bạn sử dụng.
(câu hỏi của bạn)
Sẽ có xung quanh hàng ngày tối thiểu 1000 người sử dụng
1000 người sử dụng hàng ngày là một khối lượng rất thấp, trừ khi bạn chọn một giải pháp NoSQL đó là viết ngày hôm qua lúc 3 giờ sáng như một khái niệm chứng minh, không nên lo lắng ở đây. Nhưng nếu bạn thành công và sẽ có 100.000.000 người dùng trong một vài tháng, NoSQL sẽ đơn giản hơn để mở rộng quy mô.
Sự sẵn có có phải là sự cố không?
giải pháp NoSQL rắn cho phép bạn chỉ định một cái gì đó được gọi là một quorum: "Số lượng bản sao mà phải đáp ứng một yêu cầu đọc hoặc viết trước khi nó được coi là thành công". Một số giải pháp cũng làm điều gì đó gọi là hinted handoff: "nút lân cận tạm thời tiếp quản hoạt động lưu trữ cho nút không thành công". Nói chung, bạn sẽ có thể kiểm soát tính khả dụng tùy thuộc vào yêu cầu của bạn.
(từ bình luận của bạn)
- Chúng tôi đang có kế hoạch mở rộng. Và không muốn cơ sở dữ liệu là một ràng buộc
Expanding là một thuật ngữ rất tương đối. "Ngành công nghiệp tài chính khá mở rộng", và họ vẫn chủ yếu sử dụng RDBMS cho các hoạt động hàng ngày. Facebook sử dụng MySQL. Các ngân hàng lớn, tôi đã làm việc cho, sử dụng Oracle/MySQL/PostgreSQL/DB2/etc .. và chỉ một số người trong số họ sử dụng NoSQL, nhưng KHÔNG cho dữ liệu đòi hỏi sự nhất quán 100% mọi lúc. Ngay cả Facebook chỉ sử dụng Cassandra cho những thứ như "tìm kiếm hộp thư đến". Nhưng nếu bằng cách mở rộng bạn có nghĩa là nhiều dữ liệu hơn và nhiều người dùng hơn (yêu cầu, kết nối, vv ..), NoSQL sẽ dễ dàng hơn nhiều trong việc mở rộng quy mô. Một lần nữa, nó không có nghĩa là bạn không thể mở rộng quy mô RDBMS, nó chỉ là tẻ nhạt/phức tạp hơn.
- Từ những gì tôi đã đọc, không có cơ sở dữ liệu SQL, chúng tôi không phải suy nghĩ về schema rất nhiều
Theo kinh nghiệm của tôi, nếu tôi xây dựng một hệ thống mà là bất kỳ tốt, tôi LUÔN LUÔN phải suy nghĩ về lược đồ. Cơ sở dữ liệu NoSQL cho phép bạn nhiều hơn một chút linh hoạt với dữ liệu bạn vẫn tồn tại, nhưng điều đó không có nghĩa là bạn nên suy nghĩ về lược đồ này ít hơn. Nghĩ đến lập chỉ mục dữ liệu chẳng hạn, hoặc sharding nó trên nhiều cụm, hoặc thậm chí hợp đồng/giao diện mà bạn có thể tiếp xúc với khách hàng, vv ..
- Việc bảo trì cần thiết cho cơ sở dữ liệu NoSQL là rất ít
Tôi sẽ không nói điều này là đúng nói chung, trừ khi chúng tôi là nói về BigData. Lấy PostgreSQL chẳng hạn. Nó là một phần mềm cực kỳ tuyệt vời, đó là khá dễ dàng để làm việc và duy trì. Một điểm cộng khác cho RDBMS world => mọi người cảm thấy A LOT thoải mái hơn với SQL. Vì lý do đó, ví dụ, Cassandra guys, phát hành CQL trong 0,8, đó là một tập hợp con rất hạn chế của SQL. Các thuật ngữ như maintenance cũng phải đứng vai với các cụm từ như Talent, Knowledge, Expertise. Vì nếu bạn sử dụng Cassandra, ví dụ, cô gái đó là một "bảo trì cao", nhưng không phải dành cho những kẻ từ DataStax, những người có Expertise, nhưng bạn sẽ phải trả tiền cho điều đó.
của bạn Câu hỏi chính
- Tôi đã đọc trong một blog rằng cơ sở dữ liệu NoSQL là không tốt cho tiền trực tuyến giao dịch ví dụ:(Sản phẩm của tôi có giao dịch tiền trực tuyến)
Nếu bạn không biết sản phẩm của mình là gì, thật khó để nói liệu cơ sở dữ liệu NoSQL có phù hợp hay không. Nếu mục tiêu chính của sản phẩm là "Giao dịch tiền trực tuyến", thì tôi sẽ đề xuất đối với Cơ sở dữ liệu NoSQL (ít nhất là ngày hôm nay trong năm 2011). Nếu "Giao dịch tiền trực tuyến" chỉ là một trong những yêu cầu, nhưng không phải "cốt lõi" của sản phẩm, tùy thuộc vào "lõi" là gì, bạn có thể thử cơ sở dữ liệu NoSQL và ví dụ như sử dụng dịch vụ bên ngoài để xử lý (ví dụ: Google Checkout, v.v.) các giao dịch của bạn với sự nhất quán được đảm bảo. Là một lưu ý kỹ thuật, nếu vấn đề bạn đang cố gắng giải quyết lợi ích từ việc được giải quyết với phân phối, tôi sẽ đề nghị cơ sở dữ liệu được viết bằng Erlang (ví dụ Riak, CouchDB, vv), vì Erlang là một ngôn ngữ đã được giải quyết thành công nhất của những thứ được phân phối trong nhiều thập kỷ.
Bạn nên có giao dịch trong các hệ thống như vậy. Bạn có thể mô phỏng các giao dịch với nosql nhưng bạn sẽ phát minh ra bánh xe. – varela
@varela: Bạn có thể làm rõ điểm của bạn được không, tôi không thể hiểu chính xác bạn nói gì. – Akamad007
vấn đề nhất là đồng thời. Nếu bạn muốn ví dụ substruct tiền, hơn bạn không thể chỉ 1) kiểm tra số tiền có sẵn 2) substruct nếu người dùng có tiền. Bạn cần khóa tài khoản người dùng từ những thay đổi đầu tiên bằng cờ đặc biệt và sau đó thực hiện các thao tác. Với cơ sở dữ liệu SQL, bạn có các cách tiêu chuẩn để thực hiện việc này. – varela