Ở phần này tôi sẽ trình bày các tình huống trong luồng dữ liệu liên tục và thuật toán cho truy vấn liên tục.
a. Các giả thiết về truy vấn liên tục
Giả thiết rằng chúng ta có luồng dữ liệu liên tục các bản ghi và một truy vấn Q, chúng ta cần kết quả trả lời của Q dựa trên luồng dữ liệu đó như miêu tả hình 3.2 dưới đây:
Hình 3.2: Kiến trúc truy vấn liên tục trong luồng dữ liệu
Vì Q là một truy vấn liên tục do đó nó sẽ được kích hoạt một lần và hoạt động liên tục đón các bản ghi mới trong luồng dữ liệu đó. Với giả thiết rằng chúng ta cần kết quả trả lời chính xác của Q (trong tình huống khác có thể là xấp xỉ). Hơn nữa chúng ta giả thiết luồng dữ liệu này chỉ có thêm mới mà không có cập nhật hay xóa dữ liệu. Vì vậy kích thước của luồng dữ liệu này là không giới hạn bổ sung mới cho cơ sở dữ liệu D, chúng ta có một số tình huống để thực hiện Q sau đây [2] [3]:
(1) Giả thiết chúng ta muốn lưu toàn bộ kết quả trả lời A của Q. Vì cơ sở dữ liệu D là có kích thước không giới hạn, kích thước của A cũng không giới hạn (Ví dụ như Q là truy vấn Select).
(2) Giả thiết chúng ta không cần lưu giữ kết quả A thay vào đó chúng chỉ cần các bản ghi mới của A khi chúng sinh ra từ các luồng dữ liệu liên tục. Mặc dù chúng ta không cần lưu trữ cho A nhưng chúng ta sẽ vẫn cần không gian để giữ các bản ghi đó nhằm xác định các bản ghi mới trong A. (Ví dụ Q là một self-join).
(3) Thậm chí khi luồng dữ liệu chỉ thêm mới thì vẫn có thể xảy ra trường hợp thay đổi, xóa bản ghi trong kết quả trả lời A. (Ví dụ như Q là 1 truy vấn Group by với tính toán tổng hợp dữ liệu). Bây giờ trong trường hợp 2 ở trên
----<A,B><B,C><A,D>----
Luồng dữ liệu liên tục
Truy vấn liên tục
Q A Kết quả
chúng ta có thể phải thay đổi hoặc xóa bản ghi trong luồng dữ liệu ra (Luồng dữ liệu kết quả) cùng với các bản ghi được bổ sung mới.
(4) Trong phần lớn các trường hợp tổng hợp chung, luồng dữ liệu đầu vào có thể bao gồm cả cập nhật và xóa. Trong trường hợp này sẽ phải có nhiều luồng dữ liệu cần phải lưu trữ để xác định kết quả chính xác ở Q. Do đó nảy sinh vấn đề cần phải giới hạn kích thước A, khi đó kết quả trả lời truy vấn liên tục chỉ tính xấp xỉ. Tuy nhiên trong đề tài này tôi chưa đề cập đến vấn đề xấp xỉ của truy vấn liên tục.
b. Kiến trúc
Trong phần này tôi sẽ đưa ra một kiến trúc cho việc xử lý truy vấn liên tục trên các luồng dữ liệu như được mô tả trong hình 3.3.
Hình 3.3: Mô hình kiến trúc xử lý truy vấn liên tục
Chúng ta sẽ xem xét tình huống một truy vấn liên tục với kết quả trả lời A hoạt động trên một số luồng dữ liệu vào. Nhiều truy vấn liên tục cũng có thể được sử dụng với kiến trúc này như trong hình vẽ, hơn nữa kiến trúc này cũng có thể áp dụng cho các dữ liệu đầu vào kết hợp với các bảng sơ sở dữ liệu truyền thống.
Khi truy vấn Q kết luận rằng một bản dữ liệu mới t có trong một luồng dữ liệu, nó sẽ thực hiện một số hành động sau:
Stream 1 Stream 2 . . . Stream n Q Store Scratch Throw Stream
(i) Phải xác định rằng bởi vì t mà kết quả trả lời A sẽ có những bản ghi mới. Nếu mỗi bản ghi mới a trong A sẽ duy trì trong A “vĩnh viễn hay lâu dài” thì Q sẽ gửi các bản ghi a tới thành phần Stream (Luồng). Stream chứa một luồng dữ liệu được bổ xung vào A
(ii) Nếu bản ghi mới a được xác định thuộc A nhưng một lúc nào đó không thuộc A thì a sẽ được thêm vào thành phần Store (Kho) mô tả ở hình 3.3. Nói một cách khác Stream và Store sẽ xác định kết quả trả lời hiện tại của A. Nếu muốn tối thiểu không gian lưu trữ kết quả truy vấn thì các bản ghi mới sẽ được gửi thẳng tới Stream, Store bất kể khi nào.
(iii) Nếu một bản ghi mới trong luồng có thể gây nên hiện tượng thay đổi và xóa các bản ghi kết quả trả lời trong Store, các bản ghi kết quả trả lời có thể được chuyển từ Store qua Stream.
(iv) Chúng ta có thể cần lưu lại t hoặc dữ liệu dẫn xuất từ t, vì trong tương lai chúng ta có thể cần chúng để đảm bảo tính toán được kết quả truy vấn. Trong trường hợp này t hoặc dữ liệu dẫn xuất từ t có thể được gửi đến Scratch (Nháp). Kết hợp với hành động (iii) chúng ta cũng có thể chuyển dữ liệu từ store sang Scratch.
(v) Nếu chúng ta không cần t thì t sẽ được gửi đến thành phần Throw (Bỏ). Xem hình 3.3 với chú ý rằng Throw không cần bất kỳ không gian lưu trữ nào (trừ khi chúng ta quan tâm tới việc thu thập dữ liệu không cần thiết).
(vi) Với bản ghi mới t trong luồng dữ liệu, chúng ta có thể dùng để thay thế bản ghi dữ liệu đã lưu trong Stream hoặc Store trước đó và bản ghi trước đó đưa vào Throw. Nếu chúng ta muốn tối thiểu hóa không gian lưu trữ thì chúng ta cần bảo đảm rằng dữ liệu không cần thiết trong mọi trường được gửi đến Throw, hơn là Scratch.