Lưu trữ một lượng lớn dữ liệu: DB hoặc Hệ thống Tệp?

Question

Giả sử ứng dụng của tôi tạo, lưu trữ và truy xuất số lượng mục nhập rất lớn (hàng chục triệu). Mỗi mục có số lượng dữ liệu khác nhau thay đổi (ví dụ: một số mục chỉ có một vài byte chẳng hạn như ID/tiêu đề, trong khi một số mục có thể có megabyte dữ liệu bổ sung). Cấu trúc cơ bản của mỗi mục là giống nhau và có định dạng XML.

Mục nhập được tạo và chỉnh sửa (nhiều khả năng là phụ thêm, không viết lại) tùy ý.

Có lưu ý các mục nhập dưới dạng tệp riêng biệt trong hệ thống tệp trong khi vẫn giữ các chỉ mục cần thiết trong DB so với lưu mọi thứ trong DB không?

Answer 1

Nó thực sự phụ thuộc vào cách bạn sẽ sử dụng nó. Cơ sở dữ liệu có thể xử lý nhiều mục nhập hơn trong một bảng so với hầu hết mọi người nghĩ, đặc biệt là với việc lập chỉ mục thích hợp. Mặt khác, nếu bạn không định sử dụng chức năng mà cơ sở dữ liệu quan hệ cung cấp, có thể không có nhiều lý do để sử dụng nó.

Ok, đủ tổng quát. Do đó, một cơ sở dữ liệu cuối cùng vẫn còn "xuống các tập tin trên đĩa", tôi sẽ không lo lắng quá nhiều về "điều phải làm" là gì. Nếu mục đích chính của cơ sở dữ liệu chỉ là lấy các tệp này một cách hiệu quả, tôi nghĩ sẽ tốt hơn nếu giữ các mục nhập DB nhỏ và tra cứu đường dẫn tệp thay vì dữ liệu thực tế - đặc biệt là vì hệ thống tệp của bạn sẽ khá hiệu quả trong việc truy xuất dữ liệu cho một vị trí cụ thể. Trong trường hợp bạn quan tâm, đây thực sự là mẫu lưu trữ dữ liệu chung cho các công cụ tìm kiếm - chỉ mục sẽ lưu trữ dữ liệu được lập chỉ mục và con trỏ đến dữ liệu được lưu trữ trên đĩa, thay vì lưu trữ mọi thứ trong chỉ mục.

Answer 2

Tôi sẽ lưu trữ dữ liệu trên hệ thống tệp và một đường băm đường dẫn trong DB.

Answer 3

Cũng tùy thuộc vào chi phí của bạn, MS SQL Server có thứ được gọi là "Chỉ mục XML chính" có thể được tạo, ngay cả trên dữ liệu phi cấu trúc. Điều này cho phép bạn viết XQuery để tìm kiếm các cột và cơ sở dữ liệu sẽ hỗ trợ bạn.

Nếu có bất kỳ sự nhất quán nào trong dữ liệu, hoặc nó có thể được đặt vào một lược đồ thì bạn có thể thấy một lợi ích cho điều này.

Tôi có thể khuyên bạn nên nếu bạn có một lượng lớn dữ liệu nhị phân như hình ảnh, v.v., bạn loại bỏ chúng ra và đặt chúng ở nơi khác, chẳng hạn như hệ thống tệp. Hoặc nếu bạn sử dụng 2008 có một loại gọi là "Filestream" (cheers @Marc_s) cho phép bạn lập chỉ mục, lưu trữ và bảo mật tất cả các tệp bạn ghi lại và sử dụng các API NTFS để lấy chúng (tức là chuyển khối nhanh) nhưng vẫn có chúng giữ như cột trong cơ sở dữ liệu.

Có cơ sở dữ liệu ở đó có thể cung cấp cho bạn một lớp trừu tượng và mở rộng quy mô nếu ứng dụng của bạn đặt nhu cầu lớn về tìm kiếm thông qua dữ liệu XML, điều đó có nghĩa là bạn không phải làm như vậy.

Chỉ cần 2c của tôi.

Answer 4

Ở nơi làm việc, tôi thường phải tích lũy nhiều bộ tài liệu XML để phân tích sau này. Thông thường, điều này được thực hiện bằng cách gắn chúng vào một thư mục và phân tích được thực hiện bởi grep (hoặc một chương trình Java riêng biệt với tất cả các đồ dùng XML/builder/wrapper/API của nó).

Một ngày chậm tôi nghĩ mình sẽ thử đặt nó trong PostgreSQL.Có hai tính năng mà tôi muốn thử:

• Tự động nén dữ liệu lớn khi thích hợp (TOAST).
• Lập chỉ mục bằng cách sử dụng cụm từ.

Về tính năng đầu tiên, kích thước DB nhỏ hơn một nửa kích thước tệp thô. Thực hiện tìm kiếm văn bản đầy đủ, quét bảng bằng cách sử dụng WHERE data::TEXT LIKE '%pattern%', thực sự nhanh hơn chạy grep trên các tệp. Khi bạn đang đối phó với một vài GB của XML này một mình làm cho DB đáng giá.

Tính năng thứ hai, lập chỉ mục, sẽ hoạt động nhiều hơn một chút để duy trì. Có một vài yếu tố cụ thể mà tôi đoán sẽ là tốt để lập chỉ mục. Chỉ mục trên xpath('//tradeHeader/tradeId/text()', data) hoạt động, nhưng có thể là một nỗi đau khi sao chép trong mỗi truy vấn. Tôi thấy dễ dàng hơn khi thêm các cột thông thường cho một số trường và sử dụng trình kích hoạt chèn/cập nhật để giữ chúng đồng bộ.

Answer 5

Một vài lưu ý: quản lý

• giao dịch;
• sao lưu và khôi phục.

Đây là những cách tổng quát dễ dàng hơn để so sánh với cơ sở dữ liệu so với hệ thống tệp. Nhưng có lẽ điều khó khăn nhất là để đồng bộ hóa một bản sao lưu hệ thống tập tin với một cơ sở dữ liệu cuộn về phía trước (làm lại) đăng nhập. Ứng dụng của bạn càng giao dịch càng nhiều thì càng có nhiều yếu tố quan trọng.

Nó xuất hiện từ câu hỏi của bạn rằng bạn không có ý định sử dụng bất kỳ chức năng cơ sở dữ liệu bình thường nào (tính toàn vẹn quan hệ, tham gia). Trong trường hợp đó, bạn nên cân nhắc mạnh mẽ đến tùy chọn thứ ba: lưu trữ dữ liệu của bạn trong hệ thống tệp và thay vì cơ sở dữ liệu, sử dụng công cụ truy xuất văn bản dựa trên tệp như Solr (hoặc Lucene), Sphinx, Autonomy, v.v.

Answer 6

Nó phụ thuộc vào cách bạn sẽ sử dụng dữ liệu, như một phản ứng trước đó nói.

Dữ liệu trong cơ sở dữ liệu có thể được sử dụng để hỗ trợ nhiều loại truy vấn khác nhau và cung cấp kết quả cho báo cáo, biểu mẫu, công cụ OLAP và nhiều loại công cụ khác. Việc lập chỉ mục thích hợp có thể tăng tốc độ tìm kiếm một cách đáng kể.

Nếu bạn biết SQL và nếu cơ sở dữ liệu được thiết kế tốt, việc truy vấn dễ dàng hơn, nhanh hơn và ít xảy ra lỗi hơn là thực hiện tương đương với tệp. Nhưng, như những người khác đã lưu ý, bạn có thể cắm dữ liệu XML của bạn vào SQL mà không cần chuyển nó vào cơ sở dữ liệu.

Việc thiết kế giản đồ đa năng tốt là khó hơn hầu hết những người mới bắt đầu nghĩ. Có rất nhiều điều cần tìm hiểu, và nó không chỉ là về cách thao tác một công cụ này hay công cụ khác. Và một lược đồ đa năng xấu có thể còn khó khăn hơn để làm việc với hơn các tệp.

Nếu bạn quyết định sử dụng cơ sở dữ liệu, hãy chuẩn bị để đầu tư đáng kể. Và chắc chắn rằng bạn sẽ nhận được những lợi ích của khoản đầu tư đó.

Answer 7

Tôi sẽ sử dụng HDFS (hệ thống tệp phân tán Hadoop) để lưu trữ dữ liệu. Ý tưởng chính là bạn sẽ nhận được tính sẵn sàng cao, khả năng mở rộng và nhân rộng. Bất kỳ truy vấn nào đến ứng dụng của bạn đều có thể được thực hiện làm giảm truy vấn bản đồ. Và các trường chính có thể được lưu trữ dưới dạng một chỉ mục phân tán trên Hadoop sử dụng Katta.

Hãy thử googling cho các công nghệ này.