Ví dụ thiết kế lược đồ mongodb
|
Một phần quan trọng của bất kỳ thiết kế kỹ thuật nào là chọn nơi lưu trữ dữ liệu của bạn. Nó có phù hợp với một lược đồ hay nó có cấu trúc linh hoạt không? Show Nội dung chính Hiển thị
Trong bài viết này, chúng tôi sẽ mô tả năm kho lưu trữ dữ liệu phổ biến và các thuộc tính của chúng. Chúng tôi hy vọng thông tin này sẽ cung cấp cho bạn cái nhìn tổng quan về các tùy chọn lưu trữ dữ liệu khác nhau để bạn có thể đưa ra lựa chọn tốt nhất có thể cho thiết kế kỹ thuật của mình Năm loại lưu trữ dữ liệu chúng ta sẽ thảo luận là
Cơ sở dữ liệu giống như kho lưu trữ dữ liệu gốc. Khi chúng tôi ngừng coi máy tính như máy tính được tôn vinh và bắt đầu sử dụng chúng để đáp ứng nhu cầu kinh doanh, chúng tôi bắt đầu cần lưu trữ dữ liệu. Và vì vậy chúng tôi (và theo chúng tôi, ý tôi là Charles Bachman) đã phát minh ra hệ thống quản lý cơ sở dữ liệu đầu tiên vào năm 1963. Vào giữa đến cuối những năm 70, các hệ thống quản lý cơ sở dữ liệu này đã trở thành hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) mà chúng ta biết và yêu thích ngày nay Cơ sở dữ liệu quan hệ, hay RDB, là cơ sở dữ liệu sử dụng mô hình dữ liệu quan hệ Dữ liệu được tổ chức thành các bảng. Mỗi bảng có một lược đồ xác định các cột cho bảng đó. Các hàng của bảng, mỗi hàng đại diện cho một bản ghi thông tin thực tế, phải tuân theo lược đồ bằng cách có một giá trị (hoặc giá trị NULL) cho mỗi cột Mỗi hàng trong bảng có một khóa riêng, còn được gọi là khóa chính. Thông thường, đây là một cột số nguyên được gọi là “ID. ” Một hàng trong bảng khác có thể tham chiếu ID của bảng này, do đó tạo ra mối quan hệ giữa hai bảng. Khi một cột trong một bảng tham chiếu đến khóa chính của một bảng khác, chúng tôi gọi đây là khóa ngoại Sử dụng khái niệm khóa chính và khóa ngoại này, chúng ta có thể biểu diễn các mối quan hệ dữ liệu cực kỳ phức tạp bằng cách sử dụng các nền tảng cực kỳ đơn giản SQL, viết tắt của ngôn ngữ truy vấn có cấu trúc, là ngôn ngữ tiêu chuẩn công nghiệp để tương tác với cơ sở dữ liệu quan hệ Tại Shopify, chúng tôi sử dụng MySQL làm RDBMS của mình. MySQL bền bỉ, linh hoạt và bền bỉ. Chúng tôi tin tưởng MySQL sẽ lưu trữ dữ liệu của chúng tôi và không bao giờ làm mất dữ liệu đó Các tính năng khác của RDBMS là
Khi nào nên sử dụng cơ sở dữ liệu quan hệSử dụng cơ sở dữ liệu để lưu trữ thông tin kinh doanh quan trọng của bạn. Cơ sở dữ liệu là loại lưu trữ dữ liệu lâu bền và đáng tin cậy nhất. Bất cứ thứ gì bạn cần lưu trữ vĩnh viễn nên được đưa vào cơ sở dữ liệu Cơ sở dữ liệu quan hệ thường là cơ sở dữ liệu trưởng thành nhất. chúng đã vượt qua thử thách của thời gian và tiếp tục là công cụ tiêu chuẩn của ngành để lưu trữ dữ liệu quan trọng một cách đáng tin cậy Có thể dữ liệu của bạn không phù hợp với lược đồ quan hệ hoặc lược đồ của bạn thay đổi thường xuyên đến mức cấu trúc cứng nhắc của cơ sở dữ liệu quan hệ đang làm chậm quá trình phát triển của bạn. Trong trường hợp này, bạn có thể cân nhắc sử dụng cơ sở dữ liệu không quan hệ để thay thế Cơ sở dữ liệu phi quan hệ (NoSQL)Các nhà khoa học máy tính trong nhiều năm đã làm rất tốt việc thiết kế cơ sở dữ liệu có sẵn và đáng tin cậy đến mức chúng tôi bắt đầu muốn sử dụng chúng cho cả dữ liệu không liên quan. Dữ liệu không tuân thủ nghiêm ngặt với một số lược đồ hoặc có một lược đồ thay đổi đến mức sẽ rất khó khăn khi cố gắng biểu diễn nó ở dạng quan hệ Những cơ sở dữ liệu phi quan hệ này thường được gọi là cơ sở dữ liệu “NoSQL”. Chúng có các đặc điểm gần giống như cơ sở dữ liệu SQL (bền, linh hoạt, liên tục, sao chép, phân phối và hiệu suất) ngoại trừ sự khác biệt chính là không thực thi các lược đồ (hoặc chỉ thực thi các lược đồ rất lỏng lẻo) Cơ sở dữ liệu NoQuery có thể được phân loại thành một số loại, nhưng có hai loại chính xuất hiện khi chúng ta nghĩ về cơ sở dữ liệu NoQuery. cửa hàng tài liệu và cửa hàng cột rộng (Trên thực tế, một số kho lưu trữ dữ liệu khác bên dưới cũng là kho lưu trữ dữ liệu NoSQL về mặt kỹ thuật. Chúng tôi đã chọn liệt kê chúng một cách riêng biệt vì chúng được thiết kế và tối ưu hóa cho các trường hợp sử dụng khác với các kho lưu trữ dữ liệu NoSQL “truyền thống” hơn này. ) Cửa hàng tài liệuKho lưu trữ tài liệu về cơ bản là một kho lưu trữ khóa-giá trị ưa thích trong đó khóa thường bị bỏ qua và không bao giờ được sử dụng (mặc dù một khóa được chỉ định dưới mui xe—chúng ta thường không quan tâm đến nó). Các giá trị là các đốm màu của dữ liệu bán cấu trúc, chẳng hạn như JSON hoặc XML và chúng tôi coi kho lưu trữ dữ liệu giống như nó chỉ là một mảng lớn của các đốm màu này. Ngôn ngữ truy vấn của kho lưu trữ tài liệu sau đó sẽ cho phép bạn lọc hoặc sắp xếp dựa trên nội dung bên trong các đốm màu tài liệu đó Kho lưu trữ tài liệu phổ biến mà bạn có thể đã nghe nói đến là MongoDB Cửa hàng cột rộngKho lưu trữ cột rộng nằm ở đâu đó giữa kho lưu trữ tài liệu và DB quan hệ. Nó vẫn sử dụng các bảng, hàng và cột giống như một DB quan hệ, nhưng tên và định dạng của các cột có thể khác nhau đối với các hàng khác nhau trong cùng một bảng. Chiến lược này kết hợp cấu trúc bảng nghiêm ngặt của cơ sở dữ liệu quan hệ với nội dung linh hoạt của kho lưu trữ tài liệu Các cửa hàng cột rộng phổ biến mà bạn có thể đã nghe nói đến là Cassandra và Bigtable Tại Shopify, chúng tôi sử dụng Bigtable làm công cụ chìm cho một số sự kiện phát trực tuyến. Các kho lưu trữ dữ liệu NoSQL khác không được sử dụng rộng rãi. Chúng tôi thấy rằng phần lớn dữ liệu của chúng tôi có thể được lập mô hình theo cách có quan hệ, vì vậy chúng tôi sử dụng cơ sở dữ liệu SQL như một quy tắc Khi nào nên sử dụng Cơ sở dữ liệu NoSQLCơ sở dữ liệu phi quan hệ phù hợp nhất để xử lý khối lượng lớn dữ liệu và/hoặc dữ liệu phi cấu trúc. Chúng cực kỳ phổ biến trong thế giới dữ liệu lớn vì tốc độ ghi rất nhanh. Cơ sở dữ liệu NoSQL không thực thi các lược đồ bảng chéo phức tạp, vì vậy việc ghi không có khả năng là nút cổ chai trong hệ thống sử dụng NoSQL Cơ sở dữ liệu phi quan hệ cung cấp rất nhiều tính linh hoạt cho các nhà phát triển, vì vậy chúng cũng phổ biến với các công ty khởi nghiệp ở giai đoạn đầu hoặc các dự án lĩnh vực mới khi các yêu cầu chính xác vẫn chưa rõ ràng Một cách khác để lưu trữ dữ liệu không liên quan là lưu trữ khóa-giá trị Kho lưu trữ khóa-giá trị về cơ bản là một bản đồ băm quy mô sản xuất. bản đồ từ khóa đến giá trị. Không có lược đồ ưa thích hoặc mối quan hệ giữa dữ liệu. Không có bảng hoặc nhóm dữ liệu logic nào khác cùng loại. Chỉ cần các khóa và giá trị, đó là nó Tại Shopify, chúng tôi sử dụng hai cửa hàng khóa-giá trị. Redis và Memcached Cả Redis và Memcached đều là kho lưu trữ khóa-giá trị trong bộ nhớ, vì vậy hiệu suất của chúng là hàng đầu Vì chúng nằm trong bộ nhớ nên chúng (nhất thiết) phải hỗ trợ các chính sách trục xuất có thể định cấu hình. Cuối cùng, chúng tôi sẽ hết bộ nhớ để lưu trữ khóa và giá trị, vì vậy chúng tôi sẽ cần xóa một số. Các chiến lược phổ biến nhất là Ít được sử dụng gần đây nhất (LRU) và Ít được sử dụng nhất (LFU). Các chính sách trục xuất này làm cho các kho lưu trữ khóa-giá trị trở thành một cách dễ dàng và tự nhiên để triển khai bộ đệm (Ghi chú. Ngoài ra còn có các cửa hàng khóa-giá trị dựa trên ổ đĩa, chẳng hạn như RocksDB, nhưng chúng tôi không có kinh nghiệm về chúng tại Shopify. ) Một điểm khác biệt chính giữa Redis và Memcached là Redis hỗ trợ một số cấu trúc dữ liệu dưới dạng giá trị. Bạn có thể khai báo rằng một giá trị trong Redis là một danh sách, tập hợp, hàng đợi, bản đồ băm hoặc thậm chí là HyperLogLog, sau đó thực hiện các thao tác trên các cấu trúc đó. Với Memcached, mọi thứ chỉ là một đốm màu và nếu bạn muốn thực hiện bất kỳ thao tác nào trên các đốm màu đó, bạn phải tự thực hiện rồi ghi lại vào key một lần nữa Redis cũng có thể được cấu hình để tồn tại trên đĩa, điều mà Memcached không thể. Do đó, Redis là lựa chọn tốt hơn để lưu trữ dữ liệu liên tục, trong khi Memcached vẫn chỉ phù hợp với bộ đệm Khi nào nên sử dụng Cửa hàng khóa-giá trịLưu trữ khóa-giá trị tốt cho các ứng dụng đơn giản cần lưu trữ tạm thời các đối tượng đơn giản. Một ví dụ rõ ràng là bộ đệm. Một ví dụ ít rõ ràng hơn là sử dụng danh sách Redis để xếp hàng các đơn vị công việc với các tham số đầu vào đơn giản Công cụ Tìm kiếm Toàn vănCông cụ tìm kiếm là một loại kho lưu trữ dữ liệu đặc biệt được thiết kế cho một trường hợp sử dụng rất cụ thể. tìm kiếm tài liệu dựa trên văn bản Về mặt kỹ thuật, các công cụ tìm kiếm là kho lưu trữ dữ liệu NoSQL. Bạn gửi các đốm màu tài liệu bán cấu trúc vào chúng, nhưng thay vì lưu trữ chúng nguyên trạng và sử dụng các trình phân tích cú pháp XML hoặc JSON để trích xuất thông tin, công cụ tìm kiếm sẽ cắt và sắp xếp nội dung tài liệu thành một định dạng mới được tối ưu hóa cho việc tìm kiếm dựa trên các chuỗi con của Công cụ tìm kiếm bền bỉ, nhưng chúng không được thiết kế đặc biệt bền. Bạn không bao giờ nên sử dụng công cụ tìm kiếm làm nơi lưu trữ dữ liệu chính của mình. Nó phải là bản sao thứ cấp của dữ liệu của bạn, luôn có thể được tạo lại từ nguồn ban đầu trong trường hợp khẩn cấp Tại Shopify, chúng tôi sử dụng Elaticsearch để tìm kiếm toàn văn. Elaticsearch được sao chép và phân phối ngay lập tức, giúp dễ dàng mở rộng quy mô Tuy nhiên, tính năng quan trọng nhất của bất kỳ công cụ tìm kiếm nào là nó hoạt động cực kỳ tốt đối với tìm kiếm văn bản. Để tìm hiểu thêm về cách các công cụ tìm kiếm toàn văn đạt được hiệu suất nhanh này, bạn có thể xem bài nói chuyện chớp nhoáng của Toria từ StarCon 2019 Khi nào nên sử dụng Công cụ Tìm kiếm Toàn vănNếu bạn thấy mình đang viết các truy vấn SQL có nhiều ký tự đại diện khớp (ví dụ: “CHỌN * TỪ sản phẩm WHERE mô tả THÍCH “%cat%” để tìm các sản phẩm liên quan đến mèo) và bạn đang nghĩ đến việc cải thiện thói quen tự nhiên của mình- Các công cụ tìm kiếm cũng khá giỏi trong việc tìm kiếm và lọc theo các kết quả khớp văn bản chính xác hoặc các giá trị số, nhưng cơ sở dữ liệu cũng làm tốt việc đó. Giá trị gia tăng thực sự của công cụ tìm kiếm toàn văn là khi bạn cần tìm kiếm các từ hoặc chuỗi con cụ thể trong các trường văn bản dài hơn Hàng đợi tin nhắnLoại lưu trữ dữ liệu cuối cùng mà bạn có thể muốn sử dụng là hàng đợi tin nhắn. Bạn có thể ngạc nhiên khi thấy hàng đợi tin nhắn trong danh sách này vì chúng được coi là công cụ truyền dữ liệu hơn là công cụ lưu trữ dữ liệu, nhưng hàng đợi tin nhắn lưu trữ dữ liệu của bạn với độ tin cậy cao và thậm chí bền bỉ hơn một số công cụ khác mà chúng tôi đã cung cấp Tại Shopify, chúng tôi sử dụng Kafka cho mọi nhu cầu phát trực tuyến của mình. Tải trọng được gọi là “thông báo” được “nhà sản xuất” chèn vào “chủ đề” Kafka. ” Mặt khác, “người tiêu dùng” Kafka có thể đọc các tin nhắn từ một chủ đề theo cùng thứ tự chúng được chèn vào Về cơ bản, Kafka được triển khai dưới dạng nhật ký phân tán, chỉ nối thêm. Nó chỉ là các tập tin. Mặc dù không phải là tệp con người có thể đọc được Kafka thường được coi là hàng đợi tin nhắn và thuộc đúng phần hàng đợi tin nhắn của chúng tôi, nhưng về mặt kỹ thuật, nó không phải là hàng đợi. Về mặt kỹ thuật, đây là nhật ký phân tán, nghĩa là chúng tôi có thể thực hiện những việc như đặt thời gian lưu giữ dữ liệu là “mãi mãi” và thu gọn thư của mình theo khóa (có nghĩa là chúng tôi chỉ giữ lại giá trị gần đây nhất cho mỗi khóa) và về cơ bản chúng tôi đã có một Mặc dù có một số trường hợp sử dụng hợp pháp cho thiết kế như vậy, nhưng nếu thứ bạn cần là kho lưu trữ tài liệu khóa-giá trị, thì hàng đợi tin nhắn có lẽ không phải là công cụ tốt nhất cho công việc. Bạn nên sử dụng hàng đợi tin nhắn khi cần gửi một số dữ liệu giữa các dịch vụ theo cách nhanh chóng, đáng tin cậy và phân tán Khi nào nên sử dụng Hàng đợi Tin nhắnSử dụng hàng đợi tin nhắn khi bạn cần tạm thời lưu trữ, xếp hàng hoặc gửi dữ liệu Nếu dữ liệu rất đơn giản và bạn chỉ lưu trữ dữ liệu đó để sử dụng sau này trong cùng một dịch vụ, thì bạn có thể cân nhắc sử dụng kho lưu trữ khóa-giá trị như Redis. Bạn có thể cân nhắc sử dụng Kafka cho cùng một dữ liệu đơn giản nếu đó là dữ liệu rất quan trọng, vì Kafka đáng tin cậy và bền bỉ hơn Redis. Bạn cũng có thể cân nhắc sử dụng Kafka cho một lượng lớn dữ liệu đơn giản, vì Kafka dễ dàng mở rộng quy mô hơn bằng cách thêm các phân vùng phân tán Kafka thường được sử dụng để gửi dữ liệu giữa các dịch vụ. Mô hình nhà sản xuất-người tiêu dùng có lợi thế lớn so với các giải pháp khác. bởi vì bản thân Kafka đóng vai trò là nhà môi giới tin nhắn, bạn chỉ cần gửi dữ liệu của mình vào Kafka và sau đó dịch vụ nhận có thể thăm dò các bản cập nhật. Nếu bạn cố gắng sử dụng thứ gì đó đơn giản hơn, chẳng hạn như Redis, bạn sẽ phải tự thực hiện một số loại cơ chế thông báo hoặc thăm dò ý kiến, trong khi Kafka có sẵn tính năng này. Tóm lại làĐây không phải là kho lưu trữ dữ liệu cuối cùng, nhưng chúng tôi nghĩ rằng chúng là những kho lưu trữ phổ biến và hữu ích nhất. Biết về năm loại kho dữ liệu này sẽ giúp bạn đưa ra quyết định thiết kế tuyệt vời Bạn nghĩ sao? Chúng tôi luôn tìm kiếm những người tuyệt vời thuộc mọi nền tảng và kinh nghiệm để tham gia nhóm của chúng tôi. Truy cập trang nghề nghiệp kỹ sư của chúng tôi để tìm hiểu những gì chúng tôi đang làm. Nhận những câu chuyện như thế này trong hộp thư đến của bạnCâu chuyện từ các nhóm xây dựng và mở rộng Shopify. Nền tảng thương mại cung cấp năng lượng cho hàng triệu doanh nghiệp trên toàn thế giới |
