Các đặc tính hiệu suất của sqlite với các tệp cơ sở dữ liệu rất lớn là gì? [đóng cửa]

Tôi biết rằng sqlite không hoạt động tốt với các tệp cơ sở dữ liệu cực lớn ngay cả khi chúng được hỗ trợ (đã từng có một nhận xét trên trang web sqlite nói rằng nếu bạn cần kích thước tệp trên 1GB, bạn có thể muốn xem xét sử dụng rdbms doanh nghiệp. Không tìm thấy nó nữa, có thể liên quan đến một phiên bản cũ hơn của sqlite).

Tuy nhiên, với mục đích của tôi, tôi muốn có được một ý tưởng về việc nó thực sự tồi tệ như thế nào trước khi tôi xem xét các giải pháp khác.

Tôi đang nói về các tệp dữ liệu sqlite trong phạm vi nhiều gigabyte, từ 2GB trở đi. Ai có kinh nghiệm với cái này rồi nào? Bất kỳ lời khuyên / ý tưởng?

Vì vậy, tôi đã thực hiện một số thử nghiệm với sqlite cho các tệp rất lớn và đưa ra một số kết luận (ít nhất là cho ứng dụng cụ thể của tôi).

Các thử nghiệm liên quan đến một tệp sqlite duy nhất với một bảng hoặc nhiều bảng. Mỗi bảng có khoảng 8 cột, hầu hết tất cả các số nguyên và 4 chỉ số.

Ý tưởng là chèn đủ dữ liệu cho đến khi các tệp sqlite có dung lượng khoảng 50 GB.

Bảng đơn

Tôi đã cố gắng chèn nhiều hàng vào một tệp sqlite chỉ bằng một bảng. Khi tệp có dung lượng khoảng 7 GB (xin lỗi, tôi không thể nói cụ thể về số lượng hàng), quá trình chèn đã mất quá nhiều thời gian. Tôi đã ước tính rằng thử nghiệm của tôi để chèn tất cả dữ liệu của tôi sẽ mất 24 giờ hoặc lâu hơn, nhưng nó đã không hoàn thành ngay cả sau 48 giờ.

Điều này dẫn đến tôi kết luận rằng một bảng sqlite duy nhất, rất lớn sẽ có vấn đề với các phần chèn thêm, và có lẽ các hoạt động khác cũng vậy.

Tôi đoán điều này không có gì đáng ngạc nhiên, vì bảng trở nên lớn hơn, việc chèn và cập nhật tất cả các chỉ số mất nhiều thời gian hơn.

Nhiều bàn

Sau đó tôi đã thử chia dữ liệu theo thời gian qua nhiều bảng, một bảng mỗi ngày. Dữ liệu cho 1 bảng gốc được chia thành ~ 700 bảng.

Thiết lập này không có vấn đề gì với việc chèn, nó không mất nhiều thời gian hơn vì thời gian đã được tạo ra cho mỗi bảng.

Vấn đề chân không

Như i_like_caffeine đã chỉ ra, lệnh VACUUM là một vấn đề khi tệp sqlite càng lớn. Khi nhiều thao tác chèn / xóa được thực hiện, sự phân mảnh của tệp trên đĩa sẽ trở nên tồi tệ hơn, vì vậy mục tiêu là định kỳ VACUUM để tối ưu hóa tệp và khôi phục không gian tệp.

Tuy nhiên, như được chỉ ra bởi tài liệu , một bản sao đầy đủ của cơ sở dữ liệu được tạo ra để làm chân không, mất một thời gian rất dài để hoàn thành. Vì vậy, cơ sở dữ liệu càng nhỏ, thao tác này sẽ kết thúc càng nhanh.

Kết luận

Đối với ứng dụng cụ thể của tôi, có lẽ tôi sẽ phân tách dữ liệu qua một số tệp db, mỗi tệp một ngày, để đạt hiệu suất tốt nhất cả về hiệu suất chân không và tốc độ chèn / xóa.

Điều này làm phức tạp các truy vấn, nhưng đối với tôi, đó là một sự đánh đổi đáng giá để có thể lập chỉ mục nhiều dữ liệu này. Một lợi thế nữa là tôi có thể xóa toàn bộ tệp db để giảm giá trị dữ liệu trong một ngày (một thao tác chung cho ứng dụng của tôi).

Có lẽ tôi cũng phải theo dõi kích thước bảng trên mỗi tệp để xem khi nào tốc độ sẽ trở thành vấn đề.

Thật tệ khi dường như không có một phương pháp chân không gia tăng nào ngoài việc hút bụi tự động . Tôi không thể sử dụng nó vì mục tiêu của tôi đối với chân không là chống phân mảnh tệp (không gian tệp không phải là vấn đề lớn), điều mà máy hút bụi tự động không làm được. Trong thực tế, tài liệu nói rằng nó có thể làm cho sự phân mảnh trở nên tồi tệ hơn, vì vậy tôi phải dùng đến việc định kỳ thực hiện toàn bộ chân không trên tệp.

Chúng tôi đang sử dụng DBS 50 GB + trên nền tảng của chúng tôi. không phàn nàn công việc tuyệt vời. Hãy chắc chắn rằng bạn đang làm mọi thứ đúng! Bạn đang sử dụng báo cáo được xác định trước? * SQLITE 3.7.3

1. Giao dịch
2. Báo cáo trước

3. Áp dụng các cài đặt này (ngay sau khi bạn tạo DB)

   PRAGMA main.page_size = 4096;
   PRAGMA main.cache_size=10000;
   PRAGMA main.locking_mode=EXCLUSIVE;
   PRAGMA main.synchronous=NORMAL;
   PRAGMA main.journal_mode=WAL;
   PRAGMA main.cache_size=5000;

Hy vọng điều này sẽ giúp những người khác, làm việc tuyệt vời ở đây

Tôi đã tạo cơ sở dữ liệu SQLite có kích thước lên tới 3,5 GB mà không gặp vấn đề gì về hiệu suất. Nếu tôi nhớ chính xác, tôi nghĩ rằng SQLite2 có thể có một số giới hạn thấp hơn, nhưng tôi không nghĩ SQLite3 có bất kỳ vấn đề nào như vậy.

Theo trang Giới hạn SQLite , kích thước tối đa của mỗi trang cơ sở dữ liệu là 32K. Và các trang tối đa trong cơ sở dữ liệu là 1024 ^ 3. Vì vậy, theo toán học của tôi, con số này lên tới 32 terabyte là kích thước tối đa. Tôi nghĩ bạn sẽ đạt giới hạn hệ thống tệp của mình trước khi nhấn SQLite!

Phần lớn lý do khiến bạn mất> 48 giờ để thực hiện thao tác chèn là do chỉ mục của bạn. Nó cực kỳ nhanh hơn để:

1 - Thả tất cả các chỉ mục 2 - Thực hiện tất cả các chèn 3 - Tạo lại các chỉ mục

Bên cạnh các khuyến nghị thông thường:

1. Chỉ số thả cho chèn số lượng lớn.
2. Batch chèn / cập nhật trong các giao dịch lớn.
3. Điều chỉnh bộ đệm bộ đệm của bạn / vô hiệu hóa tạp chí / w PRAGMAs.
4. Sử dụng máy 64 bit (để có thể sử dụng nhiều bộ đệm ™).
5. [đã thêm vào tháng 7 năm 2014] Sử dụng biểu thức bảng chung (CTE) thay vì chạy nhiều truy vấn SQL! Yêu cầu phát hành SQLite 3.8.3.

Tôi đã học được những điều sau từ kinh nghiệm của mình với SQLite3:

1. Để có tốc độ chèn tối đa, không sử dụng lược đồ với bất kỳ ràng buộc cột nào. (Thay đổi bảng sau khi cần thiết Bạn không thể thêm các ràng buộc với ALTER TABLE).
2. Tối ưu hóa lược đồ của bạn để lưu trữ những gì bạn cần. Đôi khi, điều này có nghĩa là phá vỡ các bảng và / hoặc thậm chí nén / chuyển đổi dữ liệu của bạn trước khi chèn vào cơ sở dữ liệu. Một ví dụ tuyệt vời là lưu trữ địa chỉ IP dưới dạng số nguyên (dài).
3. Một bảng cho mỗi tệp db - để giảm thiểu sự tranh chấp khóa. (Sử dụng ATTACH DATABASE nếu bạn muốn có một đối tượng kết nối.
4. SQLite có thể lưu trữ các loại dữ liệu khác nhau trong cùng một cột (gõ động), sử dụng điều đó cho lợi thế của bạn.

Câu hỏi / bình luận chào mừng. ;-)

Tôi nghĩ rằng những phàn nàn chính về quy mô sqlite là:

1. Quá trình viết đơn.
2. Không phản chiếu.
3. Không nhân rộng.

Tôi có cơ sở dữ liệu SQLite 7GB. Để thực hiện một truy vấn cụ thể với một phép nối bên trong phải mất 2,6 giây Để tăng tốc độ này, tôi đã thử thêm các chỉ mục. Tùy thuộc vào chỉ số nào tôi đã thêm, đôi khi truy vấn giảm xuống còn 0,1 giây và đôi khi nó tăng lên đến 7 giây. Tôi nghĩ vấn đề trong trường hợp của tôi là nếu một cột có độ trùng lặp cao thì việc thêm chỉ mục làm giảm hiệu suất :(

Đã từng có một tuyên bố trong tài liệu SQLite rằng giới hạn kích thước thực tế của tệp cơ sở dữ liệu là vài chục GB: s. Điều đó chủ yếu là do SQLite cần "phân bổ một bitmap trang bẩn" bất cứ khi nào bạn bắt đầu giao dịch. Do đó, 256 byte RAM được yêu cầu cho mỗi MB trong cơ sở dữ liệu. Chèn vào tệp DB 50 GB sẽ cần một lượng lớn (2 ^ 8) * (2 ^ 10) = 2 ^ 18 = 256 MB RAM.

Nhưng như các phiên bản gần đây của SQLite, điều này không còn cần thiết nữa. Đọc thêm ở đây .

Tôi đã gặp vấn đề với các tệp sqlite lớn khi sử dụng lệnh chân không.

Tôi chưa thử tính năng auto_vacuum. Nếu bạn dự kiến ​​sẽ cập nhật và xóa dữ liệu thường xuyên thì điều này đáng để xem xét.