Gần đây tôi đã đọc Câu hỏi này về SQLite và MySQL và câu trả lời đã chỉ ra rằng SQLite không có quy mô tốt và loại trang web chính thức xác nhận điều này , tuy nhiên.
SQLite có khả năng mở rộng như thế nào và giới hạn trên của nó là gì?
Gần đây tôi đã đọc Câu hỏi này về SQLite và MySQL và câu trả lời đã chỉ ra rằng SQLite không có quy mô tốt và loại trang web chính thức xác nhận điều này , tuy nhiên.
SQLite có khả năng mở rộng như thế nào và giới hạn trên của nó là gì?
Câu trả lời:
Hôm qua tôi đã phát hành một trang web nhỏ *để theo dõi đại diện của bạn đã sử dụng cơ sở dữ liệu SQLite được chia sẻ cho tất cả khách truy cập. Thật không may, ngay cả với tải trọng khiêm tốn mà nó đặt lên máy chủ của tôi, nó vẫn chạy khá chậm. Điều này là do toàn bộ cơ sở dữ liệu đã bị khóa mỗi khi ai đó xem trang vì nó chứa các cập nhật / chèn. Tôi sớm chuyển sang MySQL và trong khi tôi không có nhiều thời gian để thử nghiệm nó, nó dường như có khả năng mở rộng hơn nhiều so với SQLite. Tôi chỉ nhớ tải trang chậm và thỉnh thoảng gặp lỗi khóa cơ sở dữ liệu khi cố gắng thực hiện các truy vấn từ shell trong sqlite. Điều đó nói rằng, tôi đang chạy một trang web khác từ SQLite. Sự khác biệt là trang web là tĩnh (tức là tôi là người duy nhất có thể thay đổi cơ sở dữ liệu) và do đó nó hoạt động tốt khi đọc đồng thời. Đạo đức của câu chuyện:
chỉnh sửa : Tôi chỉ nhận ra rằng tôi có thể không công bằng với SQLite - Tôi đã không lập chỉ mục bất kỳ cột nào trong cơ sở dữ liệu SQLite khi tôi đang phục vụ nó từ một trang web. Điều này một phần gây ra sự chậm lại mà tôi đang trải qua. Tuy nhiên, việc quan sát các giá trị khóa cơ sở dữ liệu - nếu bạn có các cập nhật đặc biệt khó chịu, hiệu suất SQLite sẽ không khớp với MySQL hoặc Postgres.
một chỉnh sửa khác: Kể từ khi tôi đăng bài này gần 3 tháng trước, tôi đã có cơ hội kiểm tra chặt chẽ khả năng mở rộng của SQLite và với một vài thủ thuật, nó có thể mở rộng được. Như tôi đã đề cập trong lần chỉnh sửa đầu tiên của mình, các chỉ mục cơ sở dữ liệu giảm đáng kể thời gian truy vấn, nhưng đây là một quan sát chung về cơ sở dữ liệu hơn là về SQLite. Tuy nhiên, có một mẹo khác bạn có thể sử dụng để tăng tốc SQLite: giao dịch . Bất cứ khi nào bạn phải viết nhiều cơ sở dữ liệu, hãy đặt chúng vào trong một giao dịch. Thay vì ghi vào (và khóa) tệp mỗi lần truy vấn ghi, việc ghi sẽ chỉ xảy ra một lần khi giao dịch hoàn tất.
Trang web mà tôi đề cập tôi đã phát hành trong đoạn đầu tiên đã được chuyển lại thành SQLite và nó hoạt động khá trơn tru khi tôi điều chỉnh mã của mình ở một vài nơi.
* trang web không còn khả dụng
Sqlite có khả năng mở rộng về mặt người dùng đơn lẻ, tôi có cơ sở dữ liệu nhiều gigabyte hoạt động rất tốt và tôi không gặp nhiều vấn đề với nó.
Nhưng nó là người dùng đơn lẻ, vì vậy nó phụ thuộc vào loại tỷ lệ bạn đang nói đến.
Đáp lại những bình luận. Lưu ý rằng không có gì ngăn cản sử dụng cơ sở dữ liệu Sqlite trong môi trường nhiều người dùng, nhưng mọi giao dịch (thực tế, mọi câu lệnh SQL sửa đổi cơ sở dữ liệu) đều khóa trên tệp , điều này sẽ ngăn người dùng khác truy cập vào cơ sở dữ liệu tại tất cả .
Vì vậy, nếu bạn có rất nhiều sửa đổi được thực hiện cho cơ sở dữ liệu, về cơ bản bạn sẽ gặp vấn đề mở rộng rất nhanh. Mặt khác, nếu bạn có nhiều quyền truy cập đọc so với quyền truy cập ghi, thì nó có thể không quá tệ.
Nhưng Sqlite tất nhiên sẽ hoạt động trong môi trường nhiều người dùng, nhưng nó sẽ không hoạt động tốt.
SQLite điều khiển trang web sqlite.org và các trang web khác có nhiều lưu lượng truy cập. Họ đề nghị rằng nếu bạn có ít hơn 100 nghìn lượt truy cập mỗi ngày, SQLite sẽ hoạt động tốt. Và điều đó đã được viết trước khi họ cung cấp tính năng "Ghi nhật ký Writeahead".
Nếu bạn muốn tăng tốc mọi thứ với SQLite, hãy làm như sau:
Bạn có thể muốn xem video của tôi trên YouTube có tên " Cải thiện hiệu suất SQLite với ghi nhật ký Writeahead " cho biết cách sử dụng ghi nhật ký viết trước và thể hiện sự cải thiện tốc độ 5x để ghi.
Sqlite là một máy tính để bàn hoặc cơ sở dữ liệu trong quá trình . SQL Server, MySQL, Oracle và anh em của họ là máy chủ .
Cơ sở dữ liệu máy tính để bàn về bản chất không phải là một lựa chọn tốt cho bất kỳ ứng dụng nào cần hỗ trợ truy cập ghi đồng thời vào kho lưu trữ dữ liệu. Điều này bao gồm ở một số cấp độ hầu hết các trang web từng được tạo ra. Nếu bạn thậm chí phải đăng nhập bất cứ thứ gì, có lẽ bạn cần quyền truy cập ghi vào DB.
Bạn đã đọc tài liệu SQLite này - http://www.sqlite.org/weaverouse.html chưa?
SQLite thường sẽ hoạt động tốt như công cụ cơ sở dữ liệu cho các trang web lưu lượng truy cập thấp đến trung bình (có nghĩa là, 99,9% của tất cả các trang web). Tất nhiên, lượng lưu lượng truy cập web mà SQLite có thể xử lý phụ thuộc vào mức độ trang web sử dụng cơ sở dữ liệu của nó. Nói chung, bất kỳ trang web nào nhận được ít hơn 100 nghìn lượt truy cập / ngày sẽ hoạt động tốt với SQLite. Con số 100 nghìn lượt truy cập / ngày là một ước tính bảo thủ, không phải là giới hạn trên cứng. SQLite đã được chứng minh là hoạt động với lượng lưu lượng gấp 10 lần.
Khả năng mở rộng SQLite sẽ phụ thuộc nhiều vào dữ liệu được sử dụng và định dạng của chúng. Tôi đã có một số kinh nghiệm khó khăn với các bảng dài thêm (bản ghi GPS, một bản ghi mỗi giây). Kinh nghiệm cho thấy SQLite sẽ chậm lại theo từng giai đoạn, một phần do việc tái cân bằng liên tục các cây nhị phân đang phát triển đang giữ các chỉ mục (và với các chỉ mục được đóng dấu thời gian, bạn chỉ biết rằng cây sẽ được cân bằng lại rất nhiều, nhưng nó rất quan trọng đối với bạn tìm kiếm). Vì vậy, cuối cùng ở mức khoảng 1GB (rất là sân bóng, tôi biết), các truy vấn trở nên chậm chạp trong trường hợp của tôi. Số dặm của bạn sẽ thay đổi.
Một điều cần nhớ, mặc dù tất cả sự khoe khoang, SQLite KHÔNG được tạo ra để lưu trữ dữ liệu. Có nhiều cách sử dụng khác nhau không được khuyến nghị cho SQLite. Những người tốt đằng sau SQLite tự nói điều đó:
Một cách khác để xem SQLite là thế này: SQLite không được thiết kế để thay thế Oracle. Nó được thiết kế để thay thế fopen ().
Và điều này dẫn đến đối số chính (không phải định lượng, xin lỗi, nhưng định tính), SQLite không dành cho tất cả các mục đích sử dụng, trong khi MySQL có thể bao gồm nhiều cách sử dụng khác nhau, ngay cả khi không lý tưởng. Ví dụ: bạn có thể có MySQL lưu trữ cookie Firefox (thay vì SQLite), nhưng bạn cần dịch vụ đó chạy mọi lúc. Mặt khác, bạn có thể có một trang web giao dịch chạy trên SQLite (như nhiều người làm) thay vì MySQL, nhưng mong đợi rất nhiều thời gian chết.
ATTACH DATABASEđể tạo kết nối cơ sở dữ liệu ảo với tất cả các bảng (tuy nhiên giới hạn ở 62 cơ sở dữ liệu).
Tôi nghĩ rằng một máy chủ web (trong số 1) phục vụ hàng loạt khách hàng xuất hiện trên phần phụ trợ với một kết nối duy nhất đến cơ sở dữ liệu, phải không?
Vì vậy, không có quyền truy cập đồng thời trong cơ sở dữ liệu do đó chúng ta có thể nói rằng cơ sở dữ liệu đang hoạt động ở 'chế độ người dùng đơn lẻ'. Thật vô nghĩa khi truy cập nhiều người dùng trong trường hợp như vậy và SQLite hoạt động tốt như bất kỳ cơ sở dữ liệu dựa trên máy chủ nào khác.
Nghĩ theo cách này. SQL Lite sẽ bị khóa mỗi khi ai đó sử dụng nó (SQLite không khóa khi đọc). Vì vậy, nếu bạn phục vụ một trang web hoặc một ứng dụng có nhiều người dùng đồng thời thì chỉ có một người có thể sử dụng ứng dụng của bạn tại một thời điểm với SQLLite. Vì vậy, có một vấn đề mở rộng. Nếu ứng dụng một người nói là Thư viện nhạc nơi bạn giữ hàng trăm danh hiệu, xếp hạng, thông tin, sử dụng, chơi, thời gian chơi thì SQL Lite sẽ có quy mô đẹp mắt, giữ hàng ngàn bản ghi (không có ổ cứng)
Mặt khác, MySQL hoạt động tốt cho các ứng dụng máy chủ nơi mọi người sẽ sử dụng đồng thời. Nó không khóa và nó có kích thước khá lớn. Vì vậy, đối với thư viện nhạc của bạn, MySql sẽ bị giết vì chỉ có một người nhìn thấy nó, KHÔNG GIỚI HẠN đây là thư viện nhạc được chia sẻ nơi hàng ngàn người thêm hoặc cập nhật nó. Sau đó, MYSQL sẽ là người sử dụng.
Vì vậy, về mặt lý thuyết, quy mô của MySQL tốt hơn Sqllite vì nó có thể xử lý người dùng đa dạng, nhưng lại quá mức cần thiết cho một ứng dụng người dùng.
Trang web của SQLite (phần mà bạn đã tham chiếu) chỉ ra rằng nó có thể được sử dụng cho nhiều tình huống đa người dùng.
Tôi sẽ nói rằng nó có thể xử lý khá một chút. Theo kinh nghiệm của tôi, nó luôn luôn rất nhanh. Tất nhiên, bạn cần lập chỉ mục các bảng của mình và khi mã hóa theo bảng, bạn cần đảm bảo rằng bạn sử dụng các truy vấn tối ưu hóa và tương tự. Về cơ bản cùng một thứ bạn sẽ làm với bất kỳ cơ sở dữ liệu nào để cải thiện hiệu suất.
Có thể đáng để kiểm tra REAL SQL Server , một máy chủ cơ sở dữ liệu được xây dựng trên SQLite.