Trung tâm cá nhân
cuốn sách gpt4 ai đã làm

35. Trường hợp mô hình HBase: khách hàng đặt hàng

In lại Tác giả: Đường đến ông chủ Thời gian cập nhật: 2024-01-07 13:06:52 36 4
mua khóa gpt4 Nike

Trường hợp HBase: Khách hàng/Đơn hàng

Giả sử HBase được dùng để lưu trữ thông tin khách hàng và đơn hàng. Có hai loại bản ghi cốt lõi được nhập: loại bản ghi khách hàng và loại bản ghi đơn hàng.

Loại bản ghi Khách hàng sẽ chứa mọi thứ bạn thường mong đợi:

  • Mã số khách hàng
  • Tên khách hàng
  • Địa chỉ (ví dụ: thành phố, tiểu bang, mã zip)
  • Số điện thoại, v.v.

Loại bản ghi đơn hàng sẽ chứa các thông tin sau:

  • Mã số khách hàng
  • số thứ tự
  • Ngày bán
  • Một loạt các đối tượng lồng nhau dành cho địa điểm vận chuyển và mặt hàng đặt hàng

Giả sử rằng sự kết hợp giữa mã số khách hàng và đơn đặt hàng xác định duy nhất một đơn hàng, đối với bảng đơn hàng (ORDER), hai thuộc tính này sẽ tạo thành một khóa hàng, cụ thể là khóa tổng hợp, ví dụ:

[mã khách hàng][mã đơn hàng]

Tuy nhiên, cần có nhiều quyết định thiết kế hơn: Giá trị thô có phải là lựa chọn tốt nhất cho khóa hàng không?

Các vấn đề thiết kế tương tự trong trường hợp sử dụng LogData mà chúng ta gặp phải ở đây. Không gian khóa cho số khách hàng là gì và định dạng (ví dụ: số hoặc chữ và số?) Vì việc sử dụng các khóa có độ dài cố định trong HBase là thuận lợi và để hỗ trợ phân phối khóa hợp lý trong không gian khóa, nên các tùy chọn như thế này sẽ xuất hiện:

Rowkey tổng hợp có hàm băm:

  • [MD5 của mã số khách hàng] = 16 byte
  • [MD5 của số thứ tự] = 16 byte

Kết hợp số tổng hợp/băm Rowkey:

  • [thay cho số khách hàng] = 8 byte
  • [MD5 của số thứ tự] = 16 byte

Bàn đơn/nhiều bàn

Phương pháp thiết kế truyền thống sẽ có các bảng KHÁCH HÀNG và BÁN HÀNG riêng biệt. Một tùy chọn khác là đóng gói nhiều loại bản ghi vào một bảng duy nhất (ví dụ: KHÁCH HÀNG++).

Loại bản ghi khách hàng Rowkey:

  • [id khách hàng]
  • [type] = đại diện cho loại bản ghi khách hàng loại '1'

Loại bản ghi thứ tự Rowkey:

  • [id khách hàng]
  • [type] = loại chỉ ra loại bản ghi đơn hàng là '2'
  • [đặt hàng]

Ưu điểm của cách tiếp cận KHÁCH HÀNG++ cụ thể này là nhiều loại bản ghi khác nhau có thể được sắp xếp theo ID khách hàng (ví dụ: một lần quét có thể lấy được tất cả thông tin về khách hàng đó). Nhược điểm là việc quét các loại bản ghi cụ thể không dễ dàng.

Thiết kế đối tượng đặt hàng HBase

Bây giờ chúng ta cần tìm ra cách mô hình hóa đối tượng Order. Giả sử cấu trúc lớp như sau:

Đặt hàng

Đơn hàng có thể có nhiều Địa điểm vận chuyển

Mục hàng

Một ShippingLocation có thể có nhiều LineItems

Có một số tùy chọn để lưu trữ dữ liệu này.

tiêu chuẩn hóa đầy đủ

Với cách tiếp cận này sẽ có các bảng riêng biệt cho ORDER, SHIPPING_LOCATION và LINE_ITEM.

Khóa hàng của bảng ĐẶT HÀNG được mô tả ở trên: lược đồ.casestudies.custorder

Khóa hàng tổng hợp cho SHIPPING_LOCATION trông như thế này:

  • [thứ tự-hàng]
  • [số địa điểm vận chuyển] (ví dụ: địa điểm đầu tiên, địa điểm thứ hai, v.v.)

Khóa hàng tổng hợp cho bảng LINE_ITEM sẽ trông như thế này:

  • [thứ tự-hàng]
  • [số địa điểm vận chuyển] (ví dụ: địa điểm đầu tiên, địa điểm thứ hai, v.v.)
  • [số mục hàng] (ví dụ: dòng đầu tiên, dòng thứ hai, v.v.)

Một mô hình tiêu chuẩn hóa như vậy có thể là cách tiếp cận RDBMS, nhưng nó không phải là lựa chọn duy nhất cho HBase. Nhược điểm của phương pháp này là để lấy thông tin cho bất kỳ đơn hàng nào, bạn cần phải:

  • Lấy mẫu đơn đặt hàng
  • Quét đơn hàng trên bảng SHIPPING_LOCATION để tìm phiên bản ShippingLocation
  • Quét LINE_ITEM cho mỗi Địa điểm vận chuyển

Dù sao thì đây cũng là điều mà RDBMS sẽ thực hiện, nhưng vì nó không có trong HBase nên bạn chỉ biết rõ hơn về nó.

Bảng đơn có các loại bản ghi

Với cách tiếp cận này, sẽ có một ĐẶT HÀNG chứa một bảng duy nhất

Đặt hàng khóa như trên: lược đồ.casestudies.custorder

  • [thứ tự-hàng]
  • [Loại bản ghi ĐẶT HÀNG]

Khóa hàng tổng hợp ShippingLocation sẽ trông như thế này:

  • [thứ tự-hàng]
  • [Loại bản ghi VẬN CHUYỂN]
  • [số địa điểm vận chuyển] (ví dụ: địa điểm đầu tiên, địa điểm thứ hai, v.v.)

Khóa hàng tổng hợp LineItem sẽ trông như thế này:

  • [thứ tự-hàng]
  • [Loại bản ghi LINE]
  • [số địa điểm vận chuyển] (ví dụ: địa điểm đầu tiên, địa điểm thứ hai, v.v.)
  • [số mục hàng] (ví dụ: dòng đầu tiên, dòng thứ hai, v.v.)

sự không chuẩn hóa

Một biến thể trên một bảng duy nhất có các loại bản ghi là không chuẩn hóa và làm phẳng một số hệ thống phân cấp đối tượng, chẳng hạn như thu gọn thuộc tính ShippingLocation vào mỗi phiên bản LineItem.

Khóa hàng tổng hợp LineItem sẽ trông như thế này:

  • [thứ tự-hàng]
  • [Loại bản ghi LINE]
  • [số mục hàng] (ví dụ: dòng đầu tiên, dòng thứ hai, v.v., phải lưu ý rằng nó là duy nhất trong toàn bộ đơn hàng)

Cột LineItem sẽ trông như thế này:

  • số mục (itemNumber)
  • Số lượng
  • Giá
  • shipToLine1 (không chuẩn hóa từ ShippingLocation)
  • shipToLine2 (không chuẩn hóa từ ShippingLocation)
  • shipToCity (không chuẩn hóa từ ShippingLocation)
  • shipToState (không chuẩn hóa từ ShippingLocation)
  • shipToZip (không chuẩn hóa từ ShippingLocation)

Ưu điểm của phương pháp này bao gồm hệ thống phân cấp đối tượng ít phức tạp hơn, nhưng một nhược điểm là việc cập nhật sẽ trở nên phức tạp hơn nếu thông tin này thay đổi.

đối tượng BLOB

Bằng cách này, toàn bộ biểu đồ đối tượng Order được xử lý bằng cách nào đó dưới dạng BLOB. Ví dụ: khóa hàng cho bảng ORDER được mô tả ở trên: lược đồ.casestudies.custorder và một cột có tên "order" sẽ chứa một đối tượng có thể giải tuần tự hóa chứa Đơn hàng container, ShippingLocations và LineItems.

Có nhiều tùy chọn ở đây: JSON, XML, Java Serialization, Avro, Hadoop Writable và nhiều tùy chọn khác. Tất cả đều là các biến thể của cùng một cách tiếp cận: mã hóa biểu đồ đối tượng thành một mảng byte. Cần thận trọng với cách tiếp cận này để đảm bảo khả năng tương thích ngược khi mô hình đối tượng thay đổi, để các cấu trúc cố định cũ vẫn có thể được đọc từ HBase.

Ưu điểm là khả năng quản lý các biểu đồ đối tượng phức tạp với I/O tối thiểu (ví dụ: trong trường hợp này có Đơn hàng cho mỗi HBase Get), nhưng nhược điểm bao gồm khả năng tương thích ngược đã nói ở trên với tuần tự hóa, ngôn ngữ tuần tự hóa Phụ thuộc (ví dụ Java quá trình tuần tự hóa chỉ hoạt động trên máy khách Java), thực tế là bạn phải giải tuần tự hóa toàn bộ đối tượng để lấy bất kỳ thông tin nào trong BLOB và khó khăn với các khung công tác như Hive khi làm việc với các đối tượng tùy chỉnh như thế này.

36 4 0
Bài viết khuyến nghị: 37. Nghiên cứu trường hợp mẫu HBase: liệt kê dữ liệu
Bài viết khuyến nghị: 36. Trường hợp HBase: Smackdown Thiết kế Kiến trúc “Cao, Rộng, Trung bình”
Bài viết khuyến nghị: 34. Trường hợp HBase: ghi dữ liệu trên Steroid
Bài viết khuyến nghị: 33. Trường hợp mô hình HBase: dữ liệu nhật ký và dữ liệu chuỗi thời gian
Đường tới ông chủ
Hồ sơ

Tôi là một lập trình viên xuất sắc, rất giỏi!

Nhận phiếu giảm giá taxi Didi miễn phí
Phiếu giảm giá taxi Didi
Các bài viết phổ biến trên toàn bộ trang web
Chứng chỉ ICP Bắc Kinh số 000000
Hợp tác quảng cáo: 1813099741@qq.com 6ren.com
Xem sitemap của VNExpress