2012-12-12 28 views
7

Tôi yêu cầu một trường hợp cụ thể cho Java + JPA/Hibernate + Mysql, nhưng tôi nghĩ bạn có thể áp dụng câu hỏi này cho một số lượng lớn ngôn ngữ.Khi nào sử dụng truy vấn hoặc mã số

Thỉnh thoảng tôi phải thực hiện truy vấn trên cơ sở dữ liệu để nhận một số thực thể, chẳng hạn như nhân viên. Giả sử bạn cần một số nhân viên cụ thể (những người có 'John' làm tên họ), bạn có muốn truy vấn trả về bộ nhân viên chính xác này hay bạn muốn tìm kiếm tất cả nhân viên và sau đó sử dụng ngôn ngữ lập trình để truy xuất những người mà bạn quan tâm? lý do tại sao (dễ dàng, hiệu quả)? Cái nào (nói chung) hiệu quả hơn?

Có một phương pháp nào tốt hơn phương pháp khác tùy thuộc vào kích thước bảng không?

Xét:

  • Cùng phức tạp, tái sử dụng trong cả hai trường hợp.
+4

Điều gì là tốt hơn: để lưu trữ nhiều thực phẩm ở nhà hoặc mua từng chút một? Khi bạn đi du lịch nhiều? Chỉ khi tổ chức một bữa tiệc? Nó phụ thuộc, phải không? Tương tự, cách tiếp cận tốt nhất là vấn đề tối ưu hóa hiệu suất. Điều đó liên quan đến rất nhiều biến.Nghệ thuật là để cả hai ngăn bức tranh mình vào một góc khi thiết kế giải pháp của bạn và tối ưu hóa sau này, khi bạn biết tắc nghẽn thực sự của bạn. Một điểm khởi đầu tốt là ở đây: http://en.wikipedia.org/wiki/Performance_tuning Một suy nghĩ có thể hữu ích hơn hoặc ít phổ biến hơn: đóng gói dữ liệu của bạn tốt. –

+0

Tôi sẽ nói câu trả lời của bạn thực sự là câu trả lời mà bạn có thể học hỏi nhiều nhất! – dgmora

+0

@ dgarcia, cảm ơn bạn. Tôi đang quảng cáo nó thành một câu trả lời trong trường hợp bạn muốn một người chấp nhận. –

Trả lời

4

Có một mẹo chung thường được sử dụng trong lập trình - thanh toán bằng bộ nhớ để tăng tốc hoạt động. Nếu bạn có rất nhiều nhân viên, và bạn sẽ truy vấn một phần đáng kể của họ, từng người một (nói, 75% sẽ được truy vấn cùng một lúc hoặc lần khác), sau đó truy vấn mọi thứ, cache nó (rất quan trọng!) và hoàn thành tra cứu trong bộ nhớ. Lần tiếp theo bạn truy vấn, bỏ qua chuyến đi tới RDBMS, chuyển thẳng tới bộ nhớ cache và thực hiện tra cứu nhanh: một vòng lặp tới cơ sở dữ liệu rất tốn kém, so với tra cứu băm trong bộ nhớ. Mặt khác, nếu bạn đang truy cập một phần nhỏ nhân viên, bạn chỉ nên truy vấn một nhân viên: chuyển dữ liệu từ RDBMS sang chương trình của bạn mất rất nhiều thời gian, nhiều băng thông mạng, nhiều bộ nhớ về phía bạn, và rất nhiều bộ nhớ ở phía RDBMS. Truy vấn rất nhiều hàng để vứt bỏ tất cả nhưng không bao giờ có ý nghĩa.

10

Luôn thực hiện truy vấn trên cơ sở dữ liệu. Nếu bạn không phải sao chép nhiều dữ liệu hơn cho máy khách và cơ sở dữ liệu cũng được ghi để lọc dữ liệu hiệu quả gần như chắc chắn hiệu quả hơn mã của bạn.

Ngoại lệ duy nhất tôi có thể nghĩ là nếu điều kiện bộ lọc phức tạp về tính toán và bạn có thể trải rộng phép tính trên sức mạnh CPU nhiều hơn cơ sở dữ liệu.

Trong trường hợp tôi đã có cơ sở dữ liệu, máy chủ đã có nhiều CPU hơn so với máy khách, trừ khi quá tải sẽ chỉ chạy truy vấn nhanh hơn với cùng một lượng mã.

Ngoài ra, bạn phải viết ít mã hơn để thực hiện truy vấn trên cơ sở dữ liệu bằng ngôn ngữ truy vấn Hibernates thay vì bạn phải viết mã để thao tác dữ liệu trên máy khách. Các truy vấn Hibernate cũng sẽ sử dụng bất kỳ bộ nhớ đệm máy khách nào trong cấu hình mà không cần phải viết thêm mã.

2

Đó là tình huống. Tôi nghĩ rằng nói chung, tốt hơn là sử dụng sql để có được tập hợp kết quả chính xác.

Sự cố khi tải tất cả các thực thể và sau đó tìm kiếm theo chương trình là bạn sẽ tải tất cả các quyền lợi, có thể mất rất nhiều bộ nhớ. Ngoài ra, bạn phải tìm kiếm tất cả các thực thể. Tại sao làm điều đó khi bạn có thể tận dụng RDBMS của bạn và nhận được kết quả chính xác mà bạn muốn. Nói cách khác, tại sao tải một tập dữ liệu lớn có thể sử dụng quá nhiều bộ nhớ, sau đó xử lý nó, khi bạn có thể cho phép RDBMS của bạn làm công việc cho bạn? Mặt khác, nếu bạn biết kích thước của tập dữ liệu của bạn không phải là quá, bạn có thể tải nó vào bộ nhớ và sau đó truy vấn nó - điều này có lợi thế mà bạn không cần phải đi đến RDBMS, trong đó có thể hoặc có thể không yêu cầu đi qua mạng của bạn, tùy thuộc vào kiến ​​trúc hệ thống của bạn.

Tuy nhiên, ngay cả khi đó, bạn có thể sử dụng các tiện ích lưu bộ nhớ cache khác nhau để kết quả truy vấn phổ biến được lưu vào bộ nhớ cache, loại bỏ lợi thế của việc lưu dữ liệu vào bộ nhớ cache.

4

Nói chung, tôi sẽ để cơ sở dữ liệu làm những gì cơ sở dữ liệu là tốt. Lọc dữ liệu là một số cơ sở dữ liệu thực sự tốt, vì vậy nó sẽ là tốt nhất còn lại ở đó.

Điều đó nói rằng, có một số tình huống mà bạn có thể chỉ muốn lấy tất cả chúng và thực hiện lọc theo mã. Một trong những tôi có thể nghĩ sẽ là nếu số lượng hàng là tương đối nhỏ và bạn có kế hoạch để lưu trữ chúng trong ứng dụng của bạn.Trong trường hợp đó, bạn sẽ chỉ tìm kiếm tất cả các hàng, lưu trữ chúng và lọc tiếp theo dựa vào những gì bạn có trong bộ nhớ cache.

2

Hãy nhớ rằng phương pháp tiếp cận của bạn nên mở rộng theo thời gian. Những gì có thể là một tập dữ liệu nhỏ sau đó có thể biến thành một tập dữ liệu khổng lồ theo thời gian. Chúng tôi đã gặp sự cố với một lập trình viên đã mã hóa ứng dụng để truy vấn toàn bộ bảng rồi chạy các thao tác trên đó. Cách tiếp cận này hoạt động tốt khi chỉ có 100 hàng với hai lựa chọn, nhưng khi dữ liệu tăng lên qua các năm, các vấn đề hiệu suất trở nên rõ ràng. Chèn ngay cả bộ lọc ngày để chỉ truy vấn 365 ngày qua, có thể giúp quy mô ứng dụng của bạn tốt hơn.

1

- nếu bạn đang tìm kiếm một câu trả lời cụ thể để hibernate, kiểm tra @ Mark câu trả lời

Với ví dụ nhân viên -assuming số lượng nhân viên có thể mở rộng theo thời gian, nó là tốt hơn để sử dụng một cách tiếp cận để truy vấn cơ sở dữ liệu cho dữ liệu chính xác. Tuy nhiên, nếu bạn đang cân nhắc một cái gì đó như Bộ (ví dụ), nơi mà cơ hội của dữ liệu ngày càng tăng nhanh thì sẽ rất hữu ích khi truy vấn tất cả chúng và có trong bộ nhớ - theo cách này bạn không cần phải tiếp cận tài nguyên bên ngoài (cơ sở dữ liệu) mỗi lần, có thể tốn kém.

Vì vậy, các thông số nói chung là những,

  1. rộng của dữ liệu
  2. criticality để kinh doanh
  3. khối lượng dữ liệu
  4. tần số sử dụng

để đưa một số ý nghĩa, khi dữ liệu không thường xuyên mở rộng và dữ liệu không phải là nhiệm vụ quan trọng và khối lượng dữ liệu có thể quản lý được trong bộ nhớ trên pplication server và được sử dụng thường xuyên - Mang theo tất cả và lọc chúng theo chương trình, nếu cần.

nếu không thì chỉ nhận được dữ liệu cụ thể.

1

Điều gì là tốt hơn: để lưu trữ nhiều thực phẩm ở nhà hoặc mua từng chút một? Khi bạn đi du lịch nhiều? Chỉ khi tổ chức một bữa tiệc? Nó phụ thuộc, phải không? Tương tự, cách tiếp cận tốt nhất là vấn đề tối ưu hóa hiệu suất. Điều đó liên quan đến rất nhiều biến. Nghệ thuật là để cả hai ngăn bức tranh mình vào một góc khi thiết kế giải pháp của bạn và tối ưu hóa sau này, khi bạn biết tắc nghẽn thực sự của bạn. Một điểm khởi đầu tốt là ở đây: en.wikipedia.org/wiki/Performance_tuning Một suy nghĩ có thể hữu ích nhiều hay ít trên toàn cầu: đóng gói dữ liệu của bạn tốt.

+0

Tôi không chọn nó làm câu trả lời vì nó không phải là 'trả lời' một cách thẳng thắn chủ đề chính, mặc dù tôi nghĩ nó khá hữu ích – dgmora

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