Tôi thực sự thích ORM so với quy trình lưu trữ, nhưng một điều mà tôi sợ là ORM có thể chậm, vì các lớp và lớp trừu tượng. Việc sử dụng ORM có làm chậm ứng dụng của tôi không? Hay nó quan trọng?ORM có chậm không? Nó có quan trọng không?
Có, điều đó quan trọng. Nó đang sử dụng nhiều chu kỳ CPU hơn và do đó làm chậm ứng dụng của bạn. Hãy nghe tôi mặc dù ...
Nhưng, hãy cân nhắc điều này: điều gì đắt hơn? Phần cứng máy chủ hoặc một lập trình viên khác? Phần cứng máy chủ, nói chung, rẻ hơn việc thuê một nhóm lập trình viên khác. Vì vậy, trong khi ORM có thể làm bạn mất chi phí cho chu kỳ CPU, bạn cần một lập trình viên ít hơn để quản lý các truy vấn SQL của mình, thường dẫn đến chi phí ròng thấp hơn.
Để xác định xem nó có xứng đáng với bạn hay không, hãy tính toán hoặc xác định số giờ bạn đã lưu bằng cách sử dụng ORM. Sau đó, tìm ra số tiền bạn đã chi tiêu trên máy chủ để hỗ trợ ORM. Nhân số giờ bạn đã lưu theo tỷ lệ giờ của bạn và so sánh với chi phí máy chủ.
Tất nhiên, cho dù một ORM thực sự giúp bạn tiết kiệm thời gian là một toàn thể cuộc tranh luận khác ...
+1 Đây là một khởi đầu tuyệt vời. Có thêm các mối quan tâm, chẳng hạn như các yêu cầu về độ trễ mà bạn không giải quyết ở đây. Tùy thuộc vào mức độ khủng khiếp của kiến trúc hiện tại, việc thêm một máy chủ khác có thể không phải là một tùy chọn, bởi vì bạn có thể phải thuê người để thiết kế giải pháp cho một vấn đề chưa được giải quyết (ví dụ: sao lưu cân bằng/db sao lưu/chuyển đổi dự phòng, sao lưu từ nhiều nguồn, v.v.) –
Tôi nghĩ rằng các chu kỳ và lớp CPU bổ sung không phải là vấn đề, nhưng truy cập cơ sở dữ liệu, nếu không được tối ưu hóa tốt. Các máy ngày hiện đại có nhiều hơn sức mạnh của CPU, nhưng hàng trăm vòng tròn SQL cho một nhiệm vụ đơn giản vẫn còn là một vấn đề. (đúng vào năm 2013 cũng như năm 2009) –
trả lời rõ ràng: Nó phụ thuộc
ORM làm một công việc tốt về cách một lập trình viên từ SQL. Điều này có hiệu lực thay thế tầm thường, máy tính tạo ra các truy vấn cho các truy vấn thảm họa xấu mà một lập trình viên có thể cung cấp.
Ngay cả trong trường hợp tốt nhất, ORM sẽ thực hiện thêm một số công việc, tải các trường không cần, kiểm tra ràng buộc rõ ràng, v.v.
Khi chúng trở thành một chai cổ, hầu hết ORM cho phép bạn bước bên họ và tiêm SQL thô.
Nếu ứng dụng của bạn phù hợp với các đối tượng, nhưng không hoàn toàn dễ dàng như vậy với các mối quan hệ, thì đây vẫn có thể là một chiến thắng. Thay vào đó, nếu ứng dụng của bạn phù hợp với mô hình quan hệ, thì ORM sẽ biểu thị một nút cổ chai trên đầu trang của một nút cổ chai hiệu suất có thể xảy ra.
Một điều tôi thấy đặc biệt xúc phạm về phần lớn ORM là việc xử lý khóa chính của họ. Hầu hết ORM yêu cầu pk cho tất cả mọi thứ họ chạm vào, ngay cả khi không có sử dụng đáng tin cậy cho họ. Ví dụ: Tác giả nên có pk, Blog bài viết NÊN có pk, nhưng các liên kết (tham gia bảng) giữa tác giả và bài viết thì không.
Bạn có nói rằng hầu hết ORM không hỗ trợ các khóa chính kết hợp? – Teson
Vâng, tôi không thể nói quá nhiều về nhiều ORM của tôi đã không được sử dụng, nhưng của ORM của tôi đã sử dụng, có, đó là chính xác. – SingleNegationElimination
ORM có chậm không?
Có (so với các thủ tục lưu trữ)
Có vấn đề gì?
Không (ngoại trừ mối quan tâm của bạn là tốc độ)
Tôi nghĩ vấn đề là nhiều người nghĩ về ORM như một đối tượng "lừa" để cơ sở dữ liệu, mã ít hoặc đơn giản hóa việc sử dụng SQL, trong khi trên thực tế là .. cũng là một đối tượng - Để quan hệ (DB) - Lập bản đồ.
ORM được sử dụng để kéo dài các đối tượng thành một hệ thống quản lý cơ sở dữ liệu quan hệ, và không (chỉ) để thay thế hoặc làm cho SQL dễ dàng hơn (mặc dù nó làm cho một công việc tốt ở đó quá)
Nếu bạn không có một mô hình đối tượng tốt hoặc bạn đang sử dụng để tạo báo cáo hoặc thậm chí nếu bạn chỉ đang cố gắng lấy một số thông tin, thì ORM không đáng giá.
Nếu bạn có một hệ thống phức tạp được mô hình hóa thông qua các đối tượng thì mỗi quy tắc có các quy tắc khác nhau và chúng tương tác động và bạn quan tâm đến thông tin đó vào cơ sở dữ liệu thay vì thay thế một số tập lệnh SQL hiện có.
Có, ORM sẽ làm chậm ứng dụng của bạn. Bởi bao nhiêu phụ thuộc vào cách xa trừu tượng đi, như thế nào mô hình đối tượng của bạn ánh xạ đến cơ sở dữ liệu, và các yếu tố khác. Câu hỏi đặt ra là, bạn có sẵn sàng dành nhiều thời gian cho nhà phát triển hơn và sử dụng quyền truy cập dữ liệu thẳng hoặc trao đổi ít thời gian cho thời gian chạy chậm hơn.
Nhìn chung, các ORM tốt có ít chi phí đầu vào và, bởi và lớn, được coi là đáng để trao đổi.
Tôi luôn thấy nó không quan trọng. Bạn nên sử dụng bất cứ điều gì sẽ làm cho bạn hiệu quả nhất, đáp ứng với những thay đổi, và bất cứ điều gì là dễ nhất để gỡ lỗi và duy trì.
Hầu hết các ứng dụng không bao giờ cần đủ tải cho sự khác biệt giữa ORM và SPs đáng chú ý. Và có tối ưu hóa để làm cho ORM nhanh hơn.
Cuối cùng, một ứng dụng được viết tốt sẽ có quyền truy cập dữ liệu của nó được phân tách từ mọi thứ khác để trong tương lai chuyển đổi từ ORM sang bất kỳ điều gì có thể.
Một ORM sẽ luôn thêm một số phí trên vì các lớp trừu tượng nhưng trừ khi nó là một ORM được thiết kế kém nên tối thiểu. Thời gian để thực sự truy vấn cơ sở dữ liệu sẽ nhiều gấp nhiều lần chi phí bổ sung của cơ sở hạ tầng ORM nếu bạn làm đúng, ví dụ như không tải đồ thị đầy đủ khi không cần thiết. Một ORM tốt (nHibernate) cũng sẽ cung cấp cho bạn nhiều tùy chọn cho các truy vấn chạy trên cơ sở dữ liệu để bạn có thể tối ưu hóa theo yêu cầu.
Tôi chưa bao giờ thực sự hiểu tại sao mọi người nghĩ rằng điều này chậm hơn hoặc chậm hơn ... có được một máy thật tôi nói. Tôi đã có kết quả hỗn hợp ... Tôi đã nhìn thấy thời gian thực hiện cho một thủ tục được lưu trữ là chậm hơn nhiều so với ORM và ngược lại .. Nhưng trong cả hai trường hợp hiệu suất là do sự khác biệt trong phần cứng.
ORM gần như chậm hơn theo định nghĩa. Nó là một lớp khác phải theo dõi trạng thái của chính nó và trạng thái trong cơ sở dữ liệu. Do đó nó không thể nhanh hơn một truy vấn được viết tốt. Ngoài ra, nếu bạn không biết các hoạt động bên trong (mục đích của ORM là gì, để che chắn các hoạt động bên trong), bạn có thể tạo các truy vấn đáng sợ. – David
Tôi nhận thấy rằng sự khác biệt giữa "quá chậm" và "không quá chậm" phụ thuộc vào việc bạn có bật bộ nhớ cache cấp 2 (SessionFactory) ORM của mình hay không. Với nó tắt nó xử lý tốt theo tải phát triển, nhưng sẽ đè bẹp hệ thống của bạn dưới tải sản xuất nhẹ. Sau khi bật bộ nhớ cache Cấp 2, máy chủ xử lý tải dự kiến và thu nhỏ một cách độc đáo.
Sử dụng ORM thường chậm hơn. Nhưng việc tăng năng suất bạn nhận được sẽ giúp ứng dụng của bạn hoạt động và chạy nhanh hơn nhiều. Và thời gian bạn tiết kiệm sau đó có thể được chi tiêu cho việc tìm kiếm các phần ứng dụng đang gây chậm lớn nhất - sau đó bạn có thể dành thời gian tối ưu hóa các lĩnh vực mà bạn nhận được lợi tức cao nhất cho nỗ lực phát triển của mình. Chỉ vì bạn đã quyết định sử dụng ORM không có nghĩa là bạn không thể sử dụng các kỹ thuật khác trong các phần mã thực sự có thể hưởng lợi từ nó.
Một ORM có thể chậm hơn, nhưng điều này được bù đắp bởi khả năng lưu dữ liệu của bộ nhớ cache, do đó, nhanh chóng thay thế, bạn không thể nhận được nhanh hơn nhiều so với đọc từ bộ nhớ.
Trong dự án Windows Mobile 5 chống lại việc sử dụng SqlCe, tôi đã sử dụng các đối tượng được mã hóa bằng tay cho các đối tượng được tạo mã (CodeSmith) sử dụng mẫu ORM. Trong quá trình này, tất cả truy cập dữ liệu của tôi đã sử dụng CSLA làm lớp cơ sở.
Chuyển đổi thẳng đã cải thiện hiệu suất của tôi thêm 32% trong thử nghiệm cục bộ, hầu như tất cả đều là kết quả của các phương pháp truy cập tốt hơn. Sau khi thay đổi đó, chúng tôi điều chỉnh các mẫu (sau khi nhìn thấy một số công cụ hiệu suất SqlCe tại PDC bởi Steve Lasker) và sau đó ít hơn 20 phút, toàn bộ lớp dữ liệu của chúng tôi được cải thiện rất nhiều, các cuộc gọi chậm chạp của chúng tôi đã tăng từ 460 mili giây lên đến 20 giây. ~ 20ms. Phần thú vị về các công cụ ORM là chúng tôi chỉ phải thực hiện (và kiểm tra đơn vị) những thay đổi này một lần và tất cả các mã truy cập dữ liệu đã thay đổi. Đó là một tiết kiệm thời gian tuyệt vời, chúng tôi có thể tiết kiệm 40 giờ hoặc hơn.
Ở trên đang được nói, chúng tôi đã mất một thời gian bằng cách lấy ra một loạt các hộp thoại 'chờ đợi' và 'tiến bộ' không còn cần thiết nữa.
Tôi đã sử dụng một vài trong số những công cụ ORM, và tôi có thể giới thiệu hai trong số họ:
Cả hai trong số họ đã thực hiện khá độc đáo và bất kỳ tổn thất hiệu suất đã không được chú ý.
ORM có chậm không?
Không vốn có. Một số ORM nặng có thể thêm một kéo chung cho mọi thứ nhưng chúng tôi không nói đơn đặt hàng của cường độ chậm lại.
Điều gì không làm cho ORM chậm là sử dụng ngây thơ. Nếu bạn đang sử dụng ORM vì có vẻ dễ dàng và bạn không biết cách mô hình dữ liệu quan hệ cơ bản hoạt động, bạn có thể dễ dàng viết mã có vẻ hợp lý cho một lập trình viên OO, nhưng sẽ giết hiệu suất.
ORM là một công cụ hữu ích, nhưng bạn cần sự hiểu biết cấp thấp hơn (thường đến từ việc viết các truy vấn SQL) để đi cùng với nó.
Có quan trọng không?
Nếu bạn kết thúc thực hiện truy vấn lặp cho mỗi nghìn thực thể cùng một lúc, thay vì tham gia nhanh, thì chắc chắn có thể.
Có, ORM ảnh hưởng đến hiệu suất, cho dù vấn đề đó có phụ thuộc cuối cùng vào chi tiết cụ thể của dự án của bạn hay không.
Các lập trình viên thường yêu ORM vì họ thích sự thoải mái front-end cding môi trường như Visual Studio và không thích mã hóa SQL thô không có IntelliSense vv
ORMs có những hạn chế khác ngoài một hit hiệu suất - họ cũng thường làm không làm những gì bạn cần 100% thời gian, thêm độ phức tạp của một lớp trừu tượng bổ sung phải được duy trì và thiết lập lại mỗi khi các chhnges được thực hiện, cũng có các vấn đề về bộ nhớ đệm được xử lý.
Chỉ cần suy nghĩ - nếu nhà cung cấp cơ sở dữ liệu làm cho môi trường lập trình SQL đẹp như Visual Studio và cung cấp liên kết tự nhiên hơn giữa mã db và mã front-end, chúng tôi sẽ không cần ORM. Tôi đoán mọi thứ có thể đi theo hướng đó cuối cùng.
Có thể là _hundreds_ của các công cụ SQL dev dựa trên GUI với intellisense/autocomplete. –
@John lol chính xác. –
* nếu nhà cung cấp cơ sở dữ liệu làm cho môi trường lập trình SQL đẹp như Visual Studio và cung cấp liên kết tự nhiên hơn giữa mã db và mã front-end, chúng tôi sẽ không cần ORM * ** Điều này có nghĩa là gì? * * – nawfal
ORM có thể nhận được thứ tự cường độ chậm hơn, không chỉ trên grount = s lãng phí rất nhiều chu kỳ CPU trên chính nó mà còn sử dụng nhiều memeory mà sau đó phải là GC-d.
Tuy nhiên, điều này không có tiêu chuẩn cho ORM (không giống SQL) và việc sử dụng ORM-s của tôi và ORM-s khác nhau không hiệu quả nên cuối cùng bạn vẫn phải tìm hiểu SQL để sửa các vấn đề và mỗi khi ORM tạo ra một mớ hỗn độn và bạn phải gỡ lỗi nó. Có nghĩa là bạn đã không đạt được gì cả.
Công nghệ cực kỳ chưa trưởng thành đối với các ứng dụng cấp sản xuất thực tế. Những thứ rất khó giải quyết là xử lý các chỉ mục, các khóa ngoài, chỉnh các bảng để phù hợp với các hệ thống phân cấp đối tượng và các giao dịch dài khủng khiếp, có nghĩa là nhiều sự tắc nghẽn và lặp lại hơn - nếu một ORM biết các phép để xử lý điều đó. Nó thực sự làm cho máy chủ ít khả năng mở rộng mà nhân chi phí nhưng những chi phí này không được đề cập ở đầu - một chút bất tiện :-) Khi một cái gì đó sử dụng giao dịch 10-100 lần lớn hơn tối ưu nó trở thành không thể quy mô bên SQL ở tất cả. Nói về hệ thống nghiêm túc một lần nữa không phải là nhà/đồ chơi/công cụ học tập.
ORM là chậm hơn và làm thêm phí cho các ứng dụng (trừ khi bạn biết cách giải quyết các vấn đề này, điều này không phổ biến lắm). Cơ sở dữ liệu là yếu tố quan trọng nhất và các ứng dụng Web nên được thiết kế xung quanh nó.
Nhiều khung công tác OOP sử dụng Active Record hoặc ORM, các nhà phát triển nói chung - coi cơ sở dữ liệu là một ý tưởng không quan trọng và có xu hướng xem nó như là thứ họ không thực sự cần học. Nhưng hiệu suất và khả năng mở rộng thường bị ảnh hưởng khi db bị đánh thuế nặng nề!
Nhiều ứng dụng web quy mô lớn đã giảm phẳng, lãng phí hàng triệu và hàng tháng qua nhiều năm bởi vì họ không nhận ra tầm quan trọng của cơ sở dữ liệu. Hàng trăm người dùng và bảng đồng thời với hàng triệu bản ghi yêu cầu điều chỉnh và tối ưu hóa cơ sở dữ liệu. Nhưng tôi tin rằng vấn đề là đáng chú ý với một vài người dùng và ít dữ liệu hơn.
Tại sao các nhà phát triển ngại tìm hiểu các biện pháp điều chỉnh và SQL thích hợp khi đó là chìa khóa để thực hiện?
* "Tôi thực sự thích ORM so với quy trình lưu trữ" * - táo và cam. –