Oracle gần đây đã phát hành a Berkeley DB back-end to SQLite. Tôi tình cờ có một cơ sở dữ liệu SQLite hàng trăm megabyte có thể được hưởng lợi từ "hiệu suất được cải thiện, đồng thời, khả năng mở rộng và độ tin cậy", nhưng trang web của Oracle dường như thiếu bất kỳ số đo nào. Có ai ở đây thực hiện một số điểm chuẩn?Berkeley DB SQL nhanh như thế nào so với SQLite?
Tôi đã tham gia đánh giá beta mã BDB SQLite và một trong những điều mà tôi đã cố gắng xử lý là hiệu suất hoạt động. Tại thời điểm này, Tôi không thể xuất bản chính xác những gì tôi đã tìm thấy cho đến khi tôi có ít nhất một người khác đánh giá mã của tôi, chạy thử nghiệm và xác nhận số tôi nhận được (đang được thực hiện ). Tuy nhiên, tôi có thể khái quát ở đây và nói rằng có những trường hợp BDB cung cấp các cải tiến hiệu suất đáng kể so với SQLite, cụ thể trong khu vực xử lý các tải nặng liên quan đến việc ghi đồng thời. Có, nói chung, hai biện pháp "nhanh" quyền - (1) hiệu quả: bao lâu phải mất một quá trình duy nhất để làm XYZ vs. (2) đồng thời: bao nhiêu lần có thể nhiều quá trình làm XYZ trên một đơn vị thời gian. Các địa chỉ BDB vấn đề chính là đồng thời - xử lý giao dịch quy mô lớn. Vì vậy, bạn nghĩ đến nhiều kết nối đồng thời ghi và/hoặc sửa đổi nội dung của cơ sở dữ liệu.
SQLite theo thiết kế sử dụng khóa cấp cơ sở dữ liệu để có tối đa một nhà văn có thể làm việc trong cơ sở dữ liệu tại một thời điểm. Do đó, tỷ lệ giao dịch của SQLite là vẫn không đổi với số lượng kết nối đồng thời, do đó, khả năng mở rộng trong các ứng dụng ghi chuyên sâu thực sự được đo bằng hiệu quả (1). Mặt khác, BDB sử dụng khóa cấp trang, cho phép nhiều người viết làm việc trong cơ sở dữ liệu tại một thời điểm nhất định (miễn là họ đang làm việc trên các trang riêng biệt). Do đó, tỷ lệ BDB có khả năng tăng với số lượng kết nối và do đó khả năng mở rộng của nó là cả vấn đề hiệu quả (1) và đồng thời (2), có thể tăng lên.
Chủ yếu là những gì nó được ghi lại là (viết) đồng thời. BDB có thể đẩy nhiều TPS hơn SQLite cho nhiều người viết. Bởi giao dịch, tôi có nghĩa là một cái gì đó mà sửa đổi cơ sở dữ liệu (làm thế nào là họ của bất kỳ trợ giúp thực sự cho các hoạt động chỉ đọc?). Điều đó nói rằng, để đọc đồng thời (các ứng dụng chủ yếu làm các lựa chọn), SQLite rất có thể đi đối đầu với BDB vì khóa không còn là vấn đề quan trọng nữa.
Đối với kích thước của tập dữ liệu, tôi không chắc chắn. Tôi đã không xem xét điều đó. Cuối cùng, cả hai đều sử dụng cây B để lưu trữ. Có thể có các yếu tố trong các triển khai tương ứng của chúng để xem xét, nhưng tôi đã không điều tra điều đó. Tôi biết rằng SQLite có thể xử lý một cách duyên dáng các tập hợp dữ liệu vào hàng trăm MB và GB hai chữ số (và có lẽ nhiều hơn bây giờ việc triển khai bản đồ trang bẩn đã được thay đổi). Do đó, nếu bạn có một ứng dụng sử dụng nhiều kết nối sửa đổi một cơ sở dữ liệu và tranh chấp được cho là tương đối thấp, thì BDB có thể cung cấp các cải tiến hiệu suất đáng kể . Nhưng tranh chấp trang là một biến quan trọng . Trong giới hạn, nếu bạn có một cơ sở dữ liệu BDB có dữ liệu bao gồm một trang đơn thì hiệu suất của nó sẽ khớp với SQLite trong mọi trường hợp vì khóa cấp trang ở đây có hiệu quả thoái hóa tương đương với mức khóa cơ sở dữ liệu đang chiến đấu trên một điều. Tuy nhiên, khi số lượng trang tăng trong BDB (và sự tranh chấp của trang giảm), thì TPS tối đa sẽ bắt đầu phát triển với số lượng kết nối đồng thời. Sau đó, từ thời điểm đó, bộ nhớ trở thành yếu tố hạn chế tiếp theo. Nhưng đó là một câu chuyện khác .
BTW, tôi đang trong quá trình viết một bài báo về việc sử dụng BDB cho những người sắp tới từ SQLite.
Điều liên kết:
Oracle Berkeley DB SQL API vs. SQLite API – A Technical Evaluation
Oracle Berkeley DB SQL API vs. SQLite API – Integration, Benefits and Differences
Đó là một câu hỏi được tải. Kết quả sẽ thay đổi đáng kể tùy thuộc vào tốc độ truy cập đĩa của bạn, kích thước bộ nhớ cache trong bộ nhớ, số lần chèn so với lần đọc, phân tách trang, đồng thời, v.v., v.v.
Nhìn chung, BerkeleyDB có thể cực kỳ nhanh - Gần đây tôi đã thiết kế một nền tảng phân tích dữ liệu cho một nhà tuyển dụng có khả năng thực hiện chèn 40k mỗi giây trên hệ thống x86 lõi 8 (trong khi đồng thời thực hiện hàng nghìn lần đọc mỗi giây) với tập dữ liệu trong phạm vi 30G. Điều này đã được bảo vệ giao dịch đầy đủ.
Đó là trường hợp tốt nhất, mặc dù - có những lúc chèn có thể giảm tới 2k mỗi giây, tùy thuộc vào dữ liệu đến và những gì hiện được lưu trữ ở Berkeley. Hiệu suất giảm đáng kể nếu bạn có I/O đĩa chậm và tốc độ truy cập bộ nhớ cache kém hoặc liên tục mở rộng DB khiến việc tách trang xảy ra. Ngoài ra còn có một số lượng lớn các điều chỉnh bạn có thể làm để tăng hiệu suất cho tập dữ liệu cụ thể của bạn.
Nhìn chung, đây là một hệ thống tuyệt vời, nhưng tài liệu và kiến thức khá mỏng. Tôi khuyên bạn nên The BerkeleyDB Book có lẽ là tài liệu tham khảo tốt nhất hiện có sẵn.
Ngoài Berkeley DB Sách rằng Brian đề cập, bạn cũng có thể tìm thấy những tài liệu sau đây hữu ích:
Bài viết đó sẽ xuất hiện như thế nào? –
Bật lại một lúc. Nó ra khỏi tay tôi bây giờ. Không chắc chắn khi nào, nơi nó sẽ được xuất bản. Có thể nghe điều gì đó vào tuần tới. –
Dưới đây là hai bài báo trắng từ bài viết: http://www.oracle.com/technetwork/database/berkeleydb/learnmore/bdbvssqlite-wp-186779.pdf http://www.oracle.com/technetwork/database/berkeleydb /learnmore/bdbvssqlite-wp-186779.pdf –