Thay thế cho EAV cho các trường động trong kho dữ liệu lược đồ sao

Tôi cần hỗ trợ các trường và giá trị động trong một kho dữ liệu lớn để lưu trữ nhật ký yêu cầu API, trường hợp người dùng của tôi là tôi cần lưu trữ tất cả chuỗi truy vấn yêu cầu API và có thể thực hiện truy vấn đối với chúng trong tương lai (vì vậy đây không chỉ là lưu trữ, vì vậy tôi không thể sử dụng blob cho họ)

ví dụ http://example.com/?action=test&foo=abc&bar=def...

Tôi cần lưu trữ tất cả các field => valueánh xạ, (action => test), (foo => abc), (bar => def)và vì trường này rất năng động, giải pháp duy nhất tôi tìm thấy là sử dụng Entity-Attribution-Value, tuy nhiên, mọi người cứ nói đó là một thiết kế rất tệ.

Vì vậy, hãy xem xét trường hợp sử dụng của tôi ở trên, điều gì sẽ là sự thay thế phù hợp cho EAV?

Lược đồ hiện tại của tôi sử dụng KAV

1. Bảng requests
(id, timestamp, uri)
   ví dụ(1, 149382220, '/')

2. Bảng params
(request_id, key, value)
   ví dụ(1, 'action', 'test'), (1, 'foo', 'abc'), (1, 'bar', 'def')

Bất kỳ đề xuất?

Cập nhật: Chúng tôi chạy kho trên AWS RedShift

Tôi có thể nghĩ về ba giải pháp - EAV, XML và Cột thưa thớt. Cái sau là dành riêng cho nhà cung cấp và có thể không hữu ích cho bạn.

Dù bạn chọn phương pháp nào, bạn có thể muốn xem xét việc lưu trữ dữ liệu yêu cầu ban đầu ở định dạng thô, trong một bảng hoặc tệp phẳng. Nó sẽ giúp bạn dễ dàng thử các cách lưu trữ dữ liệu mới, cho phép bạn tải lại dữ liệu nếu bạn phát hiện ra lỗi với cách bạn phân tích yêu cầu của mình và cung cấp cơ hội để phân tích các yêu cầu API bằng cách xử lý hàng loạt hoặc "dữ liệu lớn" công cụ nếu bạn thấy rằng kho dữ liệu của bạn không thể xử lý dữ liệu một cách hiệu quả.

Cân nhắc EAV

EAV / KVS, như bạn đã mô tả ở trên, có thể là triển khai đơn giản nhất.

Thật không may, nó cũng sẽ rất tốn kém - để có được bất kỳ loại truy vấn hiệu quả nào trên các khóa thường được sử dụng, bạn sẽ cần phải có các chỉ mục trên cột khóa, có thể bị phân mảnh rất nhiều. Truy vấn cho các khóa cụ thể sẽ cực kỳ tốn kém.

Bạn có thể giảm chi phí lập chỉ mục hoặc quét chỉ mục bằng cách hỗ trợ cửa hàng EAV của bạn với các chế độ xem được cụ thể hóa (nhiều nhà cung cấp hỗ trợ điều này) để truy vấn các khóa hoặc giá trị mà bạn quan tâm.

XML

Hầu hết các hệ thống cơ sở dữ liệu doanh nghiệp cung cấp xử lý XML rất thành thục, bao gồm xác thực, lập chỉ mục và truy vấn tinh vi.

Tải yêu cầu API vào cơ sở dữ liệu dưới dạng XML sẽ cung cấp một tuple cho mỗi yêu cầu, về mặt logic có thể hợp lý hơn với bạn một chút so với việc có một số lượng hàng không xác định trong bảng EAV.

Việc này có hiệu quả hay không sẽ phụ thuộc rất nhiều vào nhà cung cấp RDBMS và việc triển khai của bạn.

Nhược điểm lớn nhất là đây có lẽ là cách duy nhất để quản lý dữ liệu phức tạp hơn thao tác chuỗi của yêu cầu ban đầu!

Cột thưa / bảng truyền thống

Có thể là bạn có thể tải dữ liệu của mình vào cấu trúc bảng truyền thống, với một cột cho mỗi khóa.

Tính năng Cột thưa của SQL Server là một thay thế tuyệt vời cho cửa hàng EAV. Một bảng có Cột thưa hoạt động giống như một bảng bình thường, ngoại trừ việc nó có thể có tới 30.000 cột và các giá trị NULL trong các cột thưa thớt không tiêu tốn khoảng trống trong bảng.

Kết hợp chúng với Chỉ mục được lọc (một tính năng cụ thể khác của Máy chủ SQL) có thể cung cấp giải pháp thay thế cực kỳ hiệu quả cho cửa hàng EAV nếu bạn thường xuyên truy vấn một vài cột và / hoặc giá trị cụ thể.

Sử dụng bảng truyền thống với các nhà cung cấp khác có thể khả thi - IBM hỗ trợ hơn 700 cột trên mỗi bảng và Oracle khoảng 1000, và các tính năng như nén hoặc xử lý lỗi của Oracle có thể có nghĩa là bạn có thể lưu trữ dữ liệu API của mình khá hiệu quả.

Nhược điểm rõ ràng của phương pháp này là khi bạn thêm các khóa mới vào API, bạn cần điều chỉnh lược đồ của mình cho phù hợp.

EAV không phải là một thiết kế tồi, vì nó đơn giản là một thiết kế đòi hỏi một số lượng lớn các dự đoán và có thể gây ra các vấn đề về hiệu suất khi số lượng dữ liệu tăng lên. Nó có thể là cho hệ thống của bạn, nó sẽ hoạt động tốt.

Khi tôi thiết kế một hệ thống để lưu trữ các chuỗi truy vấn, tôi không biết trước mình sẽ quan tâm đến lĩnh vực nào. Tôi đã tạo một bảng để lưu trữ chuỗi truy vấn ở định dạng nhị phân nối tiếp và xây dựng một hệ thống cho phép tôi phân tách truy vấn chuỗi thành các phần thành phần của nó một khi tôi biết các phần tôi quan tâm. Từ đó tôi tạo ra một tập hợp các bảng; mỗi cái cho các bộ dữ liệu thường có trong chuỗi truy vấn.

Chẳng hạn, cuối cùng tôi đã có một bảng cho dữ liệu tham chiếu, một bảng cho dữ liệu yêu cầu đích và một bảng cho các mục liên quan đến người dùng, chẳng hạn như truy vấn tìm kiếm mà họ đã nhập.

Tôi tìm thấy khả năng lưu trữ toàn bộ chuỗi truy vấn trong một bảng dưới dạng blob, đồng thời cung cấp khả năng phân tách blob đó trong tương lai, đáp ứng nhu cầu của tôi rất tốt.