Khi nào nên sử dụng mongodb?
|
Một cách tiếp cận kiến trúc khác sử dụng nhiều cơ sở dữ liệu là microservice, trong đó mỗi microservice có cơ sở dữ liệu riêng được tối ưu hóa tốt hơn cho các tác vụ của dịch vụ cụ thể này. Ví dụ: bạn có thể sử dụng MySQL để lưu trữ chính, Redis và Memcached – để lưu vào bộ đệm, Elaticsearch hoặc Sphinx gốc – để tìm kiếm. Bạn có thể áp dụng một cái gì đó như Kafka để chuyển dữ liệu sang hệ thống phân tích, điều này thường được thực hiện trên một cái gì đó như Hadoop Show
Nếu chúng ta đang nói về bộ lưu trữ hoạt động chính, có thể có hai tùy chọn ở đó. Chúng ta có thể chọn cơ sở dữ liệu quan hệ với ngôn ngữ SQL. Ngoài ra, chúng tôi có thể chọn cơ sở dữ liệu phi quan hệ và sau đó chọn một trong các loại có sẵn trong trường hợp này Nếu chúng ta nói về các mô hình dữ liệu NoSQL, thì cũng có rất nhiều sự lựa chọn. Những cái điển hình nhất là cơ sở dữ liệu khóa-giá trị, tài liệu hoặc cột rộng Ví dụ lần lượt là Memcache, MongoDB và Cassandra Nhìn vào Bảng xếp hạng DB-Engines, chúng ta sẽ thấy rằng mức độ phổ biến của cơ sở dữ liệu nguồn mở đã tăng lên trong những năm qua, trong khi cơ sở dữ liệu thương mại đang giảm dần  Điều thú vị hơn nữa là xu hướng tương tự đã được quan sát thấy đối với các loại cơ sở dữ liệu khác nhau. cơ sở dữ liệu nguồn mở phổ biến nhất đối với nhiều loại như cơ sở dữ liệu cột, chuỗi thời gian và câu chuyện tài liệu. Giấy phép thương mại chỉ áp dụng cho các công nghệ cổ điển như dữ liệu cơ sở dữ liệu quan hệ hoặc thậm chí cũ hơn như cơ sở dữ liệu đa giá trị Tại Percona, chúng tôi hợp tác chặt chẽ với các cơ sở dữ liệu nguồn mở quan hệ và không quan hệ phổ biến nhất (MySQL, PostgreSQL và MongoDB), giao dịch với nhiều khách hàng; Với ý nghĩ đó, bài viết này có mục đích đưa ra các kịch bản đáng xem xét trước khi triển khai MongoDB, dẫn bạn đến suy nghĩ khi nào bạn nên và không nên sử dụng nó. Ngoài ra, nếu bạn đã có thiết lập của mình, thì bài viết này cũng có thể thú vị, vì trong quá trình đánh giá sản phẩm, một số chủ đề sau có thể không được chú ý Mục lụcDưới đây là danh sách các chủ đề mà tôi sẽ thảo luận thêm trong bài viết này
1. Kinh nghiệm và sở thích của nhómTrước khi đi sâu vào MongoDB, điều quan trọng nhất là phải tính đến kinh nghiệm và sở thích của nhóm Theo quan điểm của MongoDB, lợi thế là chúng tôi có các tài liệu định dạng JSON linh hoạt và đối với một số tác vụ và một số nhà phát triển, điều này thuận tiện. Đối với một số nhóm, điều này rất khó, đặc biệt nếu họ đã làm việc với cơ sở dữ liệu SQL trong một thời gian dài và hiểu rất rõ về đại số quan hệ và ngôn ngữ SQL Trong MongoDB, bạn có thể dễ dàng làm quen với các thao tác CRUD như
Các truy vấn đơn giản ít có khả năng gây ra sự cố. Tuy nhiên, ngay khi nhiệm vụ hàng ngày phát sinh đòi hỏi xử lý dữ liệu sâu hơn, bạn chắc chắn cần một công cụ mạnh mẽ để xử lý việc đó, chẳng hạn như MongoDB aggregation pipeline và map-reduce, mà chúng ta sẽ thảo luận thêm trong bài viết này Có các khóa học tuyệt vời và miễn phí tại Đại học MongoDB chắc chắn có thể giúp nâng cao kiến thức của nhóm. Tuy nhiên, điều quan trọng cần lưu ý là có thể mất một thời gian để đạt đến đỉnh của đường cong học tập nếu nhóm không hoàn toàn quen thuộc với nó 2. Phương pháp tiếp cận phát triển và vòng đời ứng dụngNếu chúng ta nói về các ứng dụng sử dụng MongoDB, thì chúng chủ yếu tập trung vào phát triển nhanh vì bạn có thể thay đổi mọi thứ bất cứ lúc nào. Bạn không phải lo lắng về định dạng nghiêm ngặt của tài liệu Điểm thứ hai là lược đồ dữ liệu. Ở đây bạn cần hiểu rằng dữ liệu luôn có lược đồ; . Bạn có thể triển khai lược đồ dữ liệu trong ứng dụng của mình bởi vì, bằng cách nào đó, đây là dữ liệu bạn sử dụng. Hoặc lược đồ này được triển khai ở cấp cơ sở dữ liệu Khá thường xuyên khi bạn có một ứng dụng và chỉ ứng dụng này xử lý dữ liệu trong cơ sở dữ liệu. Ví dụ: nếu chúng tôi lưu dữ liệu từ ứng dụng vào cơ sở dữ liệu, lược đồ cấp ứng dụng sẽ hoạt động tốt. Tuy nhiên, nếu chúng ta có cùng một dữ liệu được sử dụng bởi nhiều ứng dụng, điều đó sẽ trở nên rất bất tiện và khó kiểm soát Một quan điểm về chu trình phát triển ứng dụng có thể được biểu diễn như sau
3. Mô hình dữ liệuNhư đã đề cập trong chủ đề đầu tiên, mô hình dữ liệu phụ thuộc nhiều vào ứng dụng và kinh nghiệm của nhóm Dữ liệu của nhiều ứng dụng web thường dễ hiển thị. Bởi vì nếu chúng ta lưu trữ cấu trúc, giống như một mảng được liên kết của ứng dụng, thì việc nhà phát triển tuần tự hóa nó thành một tài liệu JSON sẽ rất đơn giản và rõ ràng Hãy lấy một ví dụ. Chúng tôi muốn lưu danh sách liên lạc từ điện thoại. Có dữ liệu phù hợp với một bảng quan hệ. tên, họ, v.v. Nhưng nếu bạn nhìn vào số điện thoại hoặc địa chỉ email, một người có thể có nhiều số đó. Nếu chúng tôi muốn lưu trữ cái này ở dạng quan hệ tốt, sẽ tốt hơn nếu có nó trong các bảng riêng biệt, sau đó thu thập nó bằng THAM GIA, điều này kém thuận tiện hơn so với việc lưu trữ nó trong một bộ sưu tập với các tài liệu phân cấp Mô hình dữ liệu – Ví dụ về danh sách liên hệCơ sở dữ liệu quan hệ
Cơ sở dữ liệu hướng tài liệu
Tuy nhiên, điều quan trọng là phải cân nhắc rằng một giải pháp linh hoạt hơn sẽ dẫn đến một danh sách các tài liệu có thể có cấu trúc hoàn toàn khác. Như ai đó đã nói trước đây, “Với sức mạnh lớn đi kèm với trách nhiệm lớn. ” Thật không may, khá phổ biến khi thấy các hoạt động không thể quản lý các tài liệu lớn hơn hoặc một bộ sưu tập duy nhất chứa hàng terabyte dữ liệu; Những điểm bất thường này có thể là dấu hiệu tốt cho thấy bạn đang biến cơ sở dữ liệu của mình thành Đầm lầy dữ liệu. Đây là một thuật ngữ thường được sử dụng trong triển khai Dữ liệu lớn cho dữ liệu được thiết kế tồi, tài liệu không đầy đủ hoặc được bảo trì kém Bạn không cần phải chuẩn hóa dữ liệu của mình một cách nghiêm ngặt, nhưng điều cần thiết là dành thời gian và phân tích cách bạn sẽ cấu trúc dữ liệu của mình để có thế giới tốt nhất sau khi sử dụng MongoDB và tránh những cạm bẫy đó Bạn có thể kiểm tra bài đăng trên blog “Thiết kế lược đồ trong MongoDB so với Thiết kế lược đồ trong MySQL” để hiểu rõ hơn về mô hình hóa dữ liệu và sự khác biệt của nó. Điều đáng nói là tính năng xác thực lược đồ mà bạn có thể sử dụng trong quá trình cập nhật và chèn. Bạn có thể đặt quy tắc xác thực trên cơ sở từng bộ sưu tập, hạn chế loại nội dung đang được lưu trữ Điều kiệnThật thú vị, trong khi mô hình hóa và truy vấn, có nhiều điểm chung giữa các DBMS quan hệ và không quan hệ. Chúng ta đang nói về cơ sở dữ liệu trong cả hai trường hợp, nhưng cái mà chúng ta gọi là bảng trong cơ sở dữ liệu quan hệ thường được gọi là tập hợp trong cơ sở dữ liệu không quan hệ. Cột trong SQL là gì, trường trong MongoDB là gì và danh sách tiếp tục Về việc sử dụng THAM GIA mà chúng ta đã đề cập, MongoDB không có khái niệm như vậy. Tuy nhiên, bạn có thể sử dụng $lookup trên kênh tổng hợp của mình. Nó chỉ thực hiện một phép nối ngoài bên trái trong tìm kiếm của bạn; Đối với quyền truy cập. chúng tôi áp dụng SQL cho dữ liệu quan hệ. Đối với MongoDB và nhiều cơ sở dữ liệu NoSQL khác, chúng tôi sử dụng một tiêu chuẩn như CRUD. Tiêu chuẩn này nói rằng có các thao tác để tạo, đọc, xóa và cập nhật tài liệu Dưới đây là một số ví dụ về các tác vụ điển hình nhất để xử lý các tài liệu và tài liệu tương đương trong thế giới SQL
1 2 3 4 5 6 7 8 db. khách hàng. chèn({ "Tên khách hàng". "Hồng y", "Tên liên hệ". "Tom B. Erichsen", "Địa chỉ". "Skagen 21", "Thành phố". "Stavanger", "Mã bưu chính". 4006, "Quốc gia". "Na Uy" }) mysql1 2 3 4 5 6 7 8 9 10 11 12 13 CHÈN VÀO khách hàng (customername, contactname, address, city, postalcode, country) GIÁ TRỊ ( 'Cardinal', . Erichsen' 'Tom B. Erichsen' , 'Skagen 21', 'Stavanger', '4006', 'Norway');
1 2 3 4 5 6 7 8 db. khách hàng. tìm({ "Mã bưu điện". { "$eq". 4006}}, { "_id". 0, "tên khách hàng". 1, "Thành phố". 1 }) mysql1 2 3 4 CHỌN tên khách hàng, thành phố TỪ khách hàng WHERE Mã bưu chính = 12346;
1 2 3 db. khách hàng. cập nhật({ "Tên khách hàng". "Hồng Y"}, {"$set". {"Thành phố". "Oslo"}}) 1 2 3 CẬP NHẬT khách hàng SET thành phố = 'Oslo' WHERE tên khách hàng = 'Cardinal';
1 2 3 db. khách hàng. xóa({ "tên khách hàng". "John" }) mysql1 2 XÓA TỪ khách hàng WHERE tên khách hàng = 'John'; Nếu bạn là nhà phát triển quen thuộc với ngôn ngữ JavaScript, cú pháp này do CRUD (MongoDB) cung cấp sẽ tự nhiên hơn đối với bạn so với cú pháp SQL Theo tôi khi chúng ta thao tác đơn giản nhất như tìm kiếm hay chèn thì chúng đều hoạt động đủ tốt. Khi nói đến các thao tác lấy mẫu phức tạp hơn, ngôn ngữ SQL dễ đọc hơn nhiều
1 2 3 4 5 db. khách hàng. tìm({ "Mã bưu điện". { "$eq". 4006 } }). đếm() mysql1 2 3 CHỌN Đếm (1) TỪ khách hàng WHERE mã bưu điện = 4006; Với giao diện, thật dễ dàng để thực hiện những việc như đếm số lượng hàng trong bảng hoặc bộ sưu tập
1 2 3 4 5 6 7 8 9 10 db. khách hàng. tổng hợp([ { "$group". { "_id":"$Thành phố", "tổng":{ . "$sum":1 } } } ]) mysql1 2 3 4 CHỌN thành phố, Số lượng (1) TỪ khách hàng NHÓM BÊN thành phố; Nhưng nếu chúng ta làm những việc phức tạp hơn như GROUP BY trong MongoDB thì sẽ cần đến Aggregation Framework. Đây là một giao diện phức tạp hơn hiển thị cách chúng tôi muốn lọc, cách chúng tôi muốn nhóm, v.v. 4. Giao dịch và nhất quán (ACID)Lý do đưa chủ đề này ra thảo luận là vì tùy thuộc vào yêu cầu kinh doanh , giải pháp cơ sở dữ liệu might need to be ACID compliant. In this game, relational databases đi trước rất xa . Một ví dụ tuyệt vời về các yêu cầu ACID là các hoạt động liên quan đến tiền. Hãy tưởng tượng bạn đang xây dựng một chức năng để chuyển tiền từ tài khoản này sang tài khoản khác. Nếu bạn rút tiền thành công từ tài khoản nguồn nhưng không ghi có vào tài khoản đích; . Hai thao tác ghi này phải xảy ra hoặc cả hai đều không xảy ra để giữ cho hệ thống của chúng tôi hoạt động bình thường, đồng thời biết “Or if you instead credited the destination but never took money out of the source to cover it. These two writes have to either happen or both not happen to keep our system sane, also know “tất cả hoặc không có gì. ” Trước khi phát hành 4. 0, MongoDB không hỗ trợ các giao dịch , nhưng nó hỗ trợ các hoạt động nguyên tử trong một tài liệu. Điều đó có nghĩa là, theo quan điểm của một tài liệu, hoạt động sẽ là nguyên tử . Nếu quy trình thay đổi một số tài liệu và một số loại lỗi xảy ra trong quá trình thay đổi, một số tài liệu này sẽ bị thay đổi và một số thì không. Hạn chế này đối với MongoDB đã được dỡ bỏ với phiên bản 4. 0 trở đi . Đối với các tình huống yêu cầu tính nguyên tử của việc đọc và ghi vào nhiều tài liệu (trong một hoặc nhiều bộ sưu tập), MongoDB hỗ trợ giao dịch nhiều tài liệu . Nó có thể được sử dụng trên nhiều hoạt động, bộ sưu tập, cơ sở dữ liệu, tài liệu và phân đoạn với các giao dịch phân tán.
5. khả năng mở rộngKhả năng mở rộng trong bối cảnh này là gì? Nếu chúng ta nói về khả năng mở rộng của một cụm trong đó các ứng dụng của chúng ta đã đủ lớn, thì rõ ràng là một máy sẽ không đối phó được, ngay cả khi đó là máy mạnh nhất Cũng hợp lý khi nói về việc liệu chúng tôi có mở rộng quy mô đọc, ghi hoặc khối lượng dữ liệu hay không. Các ưu tiên có thể khác nhau trong các ứng dụng khác nhau, nhưng nói chung, nếu ứng dụng rất lớn, chúng thường phải giải quyết tất cả những điều này Trong MongoDB, trọng tâm ban đầu là khả năng mở rộng trên nhiều nút. Ngay cả trong trường hợp của một ứng dụng nhỏ. Chúng ta có thể nhận thấy điều đó trên tính năng Sharding được phát hành trong những ngày đầu, tính năng này đã được phát triển và hoàn thiện hơn kể từ đó Nếu bạn đang tìm kiếm khả năng mở rộng theo chiều dọc , bạn có thể đạt được điều đó trong MongoDB thông qua Replica Set< . Bạn có thể mở rộng và thu nhỏ cơ sở dữ liệu của mình trong rất ít bước, nhưng vấn đề ở đây là chỉ có configuration. You can scale up and scale down your database in very few steps, but the point here is that only sự sẵn có của bạn và reads are scaled. Your writes are still tied to a single point, the primary. Tuy nhiên, chúng tôi biết rằng tại một thời điểm nào đó, ứng dụng sẽ yêu cầu nhiều dung lượng ghi hơn hoặc tập dữ liệu sẽ trở nên quá lớn đối với Bộ bản sao . Sharding, splitting the dataset, and writes across multiples shards. Sharding MongoDB có một số hạn chế. không phải tất cả các thao tác đều hoạt động với nó, và một thiết kế tồi trên các phím phân đoạn có thể , tạo ra , and impact cluster internal operation as automatic , and on a worse scenario demanding , which is an extensive and error-prone operation. Với việc phát hành MongoDB 5. 0 , một tính năng đã được giới thiệu gần đây. Như với bất kỳ tính năng mới nào, khuyến nghị của tôi là thử nghiệm rộng rãi trước khi sử dụng sản xuất. Nếu tại một thời điểm nào đó, bạn đang xem xét các phương pháp để tinh chỉnh khóa phân đoạn của mình và sau đó phân đoạn lại with the new feature, the article Refining Shard Keys in MongoDB 4.4 and Above có thể hướng dẫn bạn lựa chọn tốt hơn. 6. Sự quản lýQuản trị là tất cả những thứ mà các nhà phát triển không nghĩ đến. Ít nhất, nó không phải là ưu tiên hàng đầu của họ. Quản trị là tất cả về nhu cầu sao lưu, cập nhật, giám sát, khôi phục ứng dụng trong trường hợp bị lỗi MongoDB tập trung hơn vào cách tiêu chuẩn – quản trị được giảm thiểu. Nhưng rõ ràng là điều này xảy ra với chi phí linh hoạt. Cộng đồng các giải pháp nguồn mở cho MongoDB nhỏ hơn đáng kể. Bạn có thể nhận thấy điều đó trong Xếp hạng động cơ DB được nêu bật ở đầu bài viết này và cuộc khảo sát hàng năm của < . ; undoubtedly, MongoDB is the most popular NoSQL database, but unfortunately, it lacks a strong community. Ngoài ra, nhiều nội dung được đề xuất trong MongoDB được liên kết khá chặt chẽ với các dịch vụ Ops Manager và Atlas – . . Cho đến gần đây, việc chạy sao lưu/khôi phục quy trình không phải là hoạt động tầm thường for Sharded Cluster or ReplicaSet. DBAs had to rely on methods around the mongodump/ hoặc sử dụng Ảnh chụp nhanh hệ thống tệp. Tình huống này bắt đầu trở nên tốt hơn với các tính năng như Dự phòng nóng Percona and the Percona Backup for MongoDB tool. Nếu chúng ta kiểm tra cơ sở dữ liệu quan hệ phổ biến nhất như MySQL, thì nó đủ linh hoạt và có nhiều cách tiếp cận khác nhau. Có những triển khai nguồn mở tốt cho mọi thứ, đó là những điểm yếu vẫn còn tồn tại trong MongoDB Phần kết luậnTôi đã thảo luận về một vài chủ đề có thể giúp ích cho bạn trong công việc hàng ngày, cung cấp một tầm nhìn bao quát về lợi ích của MongoDB. Điều quan trọng cần lưu ý là bài viết này được viết dựa trên bản phát hành mới nhất hiện có MongoDB 5. 0; . deprecated ones, some of the observations and features might not be valid. Nếu bạn đang gặp sự cố hoặc có câu hỏi ở cấp độ chi tiết, vui lòng xem blog của chúng tôi; . We also invite you to check our white paper here, in which we detail more scenarios and cases where MongoDB is a good fit, and where it’s not. Tôi hy vọng cái này sẽ giúp bạn Nếu bạn có bất kỳ câu hỏi nào, vui lòng liên hệ qua phần bình luận bên dưới Tài nguyên hữu íchCuối cùng, bạn có thể liên hệ với chúng tôi thông qua các mạng xã hội, diễn đàn của chúng tôi hoặc truy cập tài liệu của chúng tôi bằng các liên kết được trình bày bên dưới
Phân phối Percona cho MongoDB là giải pháp thay thế cơ sở dữ liệu MongoDB có sẵn miễn phí, cung cấp cho bạn một giải pháp duy nhất kết hợp các thành phần doanh nghiệp quan trọng và tốt nhất từ cộng đồng nguồn mở, được thiết kế và thử nghiệm để hoạt động cùng nhau Khi nào bạn nên sử dụng MongoDB?Sử dụng MongoDB cho phép nhóm của bạn tiến xa hơn và nhanh hơn khi phát triển các ứng dụng phần mềm xử lý mọi loại dữ liệu theo cách có thể mở rộng . MongoDB là một lựa chọn tuyệt vời nếu bạn cần. Hỗ trợ phát triển lặp đi lặp lại nhanh chóng. Cho phép cộng tác của một số lượng lớn các nhóm.
Khi nào bạn nên sử dụng MongoDB thay vì SQL?Kết luận. MongoDB là một cơ sở dữ liệu tiên tiến hơn và có khả năng xử lý dữ liệu lớn với các tính năng lược đồ động. SQL Server là một RDBMS được sử dụng để quản lý hệ thống cơ sở dữ liệu quan hệ và cung cấp các giải pháp dữ liệu kinh doanh đầu cuối. Trong trường hợp dữ liệu phi cấu trúc MongoDB là một lựa chọn tốt.
Khi nào bạn không nên sử dụng MongoDB?Một trong những nhược điểm của MongoDB là nó không hỗ trợ giao dịch. Mặc dù ngày càng có ít ứng dụng yêu cầu giao dịch nhưng vẫn có một số ứng dụng cần giao dịch để cập nhật nhiều tài liệu/bộ sưu tập. Nếu đó là chức năng cần thiết cho nhóm của bạn , thì không nên sử dụng MongoDB.
Tại sao chúng ta nên sử dụng MongoDB thay vì SQL?Vì mô hình tài liệu của MongoDB lưu trữ dữ liệu liên quan cùng nhau, nên việc truy xuất một tài liệu từ MongoDB thường nhanh hơn là THAM GIA dữ liệu trên nhiều bảng trong MySQL. |
