Chuyển từ một mô hình RDBMS sang HBase - núm vú

Nếu bạn đang phải đối mặt với giai đoạn thiết kế ứng dụng của mình và bạn tin rằng HBase sẽ phù hợp, sau đó thiết kế các phím và lược đồ hàng của bạn để phù hợp với mô hình dữ liệu HBase và kiến ​​trúc là đúng cách. Tuy nhiên, đôi khi nó có ý nghĩa để di chuyển cơ sở dữ liệu ban đầu được thiết kế cho một RDBMS để HBase.

Một kịch bản phổ biến mà cách tiếp cận này có ý nghĩa là một cá thể cơ sở dữ liệu MySQL đã đạt đến giới hạn về khả năng mở rộng của nó. Các kỹ thuật tồn tại để theo chiều ngang một cá thể MySQL ( sharding, nói cách khác) nhưng quá trình này thường là rườm rà và có vấn đề vì MySQL đơn giản không phải là ban đầu được thiết kế để sharding.

Chuyển đổi từ mô hình quan hệ sang mô hình HBase là một kỷ luật tương đối mới. Tuy nhiên, các mô hình tư tưởng đã được thiết lập nhất định đang nổi lên và đã kết hợp thành ba nguyên tắc chính để theo dõi khi tiến tới quá trình chuyển đổi. Các nguyên tắc này là denormalization, duplication, và phím thông minh (DDI) .

• Denormalization: Mô hình cơ sở dữ liệu quan hệ phụ thuộc vào a) một giản đồ cơ sở dữ liệu được chuẩn hóa và b) tham gia giữa các bảng để đáp ứng các hoạt động của SQL. Chuẩn hóa cơ sở dữ liệu là một kỹ thuật bảo vệ dữ liệu bị mất, sự thừa và các dị thường khác khi dữ liệu được cập nhật và lấy ra.

  Đây là một dạng phổ biến khi chuyển sang HBase bởi vì các tham gia không được cung cấp qua các bảng, và các kết nối có thể chậm vì chúng liên quan đến các hoạt động tốn kém. Việc bảo vệ chống lại sự dị thường về cập nhật và truy hồi bây giờ là công việc của ứng dụng khách HBase của bạn, vì sự bảo vệ được cung cấp bởi sự bình thường hóa của bạn là vô hiệu.

  Sao chép:

• Khi bạn denormalize lược đồ cơ sở dữ liệu của mình, có thể bạn sẽ kết thúc việc sao chép dữ liệu vì nó có thể giúp bạn tránh được chi phí đọc các thao tác trên nhiều bảng. Không được quan tâm về việc lưu trữ thêm (trong lý do tất nhiên); bạn có thể sử dụng khả năng mở rộng tự động của HBase cho lợi thế của bạn. Cần lưu ý rằng ứng dụng khách của bạn sẽ cần thêm công việc để sao chép dữ liệu và nhớ rằng HBase nguyên bản chỉ cung cấp các hoạt động nguyên tử cấp hàng không vượt qua hàng (trừ trường hợp được mô tả trong HBASE-5229 JIRA) hoặc qua bàn.

  Các phím thông minh:

• Bởi vì dữ liệu được lưu giữ trong HBase được sắp xếp theo hàng và khoá hàng là chỉ mục gốc do hệ thống cung cấp, thiết kế thông minh cẩn thận của khóa hàng có thể tạo ra sự khác biệt rất lớn. Ví dụ: khóa hàng của bạn có thể là sự kết hợp của số thứ tự dịch vụ và số ID của khách hàng đã đặt lệnh dịch vụ. Thiết kế khóa hàng này sẽ cho phép bạn tìm kiếm dữ liệu liên quan đến đơn đặt hàng dịch vụ hoặc tìm kiếm dữ liệu liên quan đến khách hàng bằng cách sử dụng cùng một hàng trong cùng một bảng. Kỹ thuật này sẽ nhanh hơn đối với một số truy vấn và tránh phải tham gia vào các bảng tính tốn kém.

  Để làm rõ các kiểu tư tưởng cụ thể này, hãy lấy một bảng Thông tin Liên lạc Khách hàng và đặt nó vào trong một khung cảnh cơ sở dữ liệu lệnh dịch vụ điển hình. Hình này cho bạn thấy một giản đồ cơ sở dữ liệu đặt hàng dịch vụ bình thường có thể trông như thế nào.

Theo các quy tắc của việc chuẩn hóa RDBMS, hãy thiết lập bảng Customer Contact Information mẫu để tách biệt khỏi bảng đặt hàng dịch vụ để tránh mất dữ liệu của khách hàng khi các lệnh dịch vụ bị đóng và có thể bị xóa. Thực hiện cùng một cách tiếp cận cho bảng Sản phẩm, có nghĩa là các sản phẩm mới có thể được thêm vào cơ sở dữ liệu công ty hư cấu độc lập với đơn đặt hàng dịch vụ.

Bằng cách tham gia vào các hoạt động của RDBMS, lược đồ này hỗ trợ các truy vấn cho thấy số đơn đặt hàng dịch vụ được mở ra đối với một sản phẩm cụ thể cùng với vị trí của khách hàng nơi sản phẩm được sử dụng.

Đó là tất cả các tinh hoa và dandy, nhưng đó là một giản đồ bạn muốn sử dụng với RDBM. Làm thế nào để bạn chuyển đổi giản đồ này thành một giản đồ HBase? Hình tiếp theo minh hoạ một sơ đồ HBase có thể xảy ra - một mẫu theo mẫu thiết kế DDI.

Bảng thông tin khách hàng đã được denormalized bằng cách bao gồm tên khách hàng và thông tin liên lạc thay cho các phím nước ngoài được sử dụng trước đó. Đồng thời, dữ liệu được nhân đôi bằng cách giữ cho bảng Thông tin Liên lạc của Khách hàng như cũ. Bây giờ, việc tham gia qua bảng Đặt hàng Dịch vụ và Bảng Thông tin Liên hệ Khách hàng là không cần thiết.

Ngoài ra, một thiết kế phím hàng thông minh đã được sử dụng kết hợp số sản phẩm với số khách hàng để tạo thành số đơn đặt hàng dịch vụ (ví dụ: A100 | 00001). Sử dụng khoá thông minh này, bảng đặt hàng dịch vụ có thể cung cấp các báo cáo quan trọng về sự thiếu hụt sản phẩm và khách hàng hiện đang gặp vấn đề về sản phẩm.

Tất cả các truy vấn này đều có thể được HBase hỗ trợ theo một cấp độ nguyên tử cho ứng dụng. Bởi vì bạn biết rằng HBase sắp xếp các khóa hàng và sắp xếp chúng theo kiểu lexicography, ứng dụng của bạn có thể làm cho một số giáo dục đoán về địa phương dữ liệu khi phát hành quét để báo cáo. Ví dụ, tất cả các số sản phẩm A * sẽ được lưu trữ cùng nhau)

Cơ sở dữ liệu lệnh dịch vụ theo sơ đồ HBase là một ví dụ tương đối đơn giản, nhưng nó minh hoạ cách HBase có thể, trong một số trường hợp, có thể giao thoa với thế giới RDBMS và cung cấp giá trị đáng kể. Nếu công ty hư cấu có terabytes hoặc thậm chí petabytes dữ liệu cuộc gọi dịch vụ để lưu trữ, HBase sẽ tạo ra sự khác biệt rất lớn về chi phí, độ tin cậy, hiệu suất và quy mô.

Tất nhiên bạn có thể thiết kế trật tự HBase theo các cách khác nhau. Phải thừa nhận rằng, thiết kế tất cả phụ thuộc vào các truy vấn phải được hỗ trợ nhưng bạn có khả năng chuyển đổi một số cơ sở dữ liệu quan hệ sang các ứng dụng HBase rất mạnh để sử dụng sản xuất miễn là bạn làm việc từ sự hiểu biết chắc chắn về kiến ​​trúc HBase và mẫu thiết kế DDI.

Ví dụ này giả định rằng các truy vấn đã được thực hiện bởi một ứng dụng Java đòn bẩy cho các API của khách hàng HBase, hoặc có thể qua một ngôn ngữ khác bằng Apache Thrift. Mô hình ứng dụng này có thể phù hợp với các yêu cầu chỉ cần sử dụng tốt và cung cấp các tùy chọn hiệu suất hữu ích và tuỳ chỉnh cho công ty dịch vụ hư cấu.