Loading Light/Dark Toggle
MongoDB là gì? Mô hình tài liệu và lưu trữ dữ liệu web

MongoDB là gì?

Scrapeless Web Unlocker truy xuất nội dung web công khai mà các dịch vụ thu thập có thể kiểm tra và lưu trữ dưới dạng tài liệu MongoDB.

MongoDB là một cơ sở dữ liệu tài liệu lưu trữ bản ghi dưới dạng tập hợp các trường và giá trị. Một tài liệu có thể chứa các đối tượng lồng nhau và mảng, vì vậy cấu trúc của nó có thể giống với các đối tượng được dùng trong mã ứng dụng. Điều này khiến MongoDB trở thành một lựa chọn hữu ích khi các bản ghi được nhóm tự nhiên xung quanh một thực thể như sản phẩm, bài viết hoặc một quan sát nguồn.

Mô hình tài liệu cho phép có sự khác biệt, nhưng dữ liệu đáng tin cậy vẫn cần một hợp đồng. Một collection mà trong đó một bản ghi lưu giá dưới dạng văn bản và bản ghi khác lưu số lượng không kèm đơn vị tiền có thể dễ dàng được điền dữ liệu nhưng khó truy vấn chính xác. Các quyết định về schema được chuyển vào thiết kế ứng dụng và cơ sở dữ liệu thay vì biến mất.

Tài liệu và Collection Tổ Chức Dữ Liệu

Một collection MongoDB nhóm các tài liệu lại với nhau mà không yêu cầu mọi tài liệu phải chứa các trường giống hệt nhau. Kiến trúc tài liệu MongoDB hỗ trợ các giá trị lồng nhau, truy vấn và các thao tác giao dịch. Mô hình cho phép một ứng dụng đặt thông tin liên quan cùng nhau khi điều đó phù hợp với cách ứng dụng đọc và cập nhật dữ liệu.

MongoDB sử dụng BSON cho các tài liệu được lưu trữ. BSON hỗ trợ tập kiểu dữ liệu rộng hơn JSON thông thường, vì vậy một ngày hoặc định danh sẽ giữ được kiểu dự định của nó xuyên suốt ranh giới giữa driver và ứng dụng. Một hiển thị giống JSON tiện lợi không chứng minh rằng mọi giá trị đơn giản chỉ là một chuỗi hoặc số JSON.

Định dạng trao đổi JSON vẫn có ý nghĩa khi tài liệu đến thông qua API hoặc bản xuất. Chuyển một tài liệu sang JSON có thể cần các quyết định rõ ràng về các kiểu dữ liệu phong phú hơn trong cơ sở dữ liệu. Hãy đưa các quyết định đó vào hợp đồng xuất dữ liệu để một bên tiêu thụ khác có thể tái tạo lại ý nghĩa dự định.

Tên collection cũng nên mô tả đơn vị bản ghi của nó. Sản phẩm, trang nguồn và quan sát là các đơn vị khác nhau ngay cả khi mỗi đơn vị đều chứa tiêu đề sản phẩm. Kết hợp chúng mà không có trường phân biệt tạo ra sự mơ hồ về việc liệu một tài liệu mô tả một thực thể tồn tại lâu dài hay bằng chứng tại một thời điểm về thực thể đó.

Một Schema Linh Hoạt Cần Các Ý Nghĩa Ổn Định

Một schema linh hoạt hỗ trợ các bản ghi tiến hóa, trong khi ý nghĩa trường ổn định giữ cho các bản ghi đó hữu ích. Một quan sát từ nguồn có thể có thêm một trường tùy chọn mới mà không yêu cầu mọi tài liệu lịch sử phải chứa nó. Bên tiêu thụ vẫn cần biết liệu việc vắng mặt có nghĩa là không có sẵn, không được thu thập hay không áp dụng.

Xác định sớm các trường định danh và thời gian bắt buộc. Một quan sát sản phẩm công khai có thể cần một định danh nguồn, định danh sản phẩm, thời điểm quan sát và phiên bản trích xuất. Các thuộc tính tùy chọn sau đó có thể thay đổi mà không làm mất khả năng truy vết bản ghi đến sự kiện nguồn đã tạo ra nó.

Các khái niệm kiểm tra tính hợp lệ JSON theo cấu trúc mô tả các ràng buộc như thuộc tính bắt buộc và kiểu giá trị. MongoDB có các cơ chế và cú pháp kiểm tra tính hợp lệ riêng được hỗ trợ; đừng cho rằng một schema bên ngoài bất kỳ có thể được sao chép vào cơ sở dữ liệu mà không thay đổi. Nguyên tắc thiết kế hữu ích là kiểm tra tính hợp lệ ở nơi mà nếu không thì các bản ghi không nhất quán sẽ đi vào vùng lưu trữ đáng tin cậy.

Tách đầu vào thô khỏi các trường được chấp nhận. Lưu lại phản hồi từ nguồn có thể giúp giải thích quá trình trích xuất, nhưng payload thô không nên tự động trở thành bản ghi đáng tin cậy của ứng dụng. Một tài liệu được chấp nhận nên xác định trường nào vượt qua kiểm tra tính hợp lệ và giá trị tùy chọn nào vẫn chưa biết.

Nhúng và Tham Chiếu Đi Theo Mẫu Truy Cập

Nhúng lưu trữ thông tin liên quan bên trong một tài liệu, trong khi tham chiếu lưu trữ một quan hệ tới thông tin ở nơi khác. Hãy lựa chọn dựa trên dữ liệu nào được đọc cùng nhau, nó thay đổi thế nào và liệu tập con lồng nhau có thể tăng trưởng mà không có giới hạn hữu ích hay không.

Một bản ghi sản phẩm có thể nhúng một tập nhỏ các thuộc tính hiện tại mà trang sản phẩm luôn hiển thị cùng nhau. Các quan sát giá lịch sử có thể tăng lên liên tục và có chính sách lưu trữ riêng, vì vậy một collection quan sát riêng có thể làm cho vòng đời của chúng rõ ràng hơn. Đó là một quyết định mô hình hóa dựa trên ứng dụng này, không phải quy tắc phổ quát cho mọi cơ sở dữ liệu sản phẩm.

Sao chép dữ liệu cần một chính sách cập nhật. Nếu một nhãn danh mục được sao chép vào nhiều tài liệu, việc thay đổi danh mục có thể để lại các phiên bản khác nhau trong collection. Đôi khi đó là ngữ cảnh lịch sử mong muốn; đôi khi đó là sự không nhất quán vô tình. Hãy quyết định liệu giá trị được nhúng là một ảnh chụp tại thời điểm hay một quan hệ hiện tại.

Tránh chuyển đổi máy móc một thiết kế quan hệ sang tài liệu hoặc nhúng mọi quan hệ chỉ vì khả năng lồng nhau sẵn có. Hãy bắt đầu với các truy vấn và thao tác cập nhật thực tế. Một bản ghi dễ ghi nhưng yêu cầu lắp ráp phía ứng dụng lặp lại cho mọi lần đọc có thể không phù hợp với tải công việc tốt như hình dạng ban đầu của nó gợi ý.

Index Hỗ Trợ Truy Vấn Và Tăng Khối Lượng Ghi

Index giúp MongoDB định vị tài liệu mà không phải quét toàn bộ collection cho mọi truy vấn. Index nên khớp với các trường và thứ tự được sử dụng bởi các yêu cầu quan trọng của ứng dụng. Đánh index mọi trường sẵn có không thể thay thế cho việc hiểu các yêu cầu đó.

Hãy xem xét một bộ thu thập hiển thị các quan sát đã được chấp nhận gần đây cho một nguồn. Truy vấn của nó kết hợp định danh nguồn với thời điểm quan sát và một điều kiện hợp lệ. Thiết kế và kiểm tra kế hoạch truy vấn liên quan xoay quanh mẫu truy cập đó thay vì tạo các index không liên quan chỉ vì các trường đó xuất hiện trong tài liệu.

Index tiêu tốn dung lượng lưu trữ và phải được duy trì trong quá trình ghi. Do đó, một collection ghi lại mọi quan sát có thể có ngân sách index khác với một catalog chủ yếu chỉ đọc. Đo tải công việc với kích thước tài liệu thực tế, tần suất cập nhật và hình dạng truy vấn trước khi đưa ra các cam kết về hiệu năng.

Các quy tắc về tính duy nhất cũng thể hiện ý nghĩa nghiệp vụ. Nếu một quan sát được chấp nhận là duy nhất trong một nguồn và khoảng thời gian thu thập, hãy xác định danh tính đó một cách chủ đích. Chỉ riêng một mã định danh cơ sở dữ liệu mới sinh không ngăn được cùng một quan sát nghiệp vụ bị chèn nhiều hơn một lần dưới các mã định danh khác nhau.

Mô hình hóa một Quan Sát Sản Phẩm Công Khai

Một tài liệu quan sát sản phẩm nên phân biệt thực thể nguồn với hành vi quan sát nó. Danh tính sản phẩm kết nối các quan sát nối tiếp, trong khi danh tính quan sát phân biệt các lần thu thập riêng biệt. Điều này cho phép ứng dụng so sánh các thay đổi mà không giả vờ rằng mỗi lần tải về mô tả một sản phẩm mới.

Scrapeless Web Unlocker có thể truy xuất nội dung web công khai cho quy trình thu thập này. Ứng dụng sau đó kiểm tra rằng nội dung trả về thể hiện đúng sản phẩm và ngôn ngữ/vùng miền mong đợi trước khi trích xuất các giá trị được chấp nhận. Khả năng của Scrapeless Web Unlocker mô tả dịch vụ truy xuất; MongoDB vẫn là ranh giới lưu trữ được ứng dụng của bạn lựa chọn.

Giữ cho giá hiển thị và số tiền đã chuẩn hóa có thể phân biệt được. Một số tiền đã chuẩn hóa nên đi kèm loại tiền tệ dự định và các quy tắc diễn giải liên quan. Nếu trang cung cấp một khoảng giá hoặc giá thành viên, hãy ghi lại hạng mục đó một cách rõ ràng thay vì chọn một con số tiện lợi và gán nhãn nó là giá sản phẩm thông thường.

Một giá bị thiếu nên vẫn là một kết quả quan sát mà ứng dụng có thể giải thích. Nó có thể phản ánh một trường không sẵn có, một phản hồi bị từ chối, hoặc một trang nguồn không công bố giá. Những điều kiện đó có các hàm ý khác nhau đối với xu hướng lịch sử và không nên tất cả đều trở thành số không.

Cập Nhật, Giao Dịch và Các Trình Ghi Đồng Thời

MongoDB hỗ trợ các thao tác nguyên tử trên một tài liệu đơn lẻ và cung cấp giao dịch đa tài liệu cho các khối lượng công việc phù hợp. Ứng dụng vẫn cần chọn một ranh giới cập nhật phù hợp với yêu cầu nhất quán của nó. Việc một tính năng khả dụng không quyết định được mọi bộ thu thập phải sử dụng nó như thế nào.

Đối với một góc nhìn sản phẩm hiện tại, nhiều worker có thể quan sát cùng một sản phẩm tại các thời điểm khác nhau. Không có quy tắc sắp xếp, một quan sát cũ hơn nhưng hoàn thành muộn hơn có thể ghi đè một giá trị mới hơn. Hãy sử dụng ngữ cảnh quan sát và một chính sách cập nhật rõ ràng để thứ tự xử lý không âm thầm trở thành định nghĩa về độ mới.

Một bộ sưu tập quan sát lịch sử có thể tránh được một số mơ hồ về ghi đè bằng cách giữ riêng các quan sát được chấp nhận. Góc nhìn hiện tại sau đó có thể được suy ra từ lịch sử được chấp nhận theo một quy tắc đã được ghi lại. Điều này thêm trách nhiệm mô hình hóa nhưng giúp dễ giải thích hơn cách một giá trị hiển thị được chọn.

Phần thảo luận về kiến trúc bộ sưu tập phân tán cung cấp ngữ cảnh cho việc phân phối thu thập và lưu trữ qua các dịch vụ. Hãy giữ cho việc bàn giao có thể quy trách nhiệm: một worker chỉ nên báo cáo hoàn tất sau khi tài liệu được chấp nhận theo dự định của nó đã đến đích, chứ không chỉ sau khi tải xong trang hoặc hoàn thành biến đổi cục bộ.

Nhân Bản, Phân Mảnh và Lưu Trữ Có Những Nhiệm Vụ Khác Nhau

Nhân bản duy trì các bản sao trạng thái cơ sở dữ liệu để đảm bảo khả dụng, trong khi phân mảnh phân phối dữ liệu trên một triển khai. Cả hai đều không loại bỏ nhu cầu thiết kế danh tính tài liệu, cách truy vấn và lưu trữ. Việc thêm nhiều hạ tầng vào một mô hình dữ liệu không rõ ràng có thể khiến các điểm không nhất quán của nó khó điều tra hơn.

Một shard key ảnh hưởng đến cách dữ liệu được phân phối và truy cập. Hãy đánh giá nó dựa trên các mẫu truy vấn và ghi thực tế thay vì chọn một trường chỉ vì trông có vẻ duy nhất. Quyết định phân phối nên bao gồm việc bộ sưu tập tăng trưởng như thế nào và liệu các thao tác phổ biến có cần liên hệ nhiều phân vùng hay không.

Sao lưu và khôi phục tách biệt với nhân bản trực tiếp. Một cập nhật không mong muốn có thể lan tới các bản sao, nên khôi phục lịch sử cần quy trình riêng. Hãy xác định bao nhiêu lịch sử được chấp nhận phải được lưu giữ, có thể khôi phục nó như thế nào, và đội ngũ xác minh ra sao để việc khôi phục tạo ra các bản ghi ứng dụng có thể sử dụng được.

Nội dung thô và các quan sát được chấp nhận có thể có thời hạn lưu khác nhau. Chỉ giữ bằng chứng mà ứng dụng cần, bảo vệ nó một cách phù hợp, và loại bỏ tài liệu chẩn đoán đã hết hạn một cách chủ động. Đưa nhu cầu thu thập và Scrapeless pricing vào kế hoạch vận hành để việc tăng độ bao phủ nguồn có một chi phí được hiểu rõ trước khi công việc mới được lên lịch.

Kết luận

MongoDB tổ chức dữ liệu ứng dụng xoay quanh các tài liệu với trường linh hoạt và mẫu truy cập rõ ràng. Dữ liệu thu thập đáng tin cần danh tính ổn định, xác thực, và sự phân biệt rõ ràng giữa thực thể nguồn và các quan sát. Hãy bắt đầu với các truy vấn và cập nhật mà sản phẩm của bạn phải hỗ trợ, sau đó chọn nhúng, tham chiếu và chỉ mục xoay quanh chúng. Bảo tồn đủ ngữ cảnh nguồn để giải thích từng tài liệu được chấp nhận sau khi trang gốc thay đổi.

Sẵn sàng Xác Định Tài Liệu Thu Thập Của Bạn?

Mô hình hóa các quan sát được chấp nhận xoay quanh các danh tính nguồn ổn định và giữ phản hồi thô tách biệt với các bản ghi mà ứng dụng của bạn tin cậy.

Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Nhận $5 Tín Dụng Của Bạn →

FAQ

Hỏi: MongoDB có lưu các tệp JSON thông thường không?

MongoDB lưu tài liệu trong BSON, một dạng nhị phân với nhiều kiểu hơn JSON thông thường. Cách trình bày giống JSON hữu ích cho nhà phát triển, nhưng ứng dụng phải giữ nguyên các kiểu cơ sở dữ liệu dự định khi tuần tự hóa giá trị.

Hỏi: Lược đồ linh hoạt có nghĩa là không có lược đồ?

Một lược đồ linh hoạt cho phép có sự khác biệt giữa các tài liệu, trong khi ứng dụng vẫn cần một cách diễn giải trường nhất quán. Xác thực lược đồ MongoDB có thể thực thi các quy tắc đã chọn tại ranh giới lưu trữ.

Hỏi: Mọi đối tượng liên quan đều nên được nhúng vào?

Hãy nhúng thông tin liên quan khi nó được truy cập cùng nhau và vẫn nằm trong giới hạn. Tham chiếu tách biệt có thể phù hợp hơn với các thực thể thay đổi hoặc tăng trưởng độc lập, đặc biệt khi việc trùng lặp sẽ khiến cập nhật khó quản lý.

Hỏi: Sao chép (replication) có thay thế được sao lưu (backup) không?

Sao chép hỗ trợ tính sẵn sàng bằng cách duy trì các bản sao của trạng thái cơ sở dữ liệu. Sao lưu và quy trình khôi phục giải quyết một yêu cầu khác: khôi phục một trạng thái lịch sử đã biết sau khi có các thay đổi không mong muốn hoặc các mất mát dữ liệu khác.

Tài liệu tham khảo