2012-05-15 22 views
8

Chi phí sử dụng Java ORM cho MongoDB là gì, hoặc tốt hơn là chúng ta đi ở cấp độ trình điều khiển cơ bản để đọc hoặc ghi?Chi phí đầu vào của Java ORM cho MongoDB

Chúng tôi sẽ thêm Mongo DB cho một trong các yêu cầu của chúng tôi.

Có vài công cụ lập bản đồ java ORM cho java
-morphia
-spring dữ liệu
- others

nha phiến phiên bản cuối cùng được phát hành hơn một năm trước đây
nhưng dữ liệu Xuân đang tích cực được duy trì. Nên sử dụng cái nào nếu tôi chuẩn bị bắt đầu ngay bây giờ,

+1

Không phải "R" trong ORM là viết tắt của "quan hệ"? – duffymo

+1

Có, vị trí của nó cho Ánh xạ đối tượng/quan hệ, thường được sử dụng với cơ sở dữ liệu quan hệ nhưng có thể được sử dụng chung với bất kỳ loại cơ sở dữ liệu nào. – mtariq

+0

@duffymo trong trường hợp này Morphia thực sự * không * bản đồ quan hệ giữa các bộ sưu tập. Một vài trong số các trình bao bọc của Ruby có các tính năng tương tự. –

Trả lời

11

Sử dụng ORM làm giảm hiệu suất nhưng nó làm tăng tốc độ phát triển. Có một giao dịch ở đây.

Đối với công cụ ORM, Morphia là loại ổn định nhất. Here bạn có thể tìm thấy sự so sánh giữa Morphia và Basic Mongo Driver bởi hiệu suất của chúng.

+2

So sánh hiệu suất tốt hơn [liên kết] (https://groups.google.com/forum/?fromgroups#!topic/morphia/kGCF2I3ZKRU) – mtariq

+0

Liên kết được thêm vào câu trả lời của bạn dường như không còn khả dụng nữa. – sakura

4

Có một vài điều cần đề cập ở đây nói chung. Đi kèm với điểm chuẩn cho rằng là khá khó khăn như bạn không thể thực sự kiểm tra hiệu suất mà không cần thử nghiệm thiết lập MongoDB của bạn là tốt. Vì vậy, người ta có thể khá nhiều có thể tinh chỉnh và điều chỉnh những môi trường để cung cấp các kết quả mong muốn.

Ngoài ra, bạn phải phân biệt giữa hiệu suất đọc và ghi. Đặc biệt là viết chịu ảnh hưởng nặng nề của việc sử dụng WriteConcern. Vì vậy, những gì có thể là một chi phí của 50% trong một kịch bản WriteConcern.NONE có thể dễ dàng chuyển xuống dưới 5% với một WriteConcern.SAFE. Có, chắc chắn là một chi phí trong bất kỳ việc thực hiện ODM nào khi ánh xạ đối tượng < ->DBObject phải kiểm tra đối tượng nhận và đặt giá trị thường thông qua sự phản chiếu. Do đó, IMHO điểm quan trọng là khả năng cắm các trình chuyển đổi được mã hóa theo cách thủ công mà bạn có thể muốn cung cấp cho các đối tượng quan trọng về hiệu suất. Đối với dữ liệu mùa xuân, bạn chỉ cần đăng ký EntityInstantiator tùy chỉnh new Person(…) thay vì để cho phép mặc định làm phép thuật phản chiếu của nó mang lại hiệu suất lớn.

Nhóm dữ liệu mùa xuân có build thiết lập hiệu suất trọng số xây dựng của phiên bản OTS MongoDB để viết trên WriteConcern s khác và đọc qua trình điều khiển đơn giản, MongoTemplate và kho lưu trữ trừu tượng. Các con số được lấy bằng một hạt muối vì đôi khi chúng hiển thị các kho lưu trữ dữ liệu đọc nhanh hơn các mẫu mà bị ảnh hưởng bởi cơ sở hạ tầng bởi một số có nghĩa là nó là một lớp trên cùng của mẫu nhưng không t thực sự thêm bất kỳ bộ nhớ đệm.

+1

Bạn có nghĩ rằng dữ liệu mùa xuân có thể nhanh hơn morphia? – mtariq

+1

Tất nhiên nó có thể. Nhưng tất nhiên Morphia cũng có thể nhanh hơn Spring Data. Tôi nghĩ điểm quan trọng là - như phác thảo ở trên - trong bao xa bạn có thể mã thủ đối tượng để ánh xạ DBObject cho các loại hóa ra là cổ chai để ngăn chặn cơ sở hạ tầng bản đồ chung ảnh hưởng đến hiệu suất quá nhiều. Nếu bạn bị mắc kẹt với cách tiếp cận ánh xạ không thể tùy chỉnh, điều đó thật tệ. –

Các vấn đề liên quan