Cái nào nhanh hơn: PostgreSQL vs MongoDB trên các bộ dữ liệu JSON lớn?


10

Tôi có một bộ dữ liệu lớn với các đối tượng JSON 9m với giá trị ~ 300 byte mỗi đối tượng. Chúng là các bài đăng từ một trình tổng hợp liên kết: về cơ bản là các liên kết (một URL, tiêu đề và id tác giả) và các bình luận (ID văn bản và ID tác giả) + siêu dữ liệu.

Chúng rất có thể là các bản ghi quan hệ trong một bảng, ngoại trừ thực tế là chúng có một trường mảng có ID trỏ đến các bản ghi con.

Những gì thực hiện có vẻ vững chắc hơn?

  1. Các đối tượng JSON trên cơ sở dữ liệu PostgreSQL (chỉ một bảng lớn có một cột, cụ thể là đối tượng JSON)
  2. Các đối tượng JSON trên MongoDB
  3. Phát nổ các đối tượng JSON thành các cột và sử dụng các mảng trên PostgreSQL

Tôi muốn tối đa hóa hiệu suất trong các phép nối, vì vậy tôi có thể xoa bóp dữ liệu và khám phá nó cho đến khi tôi tìm thấy các phân tích thú vị, tại thời điểm đó tôi nghĩ sẽ tốt hơn khi chuyển đổi dữ liệu thành một dạng cụ thể cho từng phân tích.


có thể muốn kiểm tra bông tuyết. Nó có thể xử lý cả dữ liệu có cấu trúc và bán cấu trúc với nhau. www.snowflower.net

Tôi nghĩ rằng bạn cần mở rộng về ý nghĩa "tối đa hóa hiệu suất khi tham gia" đối với bạn. Tham gia gì?
Spainedman

Câu trả lời:


10

Đối với tải dữ liệu, Postgre vượt trội so với MongoDB. MongoDB hầu như luôn luôn nhanh hơn khi trả về số lượng truy vấn. PostgreSQL hầu như luôn nhanh hơn cho các truy vấn sử dụng các chỉ mục.

Kiểm tra trang web này và trang này cũng để biết thêm. Họ có những giải thích rất chi tiết.


Liên kết rất tốt, đặc biệt là liên kết đầu tiên trông chi tiết và kỹ lưỡng hơn. Khi tìm kiếm năm (một chuỗi) và trả về id bản ghi (int), potgresql nhanh hơn khoảng 4 lần, nhưng khi trả về tác giả, thứ tự cường độ là như nhau. MongoDB chỉ chậm hơn khoảng 20% ​​khi trả lại tác giả. Có một sự khác biệt cơ bản giữa trả về một int và trả về một chuỗi có thể giải thích điều này? Đó là, nếu recid là một chuỗi, thì lợi thế của postgresql sẽ biến mất và cả hai đều giống như trong trường hợp của tác giả?
MASL

1

Bạn có thể hưởng lợi nhiều hơn từ thiết kế schemaless của Mongodb. Điều này có nghĩa là nó rất dễ dàng để sửa đổi cấu trúc dữ liệu một cách nhanh chóng.

Không có điều gì như tham gia vào Mongodb. Vì vậy, cách người ta nghĩ về dữ liệu và cách sử dụng nó cần phải được sửa đổi để giải thích cho các môi trường db dựa trên tài liệu và schemaless.

Có lẽ tốc độ trở nên ít quan trọng hơn khi quan điểm và ưu tiên thay đổi.

Tôi hy vọng điều đó sẽ giúp.

-Todd


Trong hầu hết các điểm chuẩn gần đây, PostgreQuery hoàn toàn thuộc sở hữu MongoDB ...
Có QUIT - Anony-Mousse

@ Anony-Mousse: Thú vị. Bạn có biết nguồn nào không?
Isaac

ví dụ: tiborsimko.org/postgresql-mongodb-json-select-speed.htmlenterprisedb.com/postgres-plus-edb-blog/marc-linster/ từ câu trả lời khác. Một lý do chính là: Postgres có các chỉ mục tốt, trong khi các chỉ mục trong MongoDB không có giá trị. Hơn nữa, Postgres có hỗ trợ BSON và các bổ sung khác để xử lý JSON, điều đó đã cải thiện hiệu suất đáng kể. Đó là lý do tại sao nó nhanh hơn rất nhiều so với các phiên bản đầu tiên.
Có QUIT - Anony-Mousse

0

Đối với những con số bạn đề cập, tôi nghĩ rằng tất cả các lựa chọn thay thế đều hoạt động (đọc: bạn sẽ có thể hoàn thành phân tích của mình trong thời gian hợp lý). Tôi đề nghị về một thiết kế có thể dẫn đến kết quả nhanh hơn đáng kể.

Như đã trả lời trước đây, nói chung postgresql nhanh hơn mongo, nhanh hơn gấp 4 lần. Xem ví dụ: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Bạn nói rằng bạn quan tâm đến việc cải thiện hiệu suất trong các lần tham gia. Tôi giả sử rằng bạn quan tâm đến việc tính toán sự tương đồng giữa các thực thể (ví dụ: bài đăng, tác giả) vì vậy bạn sẽ chủ yếu tham gia vào bảng với chính nó (ví dụ: theo bài đăng hoặc tác giả) và tổng hợp.

Thêm vào đó là thực tế là sau khi tải ban đầu, cơ sở dữ liệu của bạn sẽ chỉ được đọc, điều gì làm cho vấn đề rất phù hợp với việc sử dụng chỉ mục. Bạn sẽ không trả tiền để cập nhật chỉ mục vì bạn sẽ không có bất kỳ và tôi đoán bạn có thêm dung lượng cho chỉ mục.

Tôi sẽ sử dụng postgres và lưu trữ dữ liệu trong hai bảng:

tạo bài viết bảng (số nguyên post_id, url varchar (255), số nguyên Author_id);

- Tải dữ liệu và sau đó tạo các chỉ số. - Điều đó sẽ dẫn đến tải nhanh hơn và các chỉ số tốt hơn thay đổi các bài đăng trong bảng thêm khóa chính ràng buộc post_pk (post_id); tạo chỉ mục post_ Tác giả trên các bài đăng (Author_id);

tạo bình luận bảng (số nguyên comment_id, số nguyên post_id, số nguyên Author_id, bình luận varchar (255)); thay đổi nhận xét bảng thêm ràng buộc khóa_pk khóa chính (comment_id); tạo chỉ mục bình luận về tác giả trên bình luận (Author_id); tạo chỉ mục bình luận_post trên bình luận (post_id);

Sau đó, bạn có thể tính toán độ tương tự của tác giả dựa trên các nhận xét trong các truy vấn như chọn m. tác giả_id là m_ Author_id, a. Author_id với tư cách là a_ Author_id, đếm (phân biệt m.post_id) dưới dạng bài đăng từ các bình luận khi m tham gia bình luận dưới dạng nhóm sử dụng (post_id) bởi m. mượt_id_id, a. tác giả_id

Trong trường hợp bạn quan tâm đến việc mã hóa các từ trong bình luận cho nlp, hãy thêm một bảng khác cho điều đó nhưng hãy nhớ rằng nó sẽ tăng khối lượng dữ liệu của bạn một cách đáng kể. Thường thì tốt hơn là không thể hiện toàn bộ mã thông báo trong cơ sở dữ liệu.

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.