DBMS nào tốt cho việc đọc siêu nhanh và cấu trúc dữ liệu đơn giản?

Tôi đang phát triển một sản phẩm, như một phần của hoạt động, phải theo dõi một số lượng lớn tệp / thư mục. Ý tưởng là lưu trữ thông tin stat trong cơ sở dữ liệu sau đó, khi khởi động, tạo đồng hồ cho mỗi tệp. Các tệp thay đổi sẽ được xếp hàng (trong cơ sở dữ liệu) để đồng bộ hóa nhóm với cơ sở dữ liệu từ xa. Chúng sẽ được đồng bộ hóa theo thứ tự ưu tiên, một số trong khoảng 1-10.

Thông tin về cơ sở dữ liệu:

• <100.000 mục thông tin thống kê
• Toàn bộ cơ sở dữ liệu đọc khi khởi động, chỉ cần đường dẫn tệp là cần thiết
• Các tệp xếp hàng sẽ có trường ưu tiên (không có gì khác cần tìm kiếm)
• Chèn có thể chậm

Tôi đã tìm thấy một vài cơ sở dữ liệu mà tôi nghĩ sẽ hoạt động, nhưng tôi không chắc cái nào là tốt nhất:

• Redis - lưu trữ đường dẫn tệp dưới dạng khóa, dữ liệu thống kê dưới dạng giá trị; hàng đợi sẽ là một danh sách
• MongoDB - nhiều tùy chọn truy vấn hơn Redis, nhưng vẫn nhanh

Tôi nghĩ rằng một cơ sở dữ liệu NoQuery sẽ là giải pháp tốt nhất ở đây, vì không có quá nhiều logic quan hệ đang diễn ra và tổng kích thước dữ liệu không quá lớn (đại loại như <100 mb, gần hơn <30 mb). Tôi đã xem xét SQLite vì nó dường như đủ đơn giản để nhúng vào một ứng dụng có thể cài đặt.

Vì đây là một ứng dụng phân tán cho người dùng cuối chứ không phải máy chủ tải cao, nên cơ sở dữ liệu không phải hỗ trợ nhiều người dùng đồng thời. Ưu tiên chính ở đây là tìm một cơ sở dữ liệu có mô hình có ý nghĩa nhất.

Vì vậy, câu hỏi, cơ sở dữ liệu nào sẽ được áp dụng nhất cho tình huống này?

Ngoài ra, có bất kỳ cơ sở dữ liệu nào khác có ý nghĩa hơn cho một ứng dụng như thế này không?

Điều đầu tiên tôi nghĩ đến là một RDBMS cụ thể quen thuộc với tôi. Tôi nhận ra, tuy nhiên, nó có thể không phải là tốt nhất cho ứng dụng này.

Vì vậy, lời khuyên của tôi là đi với một cơ sở dữ liệu quen thuộc với bạn. Nếu bạn quen thuộc với Redis hoặc MongoDB, thì hãy đi với một trong số đó. Nếu bạn quen thuộc hơn với SQLite, thì hãy chọn nó.

Trên cơ sở dữ liệu có kích thước này, tất cả sẽ diễn ra khá nhanh. Ngay cả các cơ sở dữ liệu nặng đĩa hơn cũng sẽ sử dụng một số loại bộ đệm để tốc độ đĩa không quá đáng lo ngại.

Nếu bạn không quan tâm đến logic quan hệ, muốn tốc độ đọc thực sự nhanh và bạn sẵn sàng làm việc với RDBMS, tôi sẽ mạo hiểm nói về MySQL. Tại sao ???

Công cụ lưu trữ MyISAM có một tùy chọn có thể cho phép cấu trúc vật lý của bảng được tăng cường để có hiệu suất tốt hơn. Lựa chọn đó là gì? Tùy chọn ALTER TABLE ROW_FORMAT.

Ví dụ: cuốn sách Thiết kế và điều chỉnh cơ sở dữ liệu MySQL khuyên bạn nên sử dụng ROW_FORMAT = FIXED trên các trang 72,73. Điều này sẽ chuyển đổi nội bộ tất cả các trường VARCHAR thành CHAR. Nó sẽ làm cho bảng MyISAM lớn hơn, nhưng thực hiện các lệnh CHỌN đối với nó sẽ nhanh hơn nhiều. Cá nhân tôi có thể chứng thực điều này. Tôi đã từng có một bảng là 1,9 GB. Tôi đã thay đổi định dạng với ALTER TABLE tblname ROW_FORMAT = FIXED. Bảng kết thúc 3,7 GB. Tốc độ của các CHỌN so với nó nhanh hơn 20-25% mà không cải thiện hoặc thay đổi bất cứ điều gì khác.

Điều gì xảy ra nếu bạn đã có bảng MyISAM được điền dữ liệu? Bạn có thể lấy số liệu cho các định nghĩa cột được đề xuất dựa trên dữ liệu có trong bảng MyISAM. Truy vấn nào trình bày những số liệu đó?

SELECT * FROM tblname PROCEDURE ANALYSE();

THỦ TỤC ANALYZE () Điều này sẽ không hiển thị dữ liệu. Nó sẽ đọc giá trị của mỗi cột và đề xuất các định nghĩa cột. Ví dụ: nếu bạn có một cột loại có giá trị là 1-4, thì nó sẽ cố gắng sử dụng ENUM của 4 giá trị đó. Sau đó, bạn có thể chọn sử dụng TINYINT hoặc CHAR (1) vì chúng có cùng dung lượng (1 byte).

Đây là một điều khác để xem xét: Vì bạn đã suy nghĩ về việc sử dụng NoQuery DB, bạn đã bao giờ nghĩ đến việc sử dụng MyISAM theo cách NoQuery chưa? Điều này là hoàn toàn có thể. Trang 175 của cùng một cuốn sách tôi đã đề cập đề xuất sử dụng các cấu trúc HANDLER để đọc bảng mà không có hành lý quan hệ . Trong thực tế, trang 175 đưa ra ví dụ này:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Bảng này chứa hàng triệu hàng. Giả sử rằng bạn cần tạo một ứng dụng phân tích dữ liệu có các yêu cầu sau:

• Nó cần phải lấy các khối thông tin càng nhanh càng tốt.
• Dựa trên đầu vào của người dùng hoặc các yếu tố khác, nó có thể sẽ "nhảy lung tung" trong bảng.
• Nó không liên quan đến vấn đề đồng thời hoặc các vấn đề toàn vẹn dữ liệu khác.
• Khóa bảng ứng dụng chéo là không cần thiết.

Các lệnh này cho phép đọc nhanh và bẩn từ bảng:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Tôi hy vọng điều này cung cấp cho thực phẩm cho suy nghĩ. Hãy nhìn vào nó.

CẨN THẬN

Điều rất mỉa mai về việc tôi viết bài đăng đặc biệt này là tôi đã viết một bài đăng trước đó về việc Handler được sử dụng trong các tệp nhị phân của Percona Server và nghĩ rằng việc sử dụng nó đã lỗi thời . Kể từ bài đăng cũ hơn đó, tôi chưa bao giờ nghĩ rằng mình sẽ viết một cái gì đó hỗ trợ cho các cấu trúc của Handler. Bây giờ tôi đứng sửa.