DynamoDB vs MongoDB NoQuery [đã đóng]


172

Tôi đang cố gắng tìm ra những gì tôi có thể sử dụng cho một dự án trong tương lai, chúng tôi dự định lưu trữ từ khoảng 500 nghìn hồ sơ mỗi tháng trong năm đầu tiên và có thể nhiều hơn trong những năm tiếp theo, đây là một ứng dụng dọc nên không cần sử dụng cơ sở dữ liệu cho điều này, đó là lý do tại sao tôi quyết định chọn lưu trữ dữ liệu noQuery.

Tùy chọn đầu tiên xuất hiện trong đầu tôi là mongo db vì đây là một sản phẩm rất trưởng thành với rất nhiều sự hỗ trợ từ cộng đồng, nhưng mặt khác, chúng tôi có một sản phẩm hoàn toàn mới cung cấp dịch vụ được quản lý với hiệu suất cao nhất, tôi sẽ phát triển điều này ứng dụng nhưng không có kế hoạch bảo trì (ít nhất là bây giờ) vì vậy tôi nghĩ đó sẽ là một lợi thế rất lớn vì amazon cung cấp một cách linh hoạt để mở rộng quy mô.

Mối quan tâm chính của tôi là về cấu trúc truy vấn, tôi chưa xem xét các khả năng truy vấn của máy phát điện nhưng vì lưu trữ dữ liệu ak / v tôi cảm thấy rằng điều này có thể hạn chế hơn so với mongo db.

Nếu ai đó có kinh nghiệm chuyển một dự án từ mongoDB sang DynamoDB, mọi lời khuyên sẽ hoàn toàn được đánh giá cao.


3
Nếu bạn muốn tư vấn về cấu trúc truy vấn, tôi khuyên bạn nên cung cấp một ví dụ về lược đồ của bạn cùng với các trường hợp sử dụng để truy cập dữ liệu. Không có những điều này, thật khó để đưa ra đánh giá về sự phù hợp.
James Wahlin

Thật vậy, cách bạn truy vấn dữ liệu có thể ảnh hưởng đáng kể đến lựa chọn db phụ trợ. Làm thế nào phân cấp sẽ là câu hỏi số 1 của tôi.
zanlok

3
Tôi ngạc nhiên khi câu hỏi này chưa được đóng lại bằng cách xếp hạng người SO. Thông thường các câu hỏi tìm kiếm lời khuyên bị đóng vì họ không yêu cầu trợ giúp với một vấn đề rất cụ thể.
LS

Câu trả lời:


67

Gần đây tôi đã di chuyển MongoDB của mình sang DynamoDB và đã viết 3 blog để chia sẻ một số kinh nghiệm và dữ liệu về hiệu suất, chi phí.

Di chuyển từ MongoDB sang AWS DynamoDB + SimpleDB

7 lý do bạn nên sử dụng MongoDB trên DynamoDB

3 lý do bạn nên sử dụng DynamoDB trên MongoDB


cảm ơn vì đã đăng bài viết của bạn ở đây đã giúp tôi có một tầm nhìn rõ ràng hơn và điều đó chắc chắn sẽ giúp tôi vào lúc tôi sẽ thực hiện một mong muốn
jack.the.ripper

1
đọc ba lý do mà bạn nên sử dụng máy phát điện trên mongo, có một công ty cung cấp dịch vụ được quản lý đắt hơn so với máy phát điện nhưng có thể được xem xét trong trường hợp bạn không có người phụ trách bảo trì nosql , tên công ty là mongoLab
jack.the.ripper

2
@Pedro Cảm ơn rất nhiều vì đã nhắc nhở. Có lẽ tôi đang sử dụng MongoDB một cách không hiệu quả. Tôi có 1,4 triệu bản ghi và chiếm đĩa 8G, nhưng sau khi được chuyển sang DynamoDB, chỉ chiếm 300M dung lượng lưu trữ. Tôi có thể cần kiểm tra và xem lưu trữ gì nếu tôi di chuyển những dữ liệu đó sang MongoLab :)
Mason Zhang

1
Là các liên kết bị hỏng?
fedorqui 'SO ngừng làm hại'

@MasonZhang Sẽ rất thú vị để xem những gì lưu trữ nếu bạn di chuyển những dữ liệu đó sang MongoLab.
fuiiii

164

Tôi biết điều này đã cũ, nhưng nó vẫn xuất hiện khi bạn tìm kiếm sự so sánh. Chúng tôi đã sử dụng Mongo, đã chuyển gần như hoàn toàn sang Dynamo, đây là lựa chọn đầu tiên của chúng tôi bây giờ. Không phải vì nó có nhiều tính năng hơn, nó không. Mongo có ngôn ngữ truy vấn tốt hơn, bạn có thể lập chỉ mục trong một cấu trúc, có rất nhiều điều nhỏ. Sự vượt trội của Dynamo nằm ở những gì OP nêu trong nhận xét của mình: thật dễ dàng. Bạn không cần phải chăm sóc bất kỳ máy chủ nào. Khi bạn bắt đầu thiết lập một giải pháp phân chia Mongo, nó sẽ trở nên phức tạp. Bạn có thể đến một trong những công ty lưu trữ, nhưng điều đó cũng không rẻ. Với Dynamo, nếu bạn cần thêm thông lượng, bạn chỉ cần nhấp vào nút. Bạn có thể viết các kịch bản để chia tỷ lệ tự động. Khi đến lúc nâng cấp Dynamo, nó đã hoàn thành cho bạn. Đó là tất cả rất nhiều căng thẳng quý giá và thời gian không dành. Nếu bạn không

Vì vậy, bây giờ chúng tôi đang đi trên Dynamo theo mặc định. Mongo có thể, nếu cấu trúc dữ liệu đủ phức tạp để đảm bảo nó, nhưng sau đó có lẽ chúng ta sẽ quay trở lại cơ sở dữ liệu SQL. Máy phát điện rất khó hiểu, bạn thực sự cần phải suy nghĩ về cách bạn sẽ xây dựng nó và có khả năng bạn sẽ sử dụng Redis trong Elasticcache để làm cho nó hoạt động cho những thứ phức tạp. Nhưng nó chắc chắn là tốt đẹp để không phải chăm sóc nó. Bạn mã. Đó là nó.


35
Nếu người ta phải so sánh cơ sở dữ liệu với cơ sở dữ liệu, người ta chỉ phải so sánh các tính năng cơ sở dữ liệu. Giải pháp lưu trữ không phải là một tính năng cơ sở dữ liệu. Nếu bạn đang tìm kiếm một MongoDB được lưu trữ, hãy tìm MongoHQ và họ thực hiện tất cả các công việc nặng nề mà bạn có thể muốn tránh trong khi tập trung vào công việc cốt lõi của mình.
Kabeer

12
Đó là sự thật, mặc dù so sánh chi phí ban đầu chúng tôi đã cho thấy máy phát điện là một thỏa thuận khá tốt. Vấn đề khác là nếu bạn phải tăng / giảm kích thước máy phát điện, thì đó chỉ là một nút bấm. Nếu bạn phải thêm đĩa hoặc thay đổi kích thước máy chủ mongo, có thời gian chết liên quan, cho dù bạn phải làm điều đó, hoặc người khác.
CargoMeister

@Kabeer Tôi 100% đồng ý với bạn về mặt kỹ thuật, nhưng trong thế giới thực, toàn bộ gói có vấn đề để đưa ra quyết định kinh doanh. Cuối cùng, đây là một quyết định kinh doanh.
poitroae

59

Với tài liệu 500k, không có lý do gì để mở rộng quy mô. Một máy tính xách tay thông thường có ổ SSD và 8GB ram có thể dễ dàng thực hiện 10 triệu bản ghi, vì vậy nếu bạn đang cố chọn vì mở rộng sự lựa chọn của bạn thì không thực sự quan trọng. Tôi sẽ đề nghị bạn chọn những gì bạn thích nhất và có lẽ bạn có thể tìm thấy sự hỗ trợ trực tuyến nhiều nhất.


vâng lo ngại thị trưởng của tôi là về mở rộng quy mô và duy trì theo thời gian phải trung thực cá nhân tôi cảm thấy rằng MongoDB có thể thực hiện công việc Tôi chỉ nghĩ về về giữa và bảo trì dài hạn
jack.the.ripper

10
Derick, một yếu tố chính khác trong quy mô là việc sử dụng, không chỉ là số lượng tài liệu hoặc kích thước db. @jack không "cảm thấy" mà dựa vào thử nghiệm, bao gồm nền tảng và phần cứng của việc triển khai cuối cùng; một tuần dành cho việc nhồi nhét một vài biến thể db với dữ liệu và điểm chuẩn sẽ dẫn đến các quyết định sáng suốt giúp tiết kiệm rất nhiều nỗi đau.
zanlok

3
Cung cấp một sản phẩm / dịch vụ chuyên nghiệp vượt xa những gì một giải pháp "điều này có thể làm được" đơn giản. Chỉ vì một cỗ máy giá rẻ có thể chạy Linux, MongoDB và hàng triệu bản ghi mà hầu như không có tiền không có hiệu suất tuyệt vời trong thế giới thực. Các bản ghi 500K (với lược đồ SIMPLE) có thể là một ứng cử viên tốt cho DynamoDB đơn giản vì OP sẽ không có chi phí bảo trì (ít nhất là cho phần cứng) và phí hàng tháng có thể sẽ thấp hơn nhiều so với chi phí của máy chủ trong quá trình một hoặc hai năm
cbmeek


16

Câu trả lời ngắn: Bắt đầu với SQL và chỉ thêm NoQuery khi / nếu cần. (trừ khi bạn không cần bất cứ điều gì ngoài các truy vấn rất đơn giản)

Trải nghiệm cá nhân của tôi: Tôi chưa sử dụng MongoDB cho các truy vấn nhưng kể từ tháng 4 năm 2015, DynamoDB vẫn rất tê liệt khi nói đến bất cứ điều gì ngoài các truy vấn khóa / giá trị cơ bản nhất. Tôi thích nó cho những thứ cơ bản nhưng nếu bạn muốn ngôn ngữ truy vấn thì hãy tìm đến một giải pháp cơ sở dữ liệu SQL thực sự.

Trong DynamoDB, bạn có thể truy vấn trên hàm băm hoặc khóa băm và phạm vi và bạn có thể có nhiều chỉ mục toàn cầu thứ cấp. Tôi đang thực hiện các truy vấn trên một bảng với 4 tham số bộ lọc có thể và sắp xếp kết quả, điều này được hỗ trợ (hầu như không) thông qua việc sử dụng các chỉ mục phụ toàn cầu với các biểu thức lọc. Vấn đề xuất hiện khi bạn cố gắng lấy tổng số kết quả khớp với bộ lọc, bạn không thể chỉ tìm kiếm 10 mục đầu tiên phù hợp với bộ lọc mà thay vào đó, nó sẽ kiểm tra 10 mục và bạn có thể nhận được 0 kết quả hợp lệ buộc bạn phải giữ lại quét từ phím tiếp tục - đau ở cổ và tiêu tốn quá nhiều trong bảng của bạn đọc hạn ngạch cho một kịch bản đơn giản.

Để cụ thể về vấn đề giới hạn với các bộ lọc trong truy vấn, đây là từ các tài liệu ( http://docs.aws.amazon.com/amazondoperodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

Trong phản hồi, DynamoDB trả về tất cả các kết quả phù hợp trong
phạm vi của giá trị Giới hạn. Ví dụ: nếu bạn phát hành Truy vấn
hoặc yêu cầu Quét có giá trị Giới hạn là 6 và không có bộ lọc
biểu thức, hoạt động trả về sáu mục đầu tiên trong 
bảng phù hợp với các tham số yêu cầu. Nếu bạn cũng cung cấp một
FilterExpression, hoạt động trả về các mục trong 
sáu mục đầu tiên trong bảng phù hợp với yêu cầu bộ lọc.

Kết luận của tôi là các truy vấn liên quan đến FilterExpressions chỉ có thể sử dụng được trong các trường hợp rất hiếm và không thể mở rộng được vì mỗi truy vấn có thể dễ dàng đọc hầu hết hoặc tất cả các bảng của bạn tiêu thụ quá nhiều đơn vị đọc DynamoDB. Khi bạn sử dụng quá nhiều đơn vị đọc, bạn sẽ nhận được điều chỉnh và thấy hiệu suất kém.

Ý kiến ​​chuyên gia: Trong hội nghị thượng đỉnh AWS vào ngày 9 tháng 4 năm 2015, Brett Hollman, Quản lý, Kiến trúc Giải pháp, AWS đã nói về việc kêu gọi 10 triệu người dùng đầu tiên của bạn ủng hộ bắt đầu với cơ sở dữ liệu SQL và sau đó chỉ sử dụng NoQuery. Bởi vì sớm hay muộn bạn sẽ cần một máy chủ SQL ở đâu đó trong ngăn xếp của bạn. Các slide của anh ấy ở đây: http://www.sl slideshoware.net/AmazonWebService/deep-dive-scaling-up-to-your-first-10-million-users Xem slide 28.


Bạn thực sự nên kiểm tra xem việc tích hợp tìm kiếm trên đám mây với các luồng động và lambda dễ dàng như thế nào để đạt được các truy vấn dựa trên toàn văn bản hoặc vị trí.
MrTJ

4
Chọn cơ sở dữ liệu của bạn theo nhu cầu của bạn. Đây không phải là sự lựa chọn giữa SQL và noQuery, nhưng giữa DB hướng tài liệu, DB hướng đồ thị, DB giá trị khóa, RDMBS .... Không có lựa chọn vàng nào, và SQL chắc chắn là không.
vcarel

14

Chúng tôi đã chọn kết hợp Mongo / Dynamo cho một sản phẩm chăm sóc sức khỏe. Về cơ bản mongo cho phép tìm kiếm tốt hơn, nhưng Dynamo được lưu trữ là tuyệt vời vì tuân thủ HIPAA của nó mà không cần thêm bất kỳ công việc nào. Vì vậy, chúng tôi lưu trữ phần mongo không có dữ liệu cá nhân trên thiết lập tiêu chuẩn và cho phép amazon xử lý phần HIPAA về cơ sở hạ tầng. Chúng tôi có thể truy vấn một số mục nhất định từ mongo sẽ đưa ra các tài liệu có con trỏ (ID) của tài liệu Dynamo có thể liên quan.

Lý do chính chúng tôi chọn để làm điều này bằng cách sử dụng mongo thay vì lưu trữ toàn bộ ứng dụng trên máy phát điện là vì 2 lý do. Đầu tiên, chúng tôi cần phải tạo ra các tìm kiếm dựa trên vị trí mà mongo rất tuyệt và tại thời điểm đó, Dynamo thì không, nhưng hiện tại họ có một tùy chọn.

Thứ hai là một số tài liệu không có cấu trúc và chúng tôi không biết trước dữ liệu sẽ là gì, vì vậy, ví dụ: cho phép người dùng nhập tài liệu vào bộ sưu tập "biểu mẫu" như thế này: {"tên người dùng": "user1", " email ":" me@me.com "}. Và một người dùng khác đặt cái này vào cùng một bộ sưu tập {"phone": "813-555-3333", "location": [28.1234, -83,2342]}. Với mongo, chúng tôi có thể tìm kiếm bất kỳ trường nào trong số các trường động và không xác định này bất cứ lúc nào, với Dynamo, bạn có thể làm điều này nhưng sẽ phải tạo một chỉ mục mỗi khi một trường mới được thêm vào mà bạn muốn tìm kiếm. Vì vậy, nếu bạn chưa bao giờ có một trường điện thoại trong tài liệu Động của bạn trước đây và đột nhiên, một số người thêm nó, nó hoàn toàn không thể tìm kiếm.

Bây giờ điều này mang đến một điểm khác mà bạn đã đề cập. Đôi khi, việc chọn giải pháp phù hợp cho công việc không phải lúc nào cũng có nghĩa là chọn sản phẩm tốt nhất cho công việc. Ví dụ, bạn có thể có một khách hàng cần và sẽ sử dụng hệ thống bạn đã tạo trong hơn 10 năm. Sử dụng giải pháp SaaS / IaaS đủ tốt để hoàn thành công việc có thể là một lựa chọn tốt hơn vì bạn có thể dựa vào amazon để duy trì và duy trì hệ thống của họ trong suốt thời gian dài.


9

Tôi đã làm việc trên cả hai và loại fan hâm mộ của cả hai.

Nhưng bạn cần hiểu khi nào nên sử dụng cái gì và cho mục đích gì.

Tôi không nghĩ rằng việc chuyển tất cả cơ sở dữ liệu của bạn sang DynamoDB là một ý tưởng tuyệt vời, lý do việc truy vấn rất khó ngoại trừ các khóa chính và khóa phụ, Lập chỉ mục bị hạn chế và việc quét trong DynamoDB rất khó khăn.

Tôi sẽ sử dụng một loại DB lai, trong đó dữ liệu có thể truy vấn mở rộng nên có MongoDB, với tất cả tính năng của nó, bạn sẽ không bao giờ cảm thấy bị hạn chế để cung cấp các cải tiến hoặc sửa đổi.

DynamoDB nhanh như chớp (nhanh hơn MongoDB), do đó, DynamoDB thường được sử dụng thay thế cho các phiên trong các ứng dụng có thể mở rộng. Các thực tiễn tốt nhất của DynamoDB cũng gợi ý rằng nếu có nhiều dữ liệu ít được sử dụng, hãy chuyển nó sang bảng khác.

Vì vậy, giả sử bạn có một bài viết hoặc nguồn cấp dữ liệu. Mọi người có nhiều khả năng tìm kiếm công cụ tuần trước hoặc công cụ của tháng này. cơ hội thực sự hiếm khi mọi người truy cập dữ liệu hai năm tuổi. Đối với những mục đích này, DynamoDB thích có dữ liệu được lưu trữ theo tháng hoặc năm trong các bảng khác nhau.

DynamoDB dường như có khả năng mở rộng, một số thứ bạn sẽ phải làm thủ công trong MongoDB. tuy nhiên, bạn sẽ mất hiệu năng của DynamoDB, nếu bạn không hiểu về phân vùng thông lượng và cách chia tỷ lệ hoạt động sau cảnh.

Nên sử dụng DynamoDB khi tốc độ rất quan trọng, mặt khác MongoDB có quá nhiều tay và tính năng, một thứ mà DynamoDB thiếu.

ví dụ: bạn có thể có một bộ bản sao MongoDB theo cách sao cho một trong các bản sao giữ bản sao dữ liệu của 8 (hoặc bất cứ thứ gì) cũ. Thực sự hữu ích, nếu bạn làm hỏng một cái gì đó lớn thời gian trong DB của bạn và muốn lấy dữ liệu như trước đây.

Đó là ý kiến ​​của tôi mặc dù.


1
Và sự kết hợp giữa Redis và MongoDB? Thật tuyệt vời, tôi nghĩ vậy.
ismaestro

Tôi đoán vậy, tôi không có kinh nghiệm về Redis nhưng chắc chắn nó được sử dụng rộng rãi vì hiệu năng của nó, trong bộ nhớ DB hầu như luôn hoạt động tốt hơn so với DB dựa trên đĩa. Vì vậy, tôi nghĩ rằng dữ liệu cần được truy cập theo nhu cầu lớn và tần suất cao nên đến Redis. Mặt khác, nên sử dụng dữ liệu thờ ơ lớn MongoDB.
Rahul Kumar

7

Hãy nhớ rằng, tôi chỉ thử nghiệm với MongoDB ...

Từ những gì tôi đã đọc, DynamoDB đã đi một chặng đường dài về các tính năng. Nó từng là một kho lưu trữ khóa-giá trị siêu cơ bản với khả năng lưu trữ và truy vấn cực kỳ hạn chế. Nó đã phát triển, hiện hỗ trợ kích thước tài liệu lớn hơn + hỗ trợ JSONcác chỉ số phụ toàn cầu . Khoảng cách giữa những gì DynamoDB và MongoDB cung cấp về các tính năng ngày càng nhỏ hơn mỗi tháng. Các tính năng mới của DynamoDB được mở rộng tại đây .

Phần lớn các so sánh MongoDB so với DynamoDB đã lỗi thời do sự bổ sung gần đây của các tính năng của DynamoDB. Tuy nhiên, bài đăng này cung cấp một số điểm thuyết phục khác để chọn DynamoDB, cụ thể là nó đơn giản, bảo trì thấp và thường có chi phí thấp. Một cuộc thảo luận khác ở đây về các lựa chọn cơ sở dữ liệu rất thú vị để đọc, mặc dù hơi cũ.

Mục đích của tôi: nếu bạn đang thực hiện các truy vấn cơ sở dữ liệu nghiêm túc hoặc làm việc bằng các ngôn ngữ không được hỗ trợ bởi DynamoDB, hãy sử dụng MongoDB. Nếu không, hãy gắn bó với DynamoDB.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.