Cấu trúc dữ liệu cho phép tra cứu dựa trên thẻ hiệu quả


11

Tôi đang tìm kiếm một cấu trúc dữ liệu hiệu quả cao để lưu trữ dữ liệu tương tự như sau.

Thẻ Id Order1 Order2 
--------------------------
1 1,2 1 1
2 2,5 2 3
3 1,7 4 7
4 6 3 0

Tôi cần phải có khả năng truy vấn cấu trúc này theo một cách như vậy mà nó sẽ cung cấp cho tôi một danh sách của tất cả các id chứa một biểu hiện của thẻ - hỗ trợ ANDORNOThoạt động. Ví dụ. ((1 hoặc 2) chứ không phải 7)

Tôi cũng cần có khả năng chỉ định thứ tự kết quả (Order1 hoặc Order2) và có thể chỉ định các hàng tối đa được trả về với phần bù tùy chọn. Hiệu suất cho việc tìm nạp 30-100 kết quả đầu tiên là chìa khóa.

Cuối cùng, tôi cần một cách rẻ tiền để tra cứu "quan hệ thẻ", ví dụ tôi muốn biết thẻ nào "liên quan" đến thẻ (1 HOẶC 2) và ở tần số nào. Có nghĩa là các thẻ xuất hiện trong cùng một bộ là 1 HOẶC 2 ... được sắp xếp theo tần suất.

Bất kỳ ý tưởng về cấu trúc dữ liệu (hoặc bộ cấu trúc) nào sẽ có hiệu quả cao cho loại công việc này?

(Tôi muốn sử dụng điều này như một bằng chứng về khái niệm để thiết kế lại các trang được gắn thẻ của gia đình SE của các trang web)


1
Chỉ là một nhận xét (có lẽ tầm thường). Tại sao bạn không dựa vào hệ thống quản lý cơ sở dữ liệu quan hệ? Bạn có thể xác định một bảng với các cặp <id, tag> và thêm một chỉ mục trên cột thẻ. Sau đó, bạn có thể sử dụng các truy vấn SQL tiêu chuẩn để trích xuất dữ liệu. RDBMS sẽ thực hiện hiệu quả công việc "bẩn" của tối ưu hóa truy vấn và sắp xếp đầu ra.
Marzio De Biasi

@Vor, các biểu thức cực kỳ kém hiệu quả ở quy mô cao, bản thân tham gia trở thành truy vấn ác mộng.
Sam Saffron

@Sam: ok. Nhiệm vụ của bạn khá phổ biến vì vậy tôi nghĩ rằng một RDBMS tốt (có công cụ khai thác dữ liệu) có thể thực hiện công việc. Tôi rời sàn để một chuyên gia cấu trúc dữ liệu. :-)
Marzio De Biasi

Tôi tin rằng việc cho phép tất cả các kết hợp AND, OR, KHÔNG sẽ gây khó khăn cho việc tạo cấu trúc dữ liệu không liệt kê qua tất cả các mục (có lẽ nó có thể bị giới hạn ở 3-CNF?). Nếu không có giới hạn như vậy tồn tại, thì có lẽ chỉ cần chạy qua các bản ghi (theo thứ tự được chỉ định) cho đến khi bạn tìm thấy 30-100 vượt qua các yêu cầu thẻ của bạn. Mặc dù, nói chung, tôi đồng ý với đề xuất của Vor về việc sử dụng cơ sở dữ liệu để thực hiện công việc nặng nhọc cho bạn.
bbejot

Không phải là một chuyên gia, nhưng tôi nghĩ rằng nếu bạn không đặt ra một số hạn chế về cách bạn có thể hỏi về các thẻ thì điều đó sẽ trở nên khó khăn. Giới hạn chúng ở CNF (như bbejot đã đề xuất) là một cách, một cách khác là hạn chế số lượng thẻ khác nhau mà truy vấn có thể hỏi về một số lượng nhỏ (giả sử 6).
Kaveh

Câu trả lời:


6

Đây không phải là một câu trả lời chính xác về cấu trúc dữ liệu hiệu quả, mà là một sự giải thích về các ý kiến ​​của @bbejot và @Kaveh đưa ra một lập luận vẫy tay về lý do tại sao đưa ra câu hỏi hiện tại chúng ta không nên mong đợi điều gì đó tốt hơn nhiều so với tìm kiếm toàn bộ cơ sở dữ liệu. Lập luận dựa trên việc giảm SAT, giả thuyết thời gian theo cấp số nhân và rất nhiều vẫy tay.

nx|x|=nxj=1jxj=012nkkANDORNOTn2n

Chúng tôi không nên mong đợi tìm kiếm hiệu quả trong thời lượng của truy vấn (bằng cách giảm xuống SAT). Chúng ta cũng không nên mong đợi tốt hơn nhiều so với việc xem xét tất cả các mục trong cơ sở dữ liệu theo giả thuyết thời gian theo cấp số nhân.

n1


Quan sát tốt. Mỗi câu hỏi có tối đa 5 thẻ, do đó, một truy vấn về thẻ tương đương với 5-CNF.
Kaveh

cảm ơn bạn! vâng, chúng tôi có thể giả sử 5-CNF ở đây hơn nữa, hành vi gắn thẻ không phải là ngẫu nhiên. Nói chung, mọi người sẽ gắn thẻ các công cụ với các thẻ phổ biến nhất, do đó sẽ cho phép một vài phím tắt khác.
Sam Saffron

1
@Kaveh, chúng tôi đã kết thúc một cấu trúc bộ nhớ. Có một vài phím tắt không tầm thường, sắp xếp là một nút cổ chai, sử dụng sắp xếp heap hoặc sắp xếp nhanh được sửa đổi cho phép bạn chọn N hàng đầu một cách hiệu quả mà không cần thực hiện sắp xếp đầy đủ. các loại tính toán trước cho phép bạn chọn pivots hiệu quả hơn và tránh các loại sắp xếp khi cần quét toàn bộ. đa luồng tăng tốc các lựa chọn. rất nhiều công việc có thể được hoãn lại trước khi người dùng tương tác với các cấu trúc. thật đáng kinh ngạc, các cấu trúc trong bộ nhớ của chúng tôi trung bình 0ms cho một tìm kiếm trên tập dữ liệu tràn ngăn xếp.
Sam Saffron

@SamSaffron - Bài viết của MSO chi tiết về tính năng này ở đâu? Chúng tôi đã có một báo cáo lỗi ở đây .
Kevin Vermeer

5

Đây là một câu trả lời khá đơn giản, nhưng tôi nghĩ hiệu quả:

Map Tag ([Id],[Id])O(log(n))

Map Id (Set Tag)IdO(nlog(m))


Tôi có xu hướng đồng ý rằng một số cấu trúc rất đơn giản như bản đồ được lưu trữ nhiều lần có thể là cách tốt nhất để đến đây. bộ nhớ rẻ và duy trì nhiều bộ nhớ cache không quá khó
Sam Saffron
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.