MongoDB là lựa chọn đúng đắn trong trường hợp của tôi? [đóng cửa]

Tôi sẽ xây dựng dự án thực tế đầu tiên của mình trong Rails bao gồm một ứng dụng web gồm 3 phần chính:

• Phần tĩnh không có cơ sở dữ liệu được sử dụng
• Phần đăng ký người dùng sẽ yêu cầu cơ sở dữ liệu và tôi có thể sử dụng MySQL vì mỗi hàng của người dùng sẽ có cùng các trường
• "Ứng dụng" nơi người dùng sẽ có thể tạo, sắp xếp, chỉnh sửa ... các mục trong bộ sưu tập và chia sẻ chúng với những người dùng khác

Sẽ có một số loại mặt hàng và mỗi loại sẽ có các tùy chọn khác nhau, ví dụ tôi có thể có các mục "video" với các tùy chọn sau:

• Tôi
• tên người dùng
• bộ sưu tập
• tiêu đề
• nền tảng (nếu được nhúng)
• url (nếu được nhúng)
• tên tệp (nếu được lưu trữ trên ứng dụng của tôi)
• kích thước tệp (id được lưu trữ trên ứng dụng của tôi)

và các mục "bản đồ":

• Tôi
• tên người dùng
• bộ sưu tập
• tiêu đề
• nền tảng (google maps, bing maps ...)
• vị trí
• url
• kích thước bản đồ

Khi bạn có thể sử dụng MySQL cho các mục, tính linh hoạt của MongoDB có thể hữu ích vì mỗi mục có thể cần các tùy chọn khác nhau sau đó một mục khác

Cho đến nay tôi luôn sử dụng PHP và MySQL (luôn được lưu trữ chia sẻ cho các dự án nhỏ) và khả năng mở rộng là một từ hoàn toàn mới đối với tôi.

Tôi có thời gian để học nhưng tôi muốn có thể làm một cái gì đó cụ thể trong khoảng 1 tháng.

Tôi đã đọc rất nhiều về MongoDB và NoQuery so với RDMS và MySQL và sau khi dùng thử, tôi phải nói rằng tôi thích cách MongoDB hoạt động: không có bảng, không có hàng và tài liệu JSON như vậy:

• Trong tình huống của tôi, bạn sẽ làm gì? tại sao?
• Về khả năng mở rộng có thể có vấn đề với MongoDB? nếu có khi (về kích thước DB) và những vấn đề này có thể làm chậm ứng dụng của tôi đáng kể không?

Chỉnh sửa: ứng dụng sẽ hoạt động như thế nào

Vì nhiều người hỏi đây là cách tôi muốn ứng dụng hoạt động:

1. Một người dùng đăng ký
2. Anh ấy đã đăng nhập
3. Anh ấy tạo ra bộ sưu tập đầu tiên của mình, nơi anh ấy có thể tạo ra các vật phẩm vô hạn
4. Các mục có nhiều loại và mỗi loại cần lưu dữ liệu khác nhau trong cơ sở dữ liệu và loại mục có thể được thêm hoặc sửa đổi

Người dùng có thể tạo các bộ sưu tập và vật phẩm khác bên trong nó.

Vì vậy, chúng tôi có CRUD cho các bộ sưu tập và vật phẩm bên trong chúng và mỗi bộ sưu tập / vật phẩm được giới thiệu đến một người dùng cụ thể

Vấn đề chính với MySQL là nó không có lược đồ linh hoạt, có cách nào để giải quyết vấn đề này (một cách giải quyết?)?

Suy nghĩ về NoQuery, nghi ngờ duy nhất tôi có là về việc tham gia, ví dụ như được cung cấp một phần chọn lọc nào đó tôi muốn truy xuất dữ liệu liên quan đến Người dùng có trường id = user_id trong bộ sưu tập

EDIT: Ý tưởng để tiếp tục sử dụng MySQL

Tạo một trường trong bảng "mục" với các cài đặt tùy chọn, mỗi cài đặt chia cho một | hoặc một biểu tượng khác.

Sau đó, tôi sẽ lưu ở đâu đó một cấu trúc của từng mục cài đặt tùy chọn, ví dụ loại mục "ghi chú" cần hai cài đặt tùy chọn "màu" và "lạ_số", khi tôi nhận được dữ liệu từ MySQL, tôi sẽ chia trường cho các cài đặt tùy chọn thành một mảng biết rằng mục đầu tiên trong mảng là cho "màu" và vv.

Bạn nghĩ sao? Có vấn đề với giải pháp đó? bạn có ý tưởng nào khác không?

Chúng tôi có thể không thể giúp bạn cho đến khi bạn cho chúng tôi biết bạn dự định làm gì với ứng dụng. Cơ sở dữ liệu quan hệ tốt cho những thứ nhất định và cơ sở dữ liệu NoQuery tốt cho những thứ khác.

Như ai đó đã từng nói với tôi ở đây trên SO:

phần quan hệ của DB quan hệ được tối ưu hóa hơn nhiều so với một số phần khác

Nó có nghĩa là bạn có thể sử dụng một cơ sở dữ liệu quan hệ nếu điều đó có vẻ phù hợp với các trường hợp sử dụng của bạn. Đừng tiếp tục với MongoDB vì tính linh hoạt / khả năng mở rộng của nó. Đây là dòng đầu tiên về MongoDB trên Wikipedia:

MongoDB (từ "humongous") là một hệ thống cơ sở dữ liệu NoQuery định hướng tài liệu nguồn mở.

Bạn có thực sự có ý định sử dụng DB theo định hướng tài liệu không? Nếu có một số đồ thị trong các trường hợp sử dụng của bạn, thì rất có thể bạn sẽ tìm kiếm một cơ sở dữ liệu đồ thị như Neo4j. Hoặc bạn có thể sử dụng tốt nhất cả SQL và NoQuery cùng nhau như một số người làm.

BTW, tôi cũng đang thực hiện một dự án trong đó tôi sử dụng các phần tốt nhất của cả SQL và NoQuery.

EDIT: Tôi nói lại một lần nữa:

Kiểm tra các Neo4j vs Hadoop phần này bài viết. Nó nói rằng:

Về nguyên tắc, Hadoop và các cửa hàng Key-Value khác chủ yếu liên quan đến các cấu trúc dữ liệu tương đối phẳng . Đó là, chúng cực kỳ nhanh và có thể mở rộng liên quan đến việc truy xuất các đối tượng đơn giản, như các giá trị, tài liệu hoặc thậm chí các đối tượng.

Nhắc đến cùng một bài viết, bạn có thực sự cần một cấu trúc dữ liệu phẳng mà bạn sẽ dùng cho MongoDB không? Điều này cuối cùng phụ thuộc vào các trường hợp sử dụng chi tiết của bạn, cách bước 3 và 4 sẽ được thực hiện.

Ngoài ra, bạn có thể muốn giới thiệu những câu hỏi sau:

/programming/2124274/mongodb-what-to-ledge-b Before-USE

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( Chắc chắn kiểm tra câu trả lời hàng đầu / được chọn của câu hỏi thứ hai. Bạn đang ở trong tình huống khó xử mà vấn đề này có thể giải quyết. )

Tôi đoán những câu hỏi này có tất cả các thông tin bạn muốn biết. Cuối cùng, chính bạn là người sẽ phải quyết định xem đó là MongoDb hay cái gì khác, chúng tôi chỉ có thể đề xuất. Những người duy nhất biết trường hợp sử dụng chi tiết của bạn là bạn và nhóm của bạn.

EDIT AGAIN (đối với phần MySQL): Như tôi đã hiểu, bạn đang dự định lưu trữ một cái gì đó trong db và tách chúng thông qua một dấu phân tách. Điều này trình bày 2 vấn đề:

1. Bạn cần xử lý thêm bất kỳ đầu vào nào sẽ có dấu phân cách.
2. Phần lưu trữ quan hệ của cơ sở dữ liệu quan hệ được tối ưu hóa hơn nhiều so với phần khớp chuỗi. Tôi sẽ không đi đến một lược đồ mà tôi cần thực hiện khớp chuỗi trong cơ sở dữ liệu để có được một số kết quả cụ thể. Một lần nữa tôi nhấn mạnh:

   phần quan hệ của DB quan hệ được tối ưu hóa hơn nhiều so với một số phần khác (ví dụ: khớp chuỗi)

3. Không sử dụng các thuộc tính đa trị. Mọi người thường sợ chúng.

Tôi thấy câu hỏi này rất nhiều. Nó dường như luôn luôn được coi là / hoặc. MongoDB là một công cụ mới tuyệt vời. Đôi khi nó dường như cũng là công cụ sáng bóng cho mọi thứ và đó có thể là một lựa chọn kém trong trải nghiệm của tôi.

Tôi nghĩ rằng sự kết hợp tốt nhất chắc chắn là CẢ và tôi muốn khen ngợi bạn về cách tiếp cận sử dụng mylsql của tôi cho một số phần, chẳng hạn như người dùng, nhưng sử dụng MongoDB cho các phần khác vì tôi cảm thấy việc xác thực và ủy quyền được thực hiện tốt nhất với myQuery và có một tấn các ví dụ và mô-đun làm điều này thực sự tốt.

Đối với phần 'số lượng lớn các mặt hàng', đó là nơi bạn muốn xem xét sử dụng mongoDB nếu âm lượng của bạn cao và / hoặc chủ yếu là đọc và / hoặc đó là dữ liệu không có cấu trúc.

Tôi khuyên bạn không nên dựa vào quyết định của bạn về tính linh hoạt không có lược đồ của Mongo. Các lược đồ SQL và sql xuất phát từ nhu cầu có dữ liệu có cấu trúc và có thể thực hiện các phép tính và biến đổi chỉ có thể có với cấu trúc như vậy. Tôi đã học được điều này từ 5 năm làm việc trong vai trò kho dữ liệu. Tôi sẽ chỉ tìm đến MongoBD cho vấn đề hiệu suất. Nếu bạn đang hoặc đang mong đợi một khối lượng lớn người dùng và yêu cầu, giả sử 100.000 người dùng và 20 yêu cầu một giây, tôi sẽ sử dụng mongoDB, nếu không tôi sẽ thử và ở lại với sql. Trong nhiều trường hợp, tôi sẽ sử dụng myQuery với khối lượng thấp, và sau đó, khi khối lượng, thu nhập và cơ sở hạ tầng hỗ trợ nó, hãy chuyển sang Oracle, trước khi trộn vào mongoDB. Tôi đồng ý rằng bạn không nên cố gắng xử lý các vấn đề về âm lượng trước khi bạn trải nghiệm chúng, tuy nhiên nếu bạn có ý tưởng công bằng về nơi bạn đang hướng đến và không ' Tôi muốn viết lại mọi thứ một nửa ở đó, rất có ý nghĩa để chọn các công nghệ phù hợp ở bên ngoài. Chỉ cần nhớ rằng nếu bạn thực sự có khối lượng lớn đó, có một số lượng lớn các tùy chọn và công nghệ ở tất cả các cấp độ của ngăn xếp mà bạn sẽ tìm cách sử dụng.

Có những nhược điểm của dữ liệu có cấu trúc lỏng lẻo. Tôi sử dụng tương tự bãi đậu xe ở đây. không có vạch chia nào là tuyệt vời cho 3 chiếc xe đầu tiên đi vào, nhưng khi nhiều xe hơn đi vào, rất nhiều sự vô tổ chức bắt đầu xảy ra và cố gắng đỗ hoặc dễ dàng đếm xe và giữ làn đường miễn phí trở thành cơn ác mộng. Tổ chức việc này sẽ làm việc lên phía trước - đánh dấu các đường và dải phân cách và luồng giao thông, v.v. nhưng nó được đền đáp. Đôi khi mọi thứ thay đổi tất nhiên (xe hơi trở nên lớn hơn) và bạn phải thực hiện một số thay đổi - sơn lại dòng. Cộng với thời gian xuống tiêu chuẩn cho việc sơn lại và bảo trì hàng năm.

Khía cạnh thiết kế lược đồ có lẽ sẽ là rào cản lớn nhất đối với người dùng mysql truyền thống. Tôi nghĩ rằng trang MongoDb về thiết kế lược đồ sẽ giúp điều đó. Điểm cuối cùng của tôi là mọi công nghệ bạn thêm vào hỗn hợp đều tăng thêm độ phức tạp. Thường có những người ủng hộ rất lớn cho bất kỳ tác phẩm nào sẽ nói rằng bạn "phải" sử dụng nó, nhưng tôi đã thấy rằng một yếu tố thực sự lớn chỉ là có bao nhiêu phần. Nó bao hàm nhiều điểm có thể thất bại hơn và hầu hết các cơ sở tri thức cần thiết cho bất kỳ ai khác phải biết để làm việc với nó.

fyi Rick Obsorne có một sơ đồ so sánh khá tuyệt vời , khá độc đáo!

Tôi thấy rất nhiều đối số hợp lệ ở đây cho NoQuery vs MySQL. Một liên kết còn thiếu là về quy mô: Nếu bạn muốn thực sự mở rộng quy mô và muốn thực hiện với cơ sở dữ liệu nội bộ, bạn sẽ cần rất nhiều kiến ​​thức về cơ sở dữ liệu. Có quá nhiều câu chuyện kinh dị ngoài kia, nơi mọi người đã thất bại trong việc cố gắng thực hiện một hệ thống sẽ mở rộng vô tận.

Nếu bạn thực sự chọn đi theo con đường NoQuery (và sẵn sàng chịu các chi phí đi kèm - như không tham gia), hãy xem xét AWS DynamoDB (http://aws.amazon.com/dynamodb/). Ở đây bạn có thể quên đi toàn bộ phần mở rộng cơ sở dữ liệu của nó và tập trung vào ứng dụng của bạn. Chúc may mắn.

Tuyên bố miễn trừ trách nhiệm: Tôi là nhà phát triển trong nhóm AWS DynamoDB, nhưng tôi thực sự tin tưởng vào sản phẩm của chúng tôi. Hãy thử đi :)

Vì vậy, thiết kế của bạn được lưu vào cơ sở dữ liệu của bạn hai loại đối tượng khác nhau:

• Đối tượng người dùng (luôn có các trường).
• Các đối tượng ứng dụng (có thể có các trường khác nhau). Một ứng dụng sẽ chỉ thuộc về một người dùng.

Một bộ sưu tập có thể hoặc không được tôi tạo ra như một đối tượng khác, vì nó chỉ là một thẻ để nhóm các ứng dụng khác nhau. Để tranh luận, giả sử không có bộ sưu tập nào và người dùng chỉ có một danh sách các ứng dụng.

Mặc dù tôi nghĩ là có thể đạt được trên MySQL, nhưng trong MongoDB, bạn sẽ linh hoạt hơn về cấu trúc của các đối tượng ứng dụng và có lẽ nó sẽ ánh xạ tự nhiên hơn biểu diễn của bạn vào cơ sở dữ liệu, làm cho mã đơn giản hơn.

Trong MySQL, bạn sẽ gặp vấn đề với các định dạng khác nhau cho các ứng dụng khác nhau, nhưng có thể. Một vài ý tưởng:

• Bạn có thể tạo một bảng trung gian với tất cả thông tin chung giữa tất cả các đối tượng (id, user_id, title, v.v.), sau đó là loại, do đó bạn có thể tìm kiếm nó trên một bảng khác chỉ với các trường không phổ biến cho định dạng đó (ví dụ: file_name và file_size cho các tập tin). Bạn sẽ cần tạo một bảng khác nhau cho mỗi định dạng khác nhau. Nếu cả hai bảng được lập chỉ mục bởi app_id (Khóa chính), nó sẽ đủ nhanh, vì việc truy cập một bảng theo giá trị được lập chỉ mục là nhanh.
• Bạn có thể mã hóa dữ liệu theo một số định dạng và lưu trữ được chuẩn hóa. Ví dụ: mã hóa dữ liệu không phổ biến trong JSON dưới dạng chuỗi và lưu trữ trên trường VARCHAR. Hãy cẩn thận với kích thước của trường đó để bạn không bị hết dung lượng. Định dạng có thể phức tạp (JSON) hoặc đơn giản (chỉ các giá trị được phân tách bằng dấu phẩy)
• Bạn có thể tạo các trường "chung" khác nhau, như int1, int2, str1, str2 và xác định str1 cho loại ứng dụng là "file_name" trong khi đối với loại khác có thể là "location".

Trên MongoDB, có thể đơn giản như chỉ sử dụng hai bộ sưu tập MongoDB, một cho người dùng và một cho các ứng dụng. Giả sử một số loại giới hạn (không phải như vậy, như bạn đã mô tả, nhưng chỉ để nói), bạn thậm chí có thể lưu trữ các ứng dụng bên trong đối tượng người dùng, dưới dạng một danh sách. Lưu trữ và truy xuất dữ liệu là tự nhiên hơn, vì bạn có thể lưu trữ bất kỳ loại đối tượng nào, bất kể đó là các trường. Bạn có thể tìm kiếm theo user_id để có được tất cả các ứng dụng thuộc về người dùng. Trên MongoDB, dù sao bạn cũng có khả năng thực hiện các truy vấn tham gia, nhưng trong trường hợp này tôi nghĩ các truy vấn cơ bản sẽ truy xuất người dùng và truy xuất các ứng dụng liên quan đến người dùng. Nếu bạn dự định thực hiện nhiều nội dung như "cung cấp cho tôi những người dùng có nhiều hơn hai bộ sưu tập với ba ứng dụng hoặc ít hơn mỗi ứng dụng", bạn sẽ phải tạo ra nó không phải là truy vấn tham gia, nhưng là một quá trình trong mã, và sẽ ít tự nhiên hơn trong cơ sở dữ liệu quan hệ và có thể mất nhiều thời gian hơn để xử lý. Nếu bạn muốn tìm kiếm các tham số (ví dụ: cung cấp cho tôi tất cả các ứng dụng thuộc về một người dùng cụ thể; cung cấp cho tôi tất cả các ứng dụng thuộc loại X), điều đó khá dễ dàng trên MongoDB và không cần sử dụng các phép nối.

Tôi không chắc về sự hỗ trợ của MongoDB trên Rails. Tôi đã sử dụng nó trong Python và JavaScript.

EDIT: Đã thêm nhận xét về thời gian khi truy cập hai bảng và một tùy chọn MySQL khác

Tôi sẽ nói sử dụng công nghệ mà bạn biết rõ nhất, đặc biệt nếu đó là một dự án thực sự và bạn muốn đẩy nó ra nhanh chóng. Sử dụng MySQL và Mongo đều sẽ đi kèm với những lợi ích và đau đầu của riêng nó. Đã làm việc với cả hai, tôi cũng sẽ nói thêm rằng việc chuyển từ MySQL sang Mongo không khó lắm nếu bạn tuân theo các nguyên tắc thiết kế tốt.

Như đã nói, một lý do chính đáng để sử dụng MongoDB trong trường hợp của bạn là dữ liệu của bạn. Như bạn đã đề cập, bạn sẽ có một số loại mục nhập khác nhau cho các bộ sưu tập của mình: bản đồ, video, v.v. Nếu bạn thực hiện điều này bằng RDBMS, bạn có 3 cách tiếp cận:

• bảng mỗi loại: mỗi bảng chứa các cột cụ thể cho từng loại đối tượng

  Nhược điểm : N truy vấn để tìm kiếm trên tất cả các loại dữ liệu.

  Ưu điểm : thiết kế OO tốt, dễ bảo trì

• bảng duy nhất: một bảng lớn chứa tất cả các thuộc tính có thể cho tất cả các loại, với hầu hết chúng là null cho bất kỳ mục cụ thể nào

  Nhược điểm : Thay đổi thành bất kỳ đối tượng nào sẽ yêu cầu thay đổi bảng, đau đớn khi bảng trở nên lớn. Khó duy trì.

  Ưu điểm : Dễ thực hiện.

• bảng lõi với dữ liệu meta: bạn có một bảng duy nhất với các thuộc tính cốt lõi, nói tiêu đề, ngày tháng và bảng siêu dữ liệu với các cặp giá trị khóa cho các thuộc tính bổ sung

  Nhược điểm : Hai truy vấn để lấy tất cả dữ liệu cho một đối tượng.

  Ưu điểm : Vô cùng linh hoạt, không khó thực hiện.

Tôi đã sử dụng từng phương pháp này trước đây và tôi có thể nói không có cách nào là tự nhiên khi làm việc với Mongo. Dữ liệu của bạn có thể sẽ trông giống như thế này:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

Nhưng bạn sẽ không thực sự phải lo lắng về thiết kế lược đồ, vì các đối tượng miền của bạn có thể được duy trì trực tiếp như vậy. MongoDB về cơ bản là kho đối tượng của bạn mà bạn có thể truy vấn.

Nhận thấy tôi đã bỏ qua bất kỳ cuộc thảo luận nào về so sánh hiệu năng giữa MySql và Mongodb. Mặc dù bạn phải luôn luôn ghi nhớ hiệu suất, nhưng bạn sẽ không thể đưa ra quyết định một cách hiệu quả trừ khi bạn biết mẫu truy cập dữ liệu. Bất kỳ dự án tốt nào cũng có thể sẽ trải qua một vài lần lặp lại tái cấu trúc khi nó phát triển và những thách thức mới xuất hiện. Đừng lo lắng về hiệu suất trước khi hoàn thành và chọn công cụ bạn biết rõ nhất và bắt đầu viết mã.

Biên tập

Để trả lời câu hỏi cụ thể của bạn về việc sử dụng MySQL và giữ các thuộc tính trong cùng một trường bằng cách sử dụng "|". Đừng làm điều này. Cách tiếp cận này sẽ cung cấp cho bạn nhiều vấn đề hơn nó giải quyết. Trước hết, bạn sẽ không thể truy vấn các thuộc tính riêng lẻ bằng MySql. Thứ hai, nó thêm quá nhiều phức tạp vào lớp truy cập dữ liệu của bạn. Thay vào đó, hãy sử dụng cách tiếp cận loại trên mỗi bảng hoặc cách tiếp cận dữ liệu meta. Nếu bạn đã làm việc với WordPress trước đó, nó sẽ sử dụng phương pháp siêu dữ liệu:

• bảng người dùng + usemeta cho người dùng
• bảng bài + bảng postmeta

Điều này làm cho cấu trúc dữ liệu cực kỳ linh hoạt và vẫn có thể truy vấn với tốc độ hợp lý.

Bài viết dưới đây cung cấp kết quả tốt khi so sánh MySQL và MongoDB về mặt chọn, tìm nạp và chèn, xem xét lượng dữ liệu trong cơ sở dữ liệu và lượng dữ liệu được truy xuất. Kết quả cho thấy sự hoàn hảo tuyệt vời cho MongoDB liên quan đến "phần chèn", nhưng các trường hợp khác MySQL thắng. Xem bên dưới:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

Tôi đã có một trải nghiệm sử dụng MongoDB mà tôi nghĩ rằng đó là một giải pháp tốt. Tôi đã sử dụng nó để chèn hàng ngàn bộ sưu tập mỗi ngày. Kết hợp với giải pháp Solr (giải pháp bộ đệm, được cập nhật một lần mỗi ngày), tôi có thể truy xuất dữ liệu MongoDB theo id bộ sưu tập khi cần, vì vậy tôi không cần phải chọn nhanh. Vì vậy, xem xét bạn phải xử lý nhiều phần chèn và không cần quan tâm đến việc chọn và tìm nạp, MongoDB có thể là một ý tưởng tuyệt vời, nó sẽ phụ thuộc vào từng trường hợp và phân tích tốt.