Tại sao mongodb được gọi là lược đồ ít cơ sở dữ liệu?

Hầu hết những người thiết kế cơ sở dữ liệu MongoDB đều xuất thân từ nền tảng cơ sở dữ liệu quan hệ. Việc chuyển từ thế giới của các bảng, liên kết và chuẩn hóa sang cách tiếp cận dựa trên tài liệu của MongoDB và các cơ sở dữ liệu NoSQL khác có thể đồng thời vừa thoải mái vừa khó khăn

MongoDB được thiết kế cho tốc độ. Bạn có thể nhúng tất cả các loại dữ liệu và cấu trúc vào bộ sưu tập tài liệu dễ truy vấn. Để nhận ra tiềm năng hiệu suất của MongoDB, bạn phải thiết kế các bộ sưu tập để phù hợp với các mẫu truy cập phổ biến nhất của ứng dụng

Trong một bài đăng vào tháng 8 năm 2013 trên Blog hiệu suất MySQL của Percona, Stephane Combaudon sử dụng ví dụ về cơ sở dữ liệu hộ chiếu đơn giản. Trong MySQL, thông thường bạn sẽ tạo một bảng “mọi người” với các cột “id” và “tên”, và một bảng “hộ chiếu” với các cột “id”, “people_id”, “country” và “valid_until”. Sau đó, bạn sẽ sử dụng phép nối giữa các bảng để chạy truy vấn

Cơ sở dữ liệu hộ chiếu cơ bản trong MySQL có thể sử dụng phép nối giữa hai bảng riêng biệt để truy vấn cơ sở dữ liệu. Nguồn. Blog hiệu suất MySQL

Ngược lại, cơ sở dữ liệu MongoDB cho cùng mục đích có thể sử dụng một bộ sưu tập duy nhất để lưu trữ tất cả thông tin hộ chiếu, nhưng điều này gây khó khăn cho việc xác định thuộc tính nào được liên kết với đối tượng nào

Cơ sở dữ liệu hộ chiếu tương tự trong MongoDB có thể đặt tất cả các thành phần dữ liệu trong một bộ sưu tập duy nhất. Nguồn. Blog hiệu suất MySQL

Ngoài ra, bạn có thể nhúng thông tin hộ chiếu vào trong thông tin người hoặc ngược lại, mặc dù đây có thể là vấn đề nếu một số người không có hộ chiếu, chẳng hạn như “Cinderella” trong ví dụ bên dưới

Cơ sở dữ liệu hộ chiếu MongoDB có thể nhúng thông tin người vào bên trong thông tin hộ chiếu, thông qua thiết kế này có thể không tối ưu hóa hiệu suất. Nguồn. Blog hiệu suất MySQL

Trong ví dụ này, bạn có nhiều khả năng truy cập thông tin mọi người hơn là thông tin hộ chiếu, do đó, việc có hai bộ sưu tập riêng biệt sẽ có ý nghĩa vì nó giữ ít dữ liệu hơn trong bộ nhớ. Khi bạn cần dữ liệu hộ chiếu, chỉ cần thêm liên kết vào ứng dụng

Sự nguy hiểm của việc cố gắng 1. 1 chuyển đổi của DB quan hệ

Nhiều kỹ năng bạn đã học được trong việc phát triển cơ sở dữ liệu quan hệ chuyển đổi suôn sẻ sang mô hình dựa trên tài liệu của MongoDB, nhưng ngoại lệ chính là thiết kế lược đồ, như Andrew C của InfoWorld. Oliver giải thích trong một bài báo ngày 14 tháng 1 năm 2014. Nếu bạn thử 1. 1 của lược đồ RDBMS sang MongoDB, bạn gần như chắc chắn sẽ gặp sự cố về hiệu suất

Oliver chỉ ra rằng hầu hết các khiếu nại về MongoDB là do những người chọn sai lược đồ đối với cơ sở dữ liệu tập trung vào tài liệu. một 1. 1 cổng từ bảng tới tài liệu dễ gây ra lỗi kết nối, mất tính nguyên tử (mặc dù bạn có thể có ), nhiều thao tác cần thiết hơn và không nhận ra lợi ích về hiệu suất của tính năng song song

Bằng cách không thực thi lược đồ trên tài liệu hoặc lược đồ theo cách mà các lược đồ được xác định trước được yêu cầu trong RDBMS, cơ sở dữ liệu của bạn về mặt lý thuyết dễ dàng phát triển và sửa đổi hơn. Trong thực tế, mọi thứ không phải lúc nào cũng diễn ra theo cách này. Trong số các vấn đề về MongoDB được Russell Smith kiểm tra trong một bài đăng trên Rainforest Blog từ tháng 11 năm 2012 và được cập nhật vào ngày 29 tháng 7 năm 2014, có một lỗi trong thiết kế lược đồ mà nó xứng đáng được chú ý

Tất nhiên, cơ sở dữ liệu MongoDB không tồn tại biệt lập. Các dịch vụ như dịch vụ cơ sở dữ liệu Morpheus (DBaaS) được thiết kế để đáp ứng nhu cầu trong thế giới thực của các tổ chức dựa trên sự kết hợp của cơ sở dữ liệu SQL, NoSQL và trong bộ nhớ. Trên thực tế, Morpheus là DBaaS đầu tiên và duy nhất cho phép bạn cung cấp, triển khai và lưu trữ các cơ sở dữ liệu MySQL, MongoDB, Redis và ElasticSearch không đồng nhất

Với Morpheus, bạn có thể hiển thị một phiên bản của bất kỳ cơ sở dữ liệu nào, giám sát và tối ưu hóa hiệu suất của nó chỉ trong vài giây thông qua một bảng điều khiển duy nhất. Và tất cả các phiên bản cơ sở dữ liệu bao gồm một bộ bản sao đầy đủ miễn phí. Truy cập trang web Morpheus để đăng ký tài khoản miễn phí

Sử dụng lược đồ hay không lược đồ, đó là câu hỏi mà Rob Ludwig đưa ra trong bài viết Viết nội dung này. Bạn có Viết nội dung để viết về cơ sở dữ liệu ở đây không?

Theo một cách nào đó, việc chọn sử dụng lược đồ hay không cũng tương tự như việc chọn sử dụng ngôn ngữ lập trình kiểu mạnh hay kiểu động. sự đánh đổi chính là giữa tính linh hoạt và sự chặt chẽ. Giống như một ngôn ngữ được nhập động cho phép bạn nhanh chóng lặp lại và phát triển ứng dụng của mình, việc chuyển sang ngôn ngữ không lược đồ cho phép bạn thay đổi mô hình dữ liệu của mình với rất ít va chạm

Tuy nhiên, các kiểm soát nghiêm ngặt và tính chính xác được áp đặt bởi các lược đồ và bởi các ngôn ngữ được nhập cho phép bạn giữ các nhóm lớn nhà phát triển trên cùng một trang và có thể cho phép bạn bắt lỗi sớm hơn trong chu kỳ phát triển. Mọi ngôn ngữ có ODM đầy đủ tính năng cho MongoDB cũng có thư viện để thực thi các lược đồ trong mã ứng dụng, vì vậy bạn luôn có tùy chọn đưa lược đồ vào dự án của mình. Để hiểu đầy đủ hơn về sự đánh đổi, bạn nên xem xét kỹ hơn những ưu và nhược điểm của lược đồ

Hoang dã & Miễn phí. MongoDB không có lược đồ

Việc chuyển sang "không lược đồ" là một cách gọi sai vì có rất ít trường hợp sử dụng sản xuất mà dữ liệu hoàn toàn không có cấu trúc. Hầu hết dữ liệu Mongo thường có cấu trúc ngụ ý. Trên thực tế, MongoDB gần đây đã công bố phiên bản 3. 2 bao gồm một số công cụ và xác thực nó. Mặc dù dữ liệu của bạn có thể phát triển theo thời gian nhưng dữ liệu này thường có một đường trục chung trong mỗi bộ sưu tập mà bạn dựa trên các truy vấn của mình. Nhiều người tranh luận rằng việc không có lược đồ là một kiến ​​trúc kiểu miền tây hoang dã, nơi mọi thứ có thể được chèn vào cơ sở dữ liệu mà hiếm khi xảy ra trường hợp như vậy

Trên thực tế, có một số lý do tại sao bạn có thể thấy không nên sử dụng lược đồ cho dữ liệu Mongo của mình. Đầu tiên, tính linh hoạt của Mongo khi nói đến các lược đồ là lý do chính để sử dụng MongoDB ngay từ đầu. Nếu bạn vẫn đang lặp đi lặp lại về cách ứng dụng của mình sử dụng dữ liệu và dữ liệu nào được sử dụng, bạn có thể không muốn tự ràng buộc mình vào một dạng duy nhất mà dữ liệu có thể sử dụng. Việc không sử dụng lược đồ với Mongo cho phép bạn tận dụng tối đa các công cụ mà Mongo cung cấp để chiếu dữ liệu của bạn theo bất kỳ hình thức nào bạn muốn

Ngoài ra, nếu bạn có một ứng dụng thu thập dữ liệu với các cấu trúc khác nhau vào một bộ sưu tập duy nhất, thì việc cố gắng giới thiệu một lược đồ có thể gây ra nhiều rắc rối hơn là giá trị của nó. Hơn một lần, tôi đã thấy một lược đồ phát triển từ một định nghĩa chắc chắn về dữ liệu nên là một tập hợp các đối tượng lỏng lẻo, nơi mà việc xác thực hầu như không thể thực hiện được do tính chất protean của dữ liệu đang được vận hành trên đó. Thế giới thực thường lộn xộn. một ngày nào đó bạn đang tích hợp với một nhà cung cấp có cấu trúc API của họ theo một cách, ngày hôm sau bạn đã đá họ cho một đối thủ cạnh tranh có cấu trúc hoàn toàn khác. Khi nhu cầu kinh doanh của bạn phát triển, dữ liệu của bạn cũng vậy

Kế hoạch vĩ đại của sự vật. Sử dụng lược đồ với Mongodb

Hầu hết các đối số để thực thi lược đồ trên dữ liệu của bạn đều đã biết. các lược đồ duy trì cấu trúc, đưa ra ý tưởng rõ ràng về những gì đang đi vào cơ sở dữ liệu, giảm các lỗi có thể ngăn ngừa được và cho phép mã sạch hơn (không còn phải kiểm tra loại trường sắp ra khỏi cơ sở dữ liệu trước khi sử dụng nó). Các lược đồ là một dạng mã tự ghi lại, vì chúng mô tả chính xác loại dữ liệu nào đó sẽ là gì và cho bạn biết những kiểm tra nào sẽ được thực hiện. Nhiều thư viện lược đồ cho phép các chức năng xác thực ngoài việc kiểm tra kiểu đơn giản, do đó, bạn thậm chí có thể có các lược đồ đảm bảo, ví dụ: trường chuỗi là địa chỉ email hợp lệ hoặc trường GeoJSON nằm trong Hoa Kỳ

Ngoài những lý do cổ điển này để sử dụng các lược đồ, có một vài lý do cụ thể của MongoDB để sử dụng chúng. Trước hết, các lược đồ có thể giúp giải quyết một số khó khăn khi truy vấn trong Mongo. Việc truy vấn các tài liệu phụ trong Mongo có thể gây khó chịu bởi vì, như tài liệu nhắc nhở chúng tôi, "Khi thực hiện khớp bằng trên các tài liệu phụ, vấn đề thứ tự trường và các tài liệu phụ phải khớp chính xác. ”

Nếu dữ liệu của bạn có cấu trúc phức tạp với nhiều cấp độ, thì việc làm cho dữ liệu có thể dự đoán được bằng lược đồ có thể giúp cuộc sống của bạn dễ dàng hơn. Ví dụ: nếu bạn có hồ sơ nhân viên với một mảng mua hàng

{
  _id: 112,
  department: “r & d”,
  status: “full time”,
  purchases: [{
    authorizedBy: “accounting”,
    receiptsSubmitted: true,
    cost: 125.99,
    items: [{
      name: “plane ticket”,
      cost: 100,
    }, {
      name: “client lunch”,
      provider: “Applebee’ s”,
      cost: 25.99
    }],
  }],
},

có thể nhanh chóng trở nên khó suy luận về cách thực hiện các truy vấn phức tạp chỉ bằng cách nhìn vào dữ liệu. Lược đồ cung cấp một số đảm bảo về định dạng dữ liệu và cách để xem tất cả các đảm bảo đó ở một nơi. Nếu bạn đang cố gắng tìm tất cả các giao dịch mua lớn hơn 100 đô la được ủy quyền bởi bộ phận của bạn mà chưa gửi biên lai, thì việc này sẽ dễ dàng hơn một chút với lược đồ trước mặt bạn

Các lược đồ cũng đặc biệt hữu ích khi được ghép nối với Trình quản lý tài liệu đối tượng (ODM). cầy mangut. js ODM cho Node, chẳng hạn, có thể sử dụng thông minh các lược đồ của nó để đảm bảo rằng tất cả các truy vấn Mongo của bạn đều được đặt thành các giá trị chính xác. Nó có thể truyền chuỗi tới ObjectIds, ngày hoặc số khi cần thiết cho truy vấn của bạn, điều này đơn giản và nhanh hơn nhiều so với việc quản lý các loại này theo cách thủ công

Một lý do cuối cùng để ưu tiên các lược đồ với MongoDB là chúng ngăn bạn thay đổi hình dạng của tài liệu quá thường xuyên cho một bộ sưu tập nhất định. Cập nhật tài liệu Mongo chuyển đổi dữ liệu giữa các loại hoặc kích thước có thể tốn kém vì Mongo phải phân bổ lại không gian cho bản ghi mới được thay đổi kích thước, dẫn đến cập nhật chậm. Ngay cả những ví dụ tương đối nhỏ cũng có thể dẫn đến các vấn đề. Giả sử, nếu ban đầu bạn lưu tên trên tài liệu người dùng, dưới dạng chuỗi

{
    _id : 1,
    hostName : "Jay Leno",
    timeSlot : "20:00",
    show: "The Tonight Show"
}

và bạn chuyển đổi trong phiên bản mới hơn của ứng dụng để lưu trữ tên dưới dạng tài liệu phụ khi tên được cập nhật

{
    _id : 1,
    hostName : {
        first: "Conan",
        last: "O'Brien"
    }
    timeSlot: "20:00"
    show: "The Tonight Show"
}

điều này có thể khiến ghi chậm trong khi Mongo dịch chuyển tài liệu để tạo khoảng trống cho tài liệu mới được thay đổi kích thước. Nếu bạn thấy rằng những thay đổi thường xuyên đối với kích thước tài liệu trong một bộ sưu tập đang làm chậm ứng dụng của bạn, một lược đồ có thể giúp bạn bằng cách buộc bạn phải suy nghĩ về những thay đổi bạn đang thực hiện đối với dữ liệu của mình

quyết định

Khi bạn đánh giá các lựa chọn của mình, hãy dành thời gian suy nghĩ về con đường phía trước. Nếu bạn đã hiểu rõ về dữ liệu mà mình sẽ sử dụng (ví dụ: nếu bạn đang tương tác với dữ liệu ở định dạng cố định, nếu bạn đang triển khai một tiêu chuẩn), thì lược đồ sẽ rất có ý nghĩa. Những lần khác, quyết định không dễ dàng như vậy. Hãy tự hỏi bản thân rằng bạn dự định trở thành một công ty linh hoạt như thế nào. Khách hàng mới có yêu cầu thay đổi định dạng dữ liệu không?

Cuối cùng, một điều quan trọng cần cân nhắc khi từ bỏ một lược đồ là đó không phải là một quyết định vĩnh viễn. Nếu bạn từ chối áp đặt lược đồ trong hiện tại, tùy chọn vẫn mở cho bạn trong tương lai. Tại bất kỳ thời điểm nào nếu dữ liệu của bạn trở nên có trật tự hơn hoặc bạn nhận thấy việc thiếu lược đồ cản trở khả năng phối hợp giữa nhiều nhà phát triển của mình, bạn có thể áp dụng một lược đồ khá đơn giản. Tương tự như vậy, bạn luôn có thể mở các cửa xả lũ trên một ứng dụng trước đây đã có lược đồ và cho phép mọi loại dữ liệu đi vào

Tài nguyên bổ sung

Hầu hết các ngôn ngữ đều có thư viện để thực thi lược đồ ở cấp ứng dụng trong Mongo. Đây là một lựa chọn

• con trăn. Có một vài thư viện lược đồ tích hợp với PyMongo. Humongulus cung cấp khá nhiều công cụ xác thực. https. //github. com/entone/Humongolus

• Nút. cầy mangut. js là Node ODM hàng đầu và bao gồm xác thực rộng rãi. http. // mongoosejs. com/docs/hướng dẫn. html

• Java. Trình điều khiển Spring Data Mongodb thực thi xác thực bằng cách ánh xạ tài liệu tới các lớp. http. //dự án. mùa xuân. io/mùa xuân-dữ liệu-mongodb/

• hồng ngọc. Dự án Mongoid tuyệt vời hỗ trợ toàn bộ các tính năng lược đồ, từ đánh máy đến xác thực.

  Cơ sở dữ liệu không có lược đồ là gì tại sao chúng tôi gọi nó là không có lược đồ?

  Cơ sở dữ liệu không lược đồ quản lý thông tin mà không cần bản thiết kế . Việc bắt đầu xây dựng cơ sở dữ liệu không lược đồ không phụ thuộc vào việc tuân thủ các trường, bảng hoặc cấu trúc mô hình dữ liệu nhất định. Không có Hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) để thực thi bất kỳ loại cấu trúc cụ thể nào.

  Cơ sở dữ liệu MongoDB có lược đồ không?

  Dữ liệu trong MongoDB có lược đồ linh hoạt . Bộ sưu tập không thực thi cấu trúc tài liệu theo mặc định. Tính linh hoạt này cung cấp cho bạn các lựa chọn lập mô hình dữ liệu để phù hợp với ứng dụng của bạn và các yêu cầu về hiệu suất của nó.

  Lược đồ được gọi trong MongoDB là gì?

  Lược đồ là gì? . Bạn có thể sử dụng lược đồ BSON của Atlas App Services, mở rộng tiêu chuẩn Lược đồ JSON, để xác định mô hình dữ liệu của ứng dụng và xác thực tài liệu bất cứ khi nào chúng được tạo, thay đổi hoặc xóa. a JSON object that defines the the structure and contents of your data. You can use Atlas App Services' BSON schemas, which extend the JSON Schema standard, to define your application's data model and validate documents whenever they're created, changed, or deleted.

  Tại sao lại sử dụng lược đồ trong MongoDB?

  MongoDB đẩy các mối quan tâm về lược đồ lên cấp ứng dụng của bạn, nơi bạn có thể xử lý chúng linh hoạt hơn . Ví dụ: để thêm một trường mới vào tài liệu của bạn, bạn không cần thực hiện THAY ĐỔI tất cả hoặc không có gì trên bộ sưu tập của mình—có thể có hàng triệu mục nhập.