heuristic để tìm kiếm thông qua dữ liệu không được sắp xếp hoàn hảo

Đưa ra dữ liệu được sắp xếp, giải pháp tìm kiếm là rõ ràng. Cho dữ liệu chưa được sắp xếp, các tùy chọn hợp lý được sắp xếp sau đó tìm kiếm hoặc chỉ tìm kiếm tuyến tính.

Câu hỏi này là về những việc cần làm nếu dữ liệu được sắp xếp một chút , nhưng không thể được tổ chức lại (hoạt động ghi yêu cầu xóa ngành và các ngành sẽ không phù hợp với ram).

các chi tiết:

Các bản ghi dữ liệu được ghi lại liên tục với dấu thời gian . Tuy nhiên, đồng hồ dấu thời gian, đôi khi được đặt lại thành Epoch trong một thời gian trước khi được đồng bộ hóa hoặc đơn giản là nó được điều chỉnh lại do tiết kiệm ánh sáng ban ngày, v.v.

Kết quả tìm kiếm phải là bản ghi nhật ký với dấu thời gian gần nhất với thời gian được chỉ định. Trong khi thực hiện tìm kiếm nhị phân cho bản ghi tại một dấu thời gian cụ thể, có thể hạ cánh trên một bản vá dữ liệu nhật ký không rõ ràng và xoay sai hướng.

Bên cạnh một phương pháp tuyến tính vũ phu, liệu có một heuristic chúng ta có thể tận dụng ở đây? ví dụ: Tìm kiếm Simplex miễn dịch với cực tiểu địa phương?

cập nhật:

Chúng tôi có thể giả định khoảng 95% các bản ghi được sắp xếp theo thứ tự. khoảng 5% (rải rác qua nhật ký) là những tiếng nấc bẩn. Sự bắt đầu của các trục trặc có thể được xác định khi dấu thời gian quay ngược thời gian và có dấu sớm hơn so với bắt đầu nhật ký

Giả định bổ sung

Câu trả lời này dựa trên các giả định bổ sung sau:

• bạn có thể dễ dàng xác định dấu thời gian cho phần đầu của nhật ký và
• lưu trữ các vị trí của trục trặc (tùy chọn) là khả thi

Thuật toán tìm kiếm

Việc tìm kiếm được chia thành hai thuật toán khác nhau thực sự. Trong trường hợp bạn tìm kiếm nhật ký có dấu thời gian sau khi bắt đầu nhật ký, bạn sẽ biết rằng nó sẽ không được tìm thấy trong các trục trặc và sử dụng tìm kiếm không bị nấc dưới đây. Trong trường hợp bạn tìm kiếm dấu thời gian trước khi bắt đầu nhật ký, bạn sử dụng tìm kiếm nấc thay thế. Nếu bạn không tìm kiếm theo dấu thời gian, nhưng một số tiêu chí khác, trước tiên bạn hãy thử tìm kiếm không bị trục trặc do phạm vi bảo hiểm 95% và sau đó thử tìm kiếm trục trặc nếu bạn không tìm thấy gì.

Tùy chọn, bạn có thể tăng tốc tìm kiếm không bị trục trặc bằng một bước tiền xử lý.

Tiền xử lý (tùy chọn)

Nếu có thể, hãy phân tích trước dữ liệu của bạn bằng tìm kiếm tuyến tính để tìm ra vị trí của dữ liệu trục trặc. Điều này phụ thuộc hoàn toàn vào tính khả thi của việc có thể lưu trữ các phạm vi này, điều này có thể được đưa ra là chúng chỉ chiếm tới 5% nhật ký của bạn (hoặc có thể không, trong trường hợp hiệu suất giảm xuống).

Lưu ý rằng cơ sở hạ tầng tương ứng phải được cập nhật bất cứ khi nào bạn viết nhật ký mới hoặc ít nhất nó có thể cho bạn biết điểm nào của nhật ký mà quá trình tiền xử lý được thực hiện.

Tìm kiếm không bị nấc

Có thể tìm kiếm dữ liệu không bị trục trặc thông qua sự kết hợp giữa tìm kiếm nhị phân và tuyến tính. Tuy nhiên, bạn thực hiện tìm kiếm nhị phân bình thường, khi phần tử trục của bạn được đánh dấu thời gian trước khi bắt đầu nhật ký, tức là phần tử trục là một trục trặc, bạn cần xác định mục nhập nhật ký đầu tiên trước phần tử trụ và sử dụng làm phần tử trụ thực sự tìm kiếm nhị phân của bạn.

Mục nhật ký đầu tiên này với dấu thời gian sau khi bắt đầu nhật ký được tìm thấy thông qua tìm kiếm tuyến tính bắt đầu từ phần tử trục xoay. Nếu bạn biết từ tiền xử lý hoặc cập nhật gia tăng cho các trục trặc được lưu trong bộ nhớ cache của bạn, nơi phần tử trục liên quan được định vị, bạn có thể nhảy đến đó trong thời gian liên tục. Nếu bạn phải chạy tìm kiếm tuyến tính đầy đủ, bạn cập nhật cơ sở hạ tầng để lưu trữ rằng các vị trí này được bao phủ bởi dữ liệu nấc, để lần sau bạn có thể nhanh chóng xác định phần tử trục phải.

Nấc cụt

Điều này phụ thuộc vào việc bạn đã thực hiện quá trình tiền xử lý. Nếu không, nó là một tìm kiếm tuyến tính thông qua tất cả dữ liệu của bạn (và bạn cũng có thể thực hiện các phần tiền xử lý tại thời điểm này). Mặt khác, cơ sở hạ tầng được xử lý trước của bạn có thể cho bạn biết vị trí của dữ liệu trục trặc và bạn có thể tìm kiếm trực tiếp thông qua các cơ sở dữ liệu này, tức là chỉ thực hiện tìm kiếm tuyến tính thông qua 5% dữ liệu nấc.

Hiệu suất

Đối với tìm kiếm không bị trục trặc với dữ liệu được xử lý đầy đủ, bạn có thể nhận được gần như hiệu suất của tìm kiếm nhị phân mặc định. Thay vì so sánh đơn giản ở mỗi bước mặc dù bạn cần một so sánh bổ sung để xác định xem bạn có trúng phần tử nấc hay không và nếu vậy bạn cần có quyền truy cập vào cơ sở hạ tầng của mình để tìm phần tử trụ thực sự. Tuy nhiên, công việc bổ sung này được giảm nhẹ một chút bởi thực tế là bạn không chỉ loại trừ một nửa số liệu của mình mà còn loại trừ phần dữ liệu bị trục trặc.

Tất nhiên, nếu bạn phải dùng đến tìm kiếm tuyến tính, điều này sẽ làm suy giảm theo.

Tìm kiếm nấc là một trường hợp xấu nếu bạn không có thông tin về các trục trặc hiện có và cần tìm kiếm tuyến tính thông qua tất cả các dữ liệu.

Cuối cùng, nếu bạn không tìm kiếm dấu thời gian, nhưng một số tiêu chí khác và không có mục nhật ký như vậy tồn tại, đây là trường hợp xấu nhất của bạn. Trong thực tế, nếu bạn không có cơ sở hạ tầng cho các trục trặc, nó sẽ chậm hơn tìm kiếm tuyến tính, vì cả hai lần tìm kiếm có thể quét tuyến tính các vị trí nấc giống nhau (mặc dù nó vẫn là O (n)).

Nếu bạn có sẵn cơ sở hạ tầng và được xử lý trước đầy đủ, thời gian chạy trong trường hợp xấu nhất sẽ chuyển sang O (max (log (M) * log (N), M)) trong đó M là lượng dữ liệu nấc, được tìm kiếm tuyến tính, và giả sử bạn có thể tra cứu kết thúc dữ liệu nấc cụ thể với bất kỳ vị trí trục trặc nào từ cơ sở hạ tầng của bạn trong O (log (M)).