Kích thước tối đa trong thế giới thực, thực tế cho cơ sở dữ liệu SQLite là gì?

Theo bài viết này về Sử dụng phù hợp cho SQLite, nó nói rằng, trong khi SQLite bị giới hạn ở mức 140 terabyte , RDBMS của máy khách / máy chủ có thể hoạt động tốt hơn:

Một cơ sở dữ liệu SQLite có kích thước giới hạn là 140 terabyte (2 ⁴⁷ byte, 128 tibibytes). Và ngay cả khi nó có thể xử lý các cơ sở dữ liệu lớn hơn, SQLite lưu trữ toàn bộ cơ sở dữ liệu trong một tệp đĩa duy nhất và nhiều hệ thống tệp giới hạn kích thước tối đa của tệp ở mức thấp hơn mức này. Vì vậy, nếu bạn đang dự tính các cơ sở dữ liệu có độ lớn này, bạn sẽ cân nhắc tốt việc sử dụng một công cụ cơ sở dữ liệu máy khách / máy chủ để truyền bá nội dung của nó trên nhiều tệp đĩa và có thể trên nhiều ổ đĩa.

Nói chung, tôi đồng ý với điều này, nhưng tôi đã rất ngạc nhiên khi biết rằng giới hạn tối đa của SQLite là rất cao! Theo kinh nghiệm của tôi, tôi đã sử dụng khá nhiều cơ sở dữ liệu SQL Server với kích thước ~ 30-100GB. Tôi cũng đã làm việc gián tiếp với các cơ sở dữ liệu lớn hơn nhiều bằng cách sử dụng Oracle, Postgres hoặc Cassandra. Trong số đó, ít nhất là theo hiểu biết của tôi, không ai đạt tới mức 140TB. Tôi không phải là một DBA, vì vậy đây là những gì tôi sẽ coi là "lớn" từ kinh nghiệm trực tiếp của mình.

Tôi chỉ xem xét SQLite cho các tình huống trong đó cơ sở dữ liệu sẽ rất nhỏ; hàng chục megabyte nhiều nhất

Sau khi đọc bài viết này, tôi vẫn không bị thuyết phục khi xem xét SQLite cho bất cứ điều gì có thể cần hàng trăm gigabyte. Nhưng tôi tự hỏi nếu tôi đã đánh giá thấp khả năng của nó. Giới hạn kích thước tối đa thực tế cho cơ sở dữ liệu SQLite trong sử dụng trong thế giới thực là gì?

Giới hạn thực tế (về kích thước của một số cơ sở dữ liệu Sqlite) giống như giới hạn thực tế cho một tệp dữ liệu. Và giới hạn đó phụ thuộc rất nhiều vào máy tính & hệ thống của bạn. Trên máy tính để bàn Linux hiện tại của tôi, tôi không thể đủ khả năng lớn hơn nhiều tệp 350Gbyte (vì theo nguyên tắc thông thường, tôi tránh để một tệp duy nhất ăn nhiều hơn một nửa phân vùng đĩa). BTW, giới hạn thực tế đó cũng tác động đến các RDBMS SQL khác như PostGreSQL hoặc MariaDB (nhưng hầu hết trong số này đang lưu giữ dữ liệu trong một số tệp mà bạn có thể giữ trên các hệ thống tệp khác nhau và một số trong số chúng có thể quản lý dữ liệu phân tán trên các máy từ xa .. .)

Sau khi đọc bài viết này, tôi vẫn không bị thuyết phục khi xem xét SQLite cho bất cứ điều gì có thể cần hàng trăm gigabyte

Bạn đúng và sai.

Bạn đã đúng, bởi vì trên máy tính ngày nay (máy tính xách tay & máy tính để bàn, không phải siêu máy tính hoặc máy chủ trung tâm dữ liệu), một trăm gigabyte vẫn là một không gian đĩa khá lớn. Vì vậy, trong thực tế, nếu bạn nghĩ về một cơ sở dữ liệu lớn như vậy, bạn sẽ tưởng tượng tốt hơn một máy chủ SQL thực sự (đặc biệt là PostGreQuery) vì bạn có thể muốn truy cập từ xa, truy cập đồng thời hiệu quả và có thể phân phối dữ liệu & bảng.

Bạn (về nguyên tắc, tôi chưa bao giờ thử) sai vì rất có thể SQLite có khả năng (và đôi khi được kiểm tra) để xử lý cơ sở dữ liệu vài trăm gigabyte, giả sử bạn có một hệ thống tệp có khả năng xử lý một tệp lớn như vậy (và có lẽ là hai ít nhất là họ).

Tôi chắc chắn sẽ (đôi khi) xem xét SQLite cho cơ sở dữ liệu của vài chục gigabyte (và tôi đã thử một lần với một .sqlitetệp lớn như vậy , IIRC là 40Gbyte). Trên các máy hiện tại (không phải siêu máy tính), tôi sẽ ngần ngại khi có hàng trăm gigabyte cơ sở dữ liệu SQLite, đơn giản vì một tệp như vậy khá lớn theo thực tế ngày nay.

IIRC một số nhà cung cấp phần cứng bán các máy hệ thống tập tin chuyên dụng đã nói với tôi một lần về ứng dụng sqlite terabyte (nhưng tôi có thể sai).

Tất nhiên hiệu năng SQLite phụ thuộc (như tất cả các cơ sở dữ liệu SQL) rất nhiều về số lượng và độ rộng của các bảng, chỉ mục của chúng, các truy vấn SQL có liên quan. Và bạn không muốn có quyền truy cập đồng thời (theo nhiều quy trình khác nhau) và bạn nên sử dụng giao dịch (theo kinh nghiệm, ngay cả trên cơ sở dữ liệu SQLITE nhỏ của vài megabyte, bạn thực sự muốn bọc ví dụ hàng ngàn yêu cầu chèn của mình với BEGIN TRANSACTION& END TRANSACTION, không làm điều đó đang làm chậm Sqlite bởi một yếu tố lớn - hơn 10 lần-).

Và theo kinh nghiệm cá nhân, với cấu hình và tổ chức phù hợp, SQLite có thể quản lý cơ sở dữ liệu lớn hơn RAM có sẵn (vì vậy 30Gbyte không phải là vấn đề) - nhưng bạn có thể muốn các chỉ mục phù hợp với RAM!

Nếu bạn tình cờ mã hóa thứ gì đó cho "siêu máy tính" hoặc máy trạm đắt tiền (ví dụ: 512Gbyte RAM và 8Tbyte đĩa và 512Gbyte SSD), bạn chắc chắn có thể có cơ sở dữ liệu Sqlite terabyte. Nhưng bạn sẽ muốn làm điều đó có lẽ chỉ khi một (hoặc rất ít) quá trình truy cập cơ sở dữ liệu đó. Nếu bạn có hàng tá quy trình truy cập đồng thời cùng một cơ sở dữ liệu, tốt hơn là cài đặt RDBMS SQL thực (à la MariaDB hoặc PostGreQuery)

Cũng lưu ý rằng mặc dù định dạng (nhị phân) của .sqlitecác tệp cơ sở dữ liệu được ghi là "di động", tôi thích sao lưu cơ sở dữ liệu ở định dạng văn bản SQL (sử dụng sqlite3 mydb.sqlite .dump > mydb.sql). Sau đó, tôi cũng cần một số không gian đĩa bổ sung cho kết xuất văn bản đó (và điều đó làm giảm giới hạn thực tế).

Thông thường Sqlite không phải là nút cổ chai. Nhưng đĩa có thể.

Tái bút Lý do tương tự có thể được áp dụng cho các tệp được lập chỉ mục lớn bằng GDBM .

^{PPS. Trong nhánh expjs của tôi ( sept.2016 ) của trình giám sát MELT của tôi (phần mềm miễn phí GPLv3, trên github) Tôi đang duy trì toàn bộ đống ứng dụng trong JSON trong cơ sở dữ liệu Sqlite mới. Tôi đã chạy các thí nghiệm nhỏ với hàng triệu đối tượng (khá "lớn") mà không có bất ngờ xấu. YMMV.}