Tại sao MongoDB tốt hơn cho NodeJS?

Bạn đọc thân mến, bạn có thể thắc mắc tại sao phải viết một bài blog khác về MongoDb và MySql. Lý do ẩn đằng sau việc tôi tranh luận với các nhà phát triển NodeJs về việc sử dụng bộ lưu trữ dữ liệu nào làm bộ lưu trữ dữ liệu chính cho các ứng dụng nút. Tôi đã thấy rất nhiều bình luận nơi các nhà phát triển tranh luận về vấn đề này. Một số người nói. “Hãy sử dụng MongoDb, nó nhanh hơn và phù hợp hơn với các ứng dụng NodeJs”, những người khác nói. “Sử dụng db quan hệ, những người sử dụng MongoDb không biết cách viết một vài liên kết”. Vì vậy, tôi quyết định tiến lên một bước và chỉ nhìn thấy nó cho chính mình

Ghi chú. không coi đây là một nghiên cứu đầy đủ về cả hai. Bài viết này nhằm mục đích chia sẻ ý kiến ​​của tôi với bạn và không nên được coi là quyết định sử dụng công nghệ này thay vì công nghệ kia

Môi trường thử nghiệm

Vì vậy, đối với tất cả thử nghiệm này, tôi đã sử dụng MongoDb. bộ chứa docker mới nhất tương tự cho MySql. Môi trường ảo với ram 4G. bộ vi xử lý. 2. Intel Core i5 5GHz. Đối với các truy vấn, tôi đã sử dụng api được tạo với HapiJs. Khi tôi đang cố gắng tái tạo việc sản xuất như sử dụng các công nghệ. Trình điều khiển gốc được sử dụng cho cả MongoDb và MySql. Không kích hoạt bộ nhớ đệm

Thử nghiệm đã được thực hiện trên ba mô hình khác nhau

1. Mongo-flat - đó chỉ là một lược đồ phẳng. Một bộ sưu tập `Người dùng` với địa chỉ được nhúng trong bộ sưu tập

2. Mongo-relation — lược đồ quan hệ trong Mongo. Điều này liên quan đến hai bộ sưu tập. `Người dùng` và `Địa chỉ`

3. Mysql — lược đồ quan hệ. Hai cái bàn. `Người dùng` và `Địa chỉ`

Nói chung, `Người dùng` có mối quan hệ một-nhiều với `Địa chỉ`

điểm chuẩn

1. Chèn - để chèn các bản ghi tôi đã sử dụng `Faker. js`. Chèn được thực hiện bằng hai phương pháp. từng hàng và với số lượng lớn. Chèn số lượng lớn trong khối 5000

Như bạn có thể thấy người chiến thắng nhất định là các miếng chèn số lượng lớn Mongo-phẳng. Điều đó có thể hiểu được vì MongoDb được thiết kế để sử dụng làm phần chèn khối lượng lớn. Mặt khác, chúng ta có thể thấy rằng MySql xuất hiện sau cùng

2. Thêm địa chỉ cho người dùng

Trong trường hợp này, MySql xuất hiện đầu tiên

3. Xóa bản ghi

Một chiến thắng khác cho `Mongo-Flat` khi việc xóa diễn ra trên một bộ sưu tập `Users`. Như tôi đã đề cập trước đó, MongoDb được thiết kế để ghi và xóa cao. Mặt khác, Mysql có thể thực hiện công việc cho bạn trong việc xóa các quan hệ nếu bạn sử dụng ràng buộc khóa ngoài `ON DELETE …`. Điều này trở nên hữu ích trong trường hợp có các mối quan hệ phức tạp trong cơ sở dữ liệu của bạn. Tôi không khuyên bạn nên xóa tất cả bản ghi cùng nhau, vui lòng sử dụng xóa mềm. Nói cách khác, bạn có thể dựa vào cơ sở dữ liệu để thực hiện công việc cho mình trong trường hợp MySql mà MongoDb không làm được như vậy. Để xóa một mối quan hệ trong `Mongo-relation`, bạn cần thực hiện nhiều truy vấn, trước tiên để lấy dữ liệu bộ sưu tập có liên quan và sau đó truyền việc xóa qua toàn bộ cây quan hệ

4. Nhận 5000 người dùng cùng một lúc

Để truy xuất dữ liệu, MySql cho thấy hiệu suất tốt hơn. Truy xuất người dùng từ MySql mất 35 ms, nhanh hơn ~ 14% so với quan hệ Mongo và nhanh hơn ~ 12% so với Mongo-phẳng

5. Đếm người dùng

MySql hoạt động kém nhất, trong đó cả Mongo-flat và Mongo-relation đều cho kết quả rất tốt

6. Nhận 5000 người dùng có địa chỉ

Cả Mysql và Mongo-flat đều hoạt động gần như giống nhau, trong đó mối quan hệ Mongo hoạt động kém hơn; . một để truy xuất người dùng và một để truy xuất địa chỉ của nó. Trong trường hợp của MySql, nó chỉ là một `THAM GIA` và trong trường hợp của Mongo-flat, nó chỉ trả về một đối tượng phẳng

7. Nhận người dùng không có Địa chỉ Florida

Một lần nữa Mysql và Mongo-flat hoạt động gần như giống nhau. Như bạn có thể thấy tốc độ Mongo-flat bắt đầu giảm so với điểm chuẩn #6 do thực tế là có bộ lọc trên `<> 'Florida' và {$ne. 'Florida'}`. Mối quan hệ Mongo lại chậm vì để thực hiện loại truy vấn này, chúng tôi cần sử dụng khung tổng hợp MongoDb chậm

8. Nhận 5000 địa chỉ

MySql lại là người chiến thắng, nhưng trong trường hợp này, Mongo-flat về đích cuối cùng. Lý do lại là MongoDb `Aggregation framework`;

9. Đếm địa chỉ

Điểm chuẩn này gây ngạc nhiên ngay cả đối với tôi. Như bạn có thể thấy Mongo-flat chậm hơn nhiều so với những cái khác. Và đó lại là do sự tổng hợp cần thiết để đếm địa chỉ được nhúng trong bộ sưu tập `Người dùng`

10. Cập nhật địa chỉ theo mệnh đề where

Mongo-flat lại hoạt động kém;

11. Nhận tất cả các địa chỉ Florida

Một lần nữa Mongo-phẳng là cuối cùng. Một lần nữa, đó là do Khung tổng hợp

Phần kết luận

Từ tất cả các điểm chuẩn được hiển thị ở trên, tôi có thể thấy rằng MongoDb hoạt động rất tốt trên các phần chèn. Đó là bởi vì MongoDb được thiết kế để có khả năng ghi nhiều dữ liệu. Vì vậy, tôi có thể kết luận rằng MongoDb sẽ phù hợp nhất khi bạn cần ghi nhiều như ghi nhật ký hoặc dữ liệu chuyển tiếp

Mặt khác, MySql hoạt động tốt hơn nhiều cho việc truy xuất dữ liệu. Vì vậy, nếu bạn không có nhiều lần chèn dữ liệu hoặc việc chèn dữ liệu của bạn không thường xuyên, tôi sẽ xem MySql là nơi lưu trữ dữ liệu kinh doanh của bạn cho các tình huống như báo cáo, quản lý khách hàng, v.v.

Tôi đã thấy MongoDb được sử dụng làm cơ sở dữ liệu quan hệ và từ các điểm chuẩn, tôi có thể thấy rằng sử dụng nó theo cách đó là sai, chỉ cần sử dụng MySql hoặc bất kỳ cơ sở dữ liệu dựa trên Sql nào khác, chúng được thiết kế cho công việc này. Nhưng nếu bạn rơi vào bẫy, tôi sẽ cố gắng thêm các khóa quan hệ ở cả hai bên, chẳng hạn như quay lại lược đồ Người dùng->Địa chỉ quan hệ Mongo. Tôi khuyên bạn nên thêm id địa chỉ vào bộ sưu tập Người dùng, dưới dạng nhúng, vì nó . Mối quan hệ Mongo cho phép truy xuất nhanh trên mỗi cơ sở bộ sưu tập nhưng chậm lại đáng kể khi bạn bắt đầu có mối quan hệ, vì không có truy vấn nối giữa các bộ sưu tập trong mongo. Để có được các mối quan hệ, bạn cần thực hiện nhiều cuộc gọi đến cơ sở dữ liệu. Ngoài ra, bạn có thể tăng tốc truy vấn bằng cách truy xuất dữ liệu hàng loạt và sau đó tham gia các bộ sưu tập có liên quan trong ứng dụng của mình. Hãy cẩn thận với cách tiếp cận cuối cùng vì nó có thể khiến ứng dụng của bạn không sử dụng được, đặc biệt nếu bạn sử dụng các công nghệ đơn luồng như NodeJs

Mongo-flat trở nên rất chậm khi bạn sử dụng tập hợp. Trong hầu hết các trường hợp, đó là lựa chọn duy nhất mà bạn có thể có, đặc biệt nếu bạn đang cố truy xuất các quan hệ nhúng. Khung tổng hợp không mạnh bằng ngôn ngữ Sql, vì vậy đối với một số truy vấn, bạn sẽ cần thực hiện nhiều lệnh gọi tổng hợp tới cơ sở dữ liệu để đạt được kết quả cuối cùng. Tất cả những điều này trở nên rất phức tạp khi mối quan hệ của bạn lồng ghép sâu hơn

MySql sử dụng ngôn ngữ Sql rất mạnh và dễ viết, cho phép nối các bảng, lọc và nối lại; . việc nối bảng của bạn được thực hiện ở cấp cơ sở dữ liệu thay vì cấp ứng dụng

MySql có thể bị chậm không? . Nhưng theo ý kiến ​​​​của tôi, đó là do lược đồ được thiết kế kém. Có rất nhiều công ty đã sử dụng MySql làm nơi lưu trữ dữ liệu chính của họ trong nhiều năm và nó cho thấy điểm chuẩn tốt

Cả Mongo và MySql đều là những công nghệ tuyệt vời. Cả hai đều phục vụ mục đích của họ. Nhưng chúng ta có nên thay thế cái này bằng cái khác không? . Như tôi đã viết trước đó, MongoDb rất tốt cho dữ liệu chuyển tiếp, nhật ký, thông báo, v.v. Nơi MySql tốt cho việc lưu trữ dữ liệu kinh doanh, báo cáo, dữ liệu quan hệ của bạn, v.v.

Tôi thấy không thành công khi MongoDb được sử dụng làm cơ sở dữ liệu quan hệ và điều đó làm tôi kinh ngạc. Một lần nữa, những quyết định sai lầm đưa bạn đến thất bại. Không sử dụng MongoDb cho dữ liệu quan hệ - đó không phải là mục đích của MongoDb

Tôi có thể tiếp tục mô tả cả MongoDb và MySql nhưng tôi sẽ dừng ở đây và để bạn tự quyết định. Tôi đã làm nghiên cứu của tôi, bạn làm của bạn. Nhưng một lần nữa, mọi công nghệ đều phục vụ mục đích của nó

Tại sao mọi người sử dụng NodeJS với MongoDB?

Cái nào tốt hơn với NodeJS MySQL hoặc MongoDB?

Tại sao MongoDB được ưu tiên?

Cơ sở dữ liệu nào tốt nhất với NodeJS?