Chi phí thực hiện ORM

Question

Có ai có kinh nghiệm cho biết loại hiệu suất nào mà nhà phát triển đạt được bằng cách chọn sử dụng ORM (trong Django, RoR, SQLAlechemy, v.v.) trên cơ sở dữ liệu SQL và thiết kế thủ công không? Tôi tưởng tượng có những vấn đề phức tạp, bao gồm việc xác định một cơ sở dữ liệu trong các ràng buộc của ORM tăng hay giảm cơ hội tạo ra một cấu trúc cơ sở dữ liệu hiệu quả (dựa trên mức độ kinh nghiệm của nhà phát triển) và câu hỏi về cách nhà phát triển xây dựng Các truy vấn dựa trên SQL hoặc ORM (một lần nữa dựa trên kinh nghiệm của họ). Bất kỳ thông tin nào liên quan đến các vấn đề về hiệu suất nội tại hoặc thực tế này sẽ thực sự thú vị đối với tôi.

Answer 1

Lời khuyên của tôi không phải lo lắng về điều này cho đến khi bạn cần - đừng tối ưu hóa sớm. Một ORM có thể cung cấp nhiều lợi ích cho tốc độ phát triển, khả năng đọc mã và có thể loại bỏ rất nhiều sự lặp lại mã. Tôi sẽ khuyên bạn nên sử dụng một nếu nó sẽ làm cho ứng dụng của bạn dễ dàng hơn để phát triển.

Khi bạn tiến hành thông qua các điểm chuẩn sử dụng phát triển và lược tả để xác định các nút cổ chai trong mã và nếu cần, bạn có thể bỏ qua ORM và sử dụng truy vấn thủ công khi chúng được yêu cầu. Thông thường, bạn sẽ có thể cải thiện tốc độ của ORM bằng cách sử dụng bộ nhớ đệm và các chỉ mục cơ sở dữ liệu (trong số những thứ khác) và sau đó bạn có thể quyết định các truy vấn thủ công được yêu cầu ở đâu. Đối với hầu hết các phần, hiệu suất ORM có lẽ sẽ chấp nhận được và lợi ích của việc sử dụng nó sẽ vượt xa chi phí hiệu suất.

Answer 2

Điều này phụ thuộc rất nhiều vào những gì bạn so sánh. Các coder viết mã tay là một hack tổng số nó có thể là một lợi ích hơn là một hit. Rõ ràng nó có thể đi theo cách khác là tốt.

Answer 3

Nó cũng phụ thuộc vào những gì bạn đang sử dụng làm ORM. Theo kinh nghiệm của tôi, Hibernate là một con lợn, về mặt tốc độ, sử dụng tài nguyên và thời gian khởi động. LINQ to SQL, mặt khác, là một trình bao bọc SQL cực kỳ nhẹ, có tác động mà bạn có thể sẽ không chú ý (nếu có).

Answer 4

Hiệu suất luôn là một suy nghĩ sau trong hầu hết các cấu trúc/phát triển DAL Layer. Tôi nghĩ khoảng thời gian của chúng tôi bắt đầu đặt câu hỏi về hiệu suất của các công cụ ORM, cho cái gọi là dễ dàng phát triển họ hứa:

2 khu vực lớn nhất của vấn đề hiệu suất trong ORMs là:

1. Không có khả năng viết SQL tối ưu. Bạn phải sử dụng một ngôn ngữ truy vấn đối tượng được diễn giải trong SQL bởi khung công tác. Chủ yếu nó là SQL tốt, nhưng thường đủ nó không phải là SQL hiệu quả nhất.

2. Phản ánh. Hầu hết các khung công tác ORM đều sử dụng Reflection để điền các đối tượng có dữ liệu từ cơ sở dữ liệu. Các hoạt động phản xạ rất tốn kém và với số lượng tải và dữ liệu ngày càng tăng, sự suy giảm hiệu suất trở nên rõ ràng.

Các vấn đề hiệu suất khác phát sinh là do thiết kế mô hình cơ sở dữ liệu hoặc thực thể không hiệu quả do khớp nối chặt chẽ đối tượng thực thể với bảng.

Answer 5

Hiệu suất - luôn luôn chuyên nghiệp và chống đối. Nếu bạn thâm nhập sâu hơn vào kiến ​​trúc ORM (xem bài viết của tôi: avoid ORM bad habits) thì bạn sẽ tìm thấy những cách trực quan để làm cho nó nhanh hơn.Dưới đây là một bài viết của tôi về cách làm cho EF6x 5x nhanh (ít nhất là cho các tình huống đã đọc): EF6.x 5x faster

Nhưng dù sao cho hiệu suất tốt, ngay cả với ORM bạn sẽ cần phải tạo ra quan điểm cơ sở dữ liệu, chỉ số quá như để kiểm tra các truy vấn được tạo ra và được thực hiện bởi ORM và tinh chỉnh chúng quá. Đang tải trình phát là phải với ORM.