So sánh hiệu suất của Derby so với PostgreSql

Question

Hiện tại, chúng tôi đang nghiên cứu về việc chuyển đổi db postgresql của chúng ta thành một Derby Derby nhúng hay không. Cả hai sẽ sử dụng glassfish 3 cho lớp dữ liệu của chúng tôi. Bất kỳ ai có bất kỳ ý kiến ​​hay kiến ​​thức nào có thể giúp chúng tôi quyết định?

Cảm ơn!

chỉnh sửa: hiện tại chúng tôi đang viết một số thử nghiệm hiệu suất. Tìm câu trả lời hơn dựa trên kiến ​​thức kinh nghiệm/tay đầu tiên

Answer 1

Một số số liệu thống kê từ các cơ sở dữ liệu trang web H2 ở đây: http://www.h2database.com/html/performance.html

Answer 2

Chưa so PostgreSQL để Derby trực tiếp. Tuy nhiên, khi sử dụng cả hai trong hoàn cảnh khác nhau, tôi đã tìm thấy Derby là một người đáng tin cậy. Tuy nhiên, bạn sẽ cần phải chú ý đến cấu hình Derby để đảm bảo nó phù hợp với nhu cầu ứng dụng của bạn.

Answer 3

Có một số bộ thử nghiệm hiệu suất được bao gồm như một phần của bản thân phân phối mã nguồn Derby; chúng được các nhà phát triển Derby sử dụng để tiến hành thử nghiệm hiệu suất của riêng họ về Derby. Vì vậy, nếu bạn cần ví dụ về các bài kiểm tra hiệu suất, hoặc muốn các bài kiểm tra bổ sung, bạn có thể xem xét sử dụng các bài kiểm tra đó. Tìm trong thư mục con có tên là java/testing/org/apache/derbyTesting/perf trong bản phân phối nguồn Derby.

Answer 4

Khi xem xét trang web thống kê cơ sở dữ liệu H2, bạn nên đọc phần thảo luận tiếp theo về lợi ích của Derby so với kết luận H2. http://groups.google.com/group/h2-database/browse_thread/thread/55a7558563248148?pli=1

Answer 5

Derby vẫn hoạt động tương đối chậm, nhưng ... khi ứng dụng Java của bạn đi vào máy chủ cơ sở dữ liệu, hoàn toàn độc lập với nền tảng. Bạn thậm chí không cần phải suy nghĩ về việc cài đặt một máy chủ DB, nơi ứng dụng Java của bạn đang được sao chép vào.

Tôi đã sử dụng MySQL với Java, nhưng việc triển khai nhúng máy chủ Cơ sở dữ liệu của bạn nằm ngay trong Ứng dụng Java của tôi chỉ là năng suất, tự do và linh hoạt tuyệt vời và chưa từng có.

Luôn luôn có một máy chủ DB được bao gồm bất cứ khi nào và bất cứ nơi nào trên bất kỳ nền tảng cho tôi chỉ là thiên đường !!!

Answer 6

Tôi biết mình đã trễ gửi câu trả lời ở đây, nhưng tôi muốn đảm bảo không ai phạm sai lầm khi sử dụng Derby trên bất kỳ cơ sở dữ liệu chất lượng sản xuất nào trong tương lai. Tôi xin lỗi trước vì làm thế nào tiêu cực câu trả lời này là - Tôi đang cố gắng để nắm bắt toàn bộ cảm xúc của một nhóm kỹ thuật bị bệnh trong một Q & một câu trả lời ngắn gọn.

Kinh nghiệm của chúng tôi khi sử dụng Derby trong nhiều triển khai của khách hàng nhỏ đã khiến chúng tôi nghi ngờ nghiêm túc việc sử dụng nó hữu ích như thế nào đối với bất kỳ môi trường thử nghiệm nào.Một số vấn đề chúng tôi đã có:

• Deadlocks do leo thang khóa - đây là lớn nhất một và xảy ra đối với một khách hàng về một lần mỗi tuần hoặc hai
• gián đoạn I/Os nguyên nhân Derby thất bại hoàn toàn trên Solaris (có thể không phải là vấn đề trên các nền tảng khác) - chúng tôi đã phải xây dựng một bảo mật để bảo vệ nó khỏi những lỗi này
• Không thể xử lý các truy vấn phức tạp mà MySQL/PostgreSQL xử lý dễ dàng
• Thực hiện đăng nhập giao dịch lỗi gây ra tham nhũng bảng yêu cầu chúng tôi xuất cơ sở dữ liệu và sau đó nhập lại (không thể chỉ thả bảng bị hỏng) và chúng tôi vẫn mất bảng trong quá trình này - cảm ơn lòng tốt chúng tôi đã có một bản sao lưu
• Không LIMIT cú pháp
• hiệu suất thấp cho các truy vấn phức tạp
• hiệu suất thấp cho các bộ dữ liệu lớn

Do thực tế là nó được nhúng, Derby là một đối thủ cạnh tranh với SQLite hơn là PostgreSQL, một cơ sở dữ liệu chất lượng sản xuất cực kỳ trưởng thành được sử dụng để lưu trữ các tập dữ liệu nhiều petabyte bởi một số trang web lớn nhất trên thế giới. Nếu bạn muốn sẵn sàng cho sự tăng trưởng và không muốn bị bắt gặp gỡ gỡ lỗi mã cơ sở dữ liệu của người khác, tôi khuyên bạn không nên sử dụng Derby. Tôi không có bất kỳ kinh nghiệm với SQLite, nhưng tôi không thể tưởng tượng nó là ít đáng tin cậy hơn Derby đã được cho chúng tôi và vẫn được phổ biến như nó được.

Thực tế, chúng tôi đang trong quá trình chuyển sang PostgreSQL ngay bây giờ.