Các trang web sử dụng nội bộ: Có trường hợp hấp dẫn nào chống lại SQLite không?

Nhiều khung web, như Flask hoặc Django sử dụng SQLite làm cơ sở dữ liệu mặc định của chúng. SQLite hấp dẫn bởi vì nó được bao gồm trong python và chi phí quản trị khá thấp.

Tuy nhiên, hầu hết các trang web sản xuất công cộng có lưu lượng truy cập cao đều sử dụng cơ sở dữ liệu nặng hơn: mySQL, Oracle hoặc postgresql.

Các câu hỏi :

Giả định:

• Lưu lượng truy cập trang web ở mức vừa phải và việc truy cập đọc / ghi đồng thời vào cơ sở dữ liệu sẽ xảy ra
• Chúng tôi sẽ sử dụng SQLAlchemy với các khóa ghi SQLite (mặc dù nhận xét này khiến tôi hơi lo lắng)
• Cơ sở dữ liệu sẽ chứa khoảng 60.000 hồ sơ
• Cấu trúc dữ liệu không yêu cầu các tính năng nâng cao được tìm thấy trong cơ sở dữ liệu nặng hơn

Đã bao giờ có một trường hợp hấp dẫn chống lại sự tương tranh SQLite cho các trang web hoạt động như các công cụ nội bộ lưu lượng truy cập vừa phải chưa? Nếu vậy, điều kiện nào sẽ khiến SQLite gặp vấn đề tương tranh?

Tôi đang tìm kiếm các nguyên nhân gốc cụ thể đã biết, thay vì sợ hãi chung / chỉ tay không căn cứ.

Tôi khuyên bạn nên đọc câu trả lời chính thức cho câu hỏi của bạn, Sử dụng phù hợp cho SQLite . Cụ thể, "Tình huống trong đó một RDBMS khác có thể hoạt động tốt hơn" cảnh báo rằng SQLite không hỗ trợ viết đồng thời:

SQLite hỗ trợ số lượng người đọc đồng thời không giới hạn, nhưng nó sẽ chỉ cho phép một người viết bất cứ lúc nào. Đối với nhiều tình huống, đây không phải là một vấn đề. Mỗi ứng dụng làm cơ sở dữ liệu của nó hoạt động nhanh chóng và di chuyển, và không có khóa nào tồn tại trong hơn vài chục mili giây. Nhưng có một số ứng dụng đòi hỏi đồng thời nhiều hơn và những ứng dụng đó có thể cần tìm kiếm một giải pháp khác.

Từ góc độ phù hợp, tôi có xu hướng xem SQLite như một định dạng tệp rất tinh vi hỗ trợ các truy vấn SQL. Tôi có xu hướng tránh SQLite nếu tôi muốn tách cơ sở dữ liệu của mình khỏi ứng dụng web của mình, vì nó không được tối ưu hóa cho trường hợp này. Nói tóm lại, SQLite không đủ khả năng mở rộng để sử dụng trong một số tình huống, vì vậy những người đang chạy các trang web hy vọng một ngày nào đó trở nên phổ biến có thể tốt hơn là bắt đầu với một cái gì đó có thể mở rộng, thay vì đi bằng SQLite và sau đó bị buộc phải chuyển đổi.

Tất cả những gì đang được nói, SQLite có thể tốt cho hầu hết các trang web nội bộ; thông thường các trang web nội bộ không yêu cầu cùng mức độ đồng thời và khả năng mở rộng.

Đội mũ Giám đốc CNTT của tôi, tôi thấy một vài điều không hay ở đây:

• Nguy cơ tham nhũng dữ liệu. Có lẽ nhiều hơn so với thực tế nhưng cuối ngày, đây là một loại tệp DB không giao dịch, không có nhiều nếu có bất kỳ lời đề nghị nào viết xấu ngoài việc hỏi bạn đã có bản sao lưu gần đây chưa. Nói về mà . . .
• Làm thế nào để tôi sao lưu điều này lên? Theo cách tôi biết tôi đã có một bản sao tốt. Tốt nhất là không dùng ứng dụng ngoại tuyến.
• Làm thế nào tôi có thể bảo mật truy cập vào DB? Hiểu biết chung của tôi là SQL lite không có quyền truy cập hệ thống tập tin, đây là một khởi đầu tốt nhưng không phải là tất cả, cuối cùng. Đặc biệt đối với các ứng dụng web nơi bạn có thể muốn có nhiều quyền tốt nghiệp hơn DBA hoặc không có gì.

Từ quan điểm của nhà phát triển, tôi nghĩ điều quan trọng là phải biết tại sao SqlLite là mặc định - đó là vì nó dễ dàng và nó được trình diễn tốt. Nếu bạn đang "bán" một nền tảng cho các nhà phát triển mới, việc có thể kích hoạt một ứng dụng web hoạt động với sự ồn ào tối thiểu là chìa khóa. Và việc phải đứng lên và cấu hình đúng máy chủ cơ sở dữ liệu sẽ là một trở ngại lớn cần tránh.