SQLite trên một máy chủ sản xuất? [đóng cửa]

Tôi đã biết về SQLite từ lâu và tôi biết rằng nó rất nhanh, nhưng tôi chưa bao giờ thử nó trong một máy chủ sản xuất. Tôi không bao giờ có thể tìm thấy một ước tính chắc chắn về lưu lượng truy cập mà nó có thể xử lý trước khi thất bại.

Có ai có bất kỳ số hoặc một bài viết về điều này?

Thật không may, tôi không có bất kỳ số liệu nào cho bạn về khả năng tải, nhưng một vài nhận xét về một số yếu tố hạn chế hiệu suất:

• Tốc độ của SQLite bị ảnh hưởng bởi tốc độ của đĩa và nó có hay không có nhiều phần chèn / cập nhật đang diễn ra (tức là truy cập ghi). Khóa ghi bị giới hạn bởi tốc độ quay đĩa

• Giao dịch được bắt đầu theo mặc định, nhưng bạn sẽ có hiệu suất tốt hơn nếu bạn bắt đầu và cam kết giao dịch. Tôi đã chèn rất nhanh khi xử lý giao dịch theo chương trình

• Nếu bạn thường chỉ đọc dữ liệu thì bạn sẽ có hiệu suất tốt theo kinh nghiệm của tôi. Vì vậy, SQLite có thể được sử dụng như một hệ thống lưu trữ để lưu trữ các máy chủ cơ sở dữ liệu đọc, các từ xa cụ thể hoặc các truy vấn phức tạp.

• Nó sử dụng ít tài nguyên hơn máy chủ cơ sở dữ liệu, vì vậy điều này có thể ảnh hưởng đến hiệu suất trang web vì giải phóng nhiều tài nguyên hơn cho máy chủ Web và mã ứng dụng

• Nếu bạn yêu cầu một số lần ghi đồng thời là có thể, thì một máy chủ cơ sở dữ liệu (ví dụ: MySQL, Postgres) có thể phục vụ bạn tốt hơn

Như Devrim đã nêu, trang web SQLite tuyên bố khoảng 100 nghìn người dùng / ngày sẽ ổn. Một hệ thống Trac yêu cầu ghi, vì vậy hiệu suất có thể sẽ chậm hơn trong trường hợp đó

Tôi có một số điểm để thêm vào những câu trả lời tốt.

Phiên bản hiện tại của SQLite có WAL (Ghi nhật ký trước) để việc đọc và viết có thể tiến hành đồng thời. Vì vậy, giới hạn nhà văn duy nhất truyền thống được đề cập trong các câu trả lời trước không còn tồn tại. Tôi chưa thấy WAL trong sản xuất nên tôi không thể nhận xét mức độ quy mô của nó.

Sử dụng WAL hay không, nếu cơ sở dữ liệu SQLite của bạn chỉ đọc (hoặc được cập nhật hàng loạt) và nó phù hợp với RAM (HĐH của bạn có đủ RAM dự phòng để giữ bộ đệm), nó có thể mở rộng rất tốt trên ứng dụng web sản xuất. Cá nhân tôi đã rất hoài nghi về hiệu suất, khả năng mở rộng và mạnh mẽ của nó, nhưng bây giờ sau chín tháng sản xuất, nó đã được chứng minh là chạy rất tốt những phần phức tạp nhất của hệ thống .

Sqlite là tuyệt vời để nhúng vào các ứng dụng, và đó là những gì nó được thiết kế cho, nhưng nó chắc chắn không phải là "nhanh chóng". Tôi sử dụng nó cho một số ứng dụng của riêng tôi, hoàn toàn vì sự tiện lợi khi chỉ có hai tệp có thể được sao chép sang máy khác để cung cấp cho ứng dụng hoạt động hoàn toàn. Các thử nghiệm chống lại MySQL, sử dụng cùng cấu trúc, chỉ mục, v.v., cho thấy Sqlite chậm hơn đáng kể, ngay cả đối với các cơ sở dữ liệu nhỏ. Tôi hy vọng sự khác biệt hiệu suất sẽ tăng lên khi kích thước cơ sở dữ liệu tăng lên, mặc dù tôi không thể nói chắc chắn vì tôi chỉ sử dụng nó với cơ sở dữ liệu dưới 100 MB.

Tôi nghĩ rằng sqlite chỉ nhanh hơn một tệp văn bản / xml (bạn có thể ngạc nhiên nếu bạn đã thử nó). Và nó không hỗ trợ đồng thời, nếu bạn muốn tạo một trang web cho mạng nội bộ nơi mọi người đăng ký giờ làm việc hoặc sử dụng vé trac thì nó có thể phục vụ tốt. Ngoài ra, cần tránh và thay thế bằng mysql hoặc couchdb.

Trang web sqlite cho biết 100k người dùng / ngày sẽ ổn nhưng tôi rất nghi ngờ điều đó, vì một dự án trac đơn giản bị kẹt rất nhiều với việc sử dụng văn phòng 10 ppl.

Sqlite không phải là ứng dụng DB máy khách / máy chủ truyền thống. Đó thực chất là một thư viện được nhúng trong một ứng dụng khác. Nó được thiết kế cho các ứng dụng máy tính để bàn một người dùng. Bạn hoàn toàn không muốn thử sử dụng nó như một loại thay thế MySQL / PostgreSQL / MS-SQL độc lập trong môi trường nhiều người dùng vì toàn bộ DB bị khóa khi ghi. Bạn sẽ xử lý các vấn đề tranh chấp ngay cả khi tải nhẹ sẽ phá hủy hiệu suất.