Khớp nối thấp xử lý số lượng lớn dữ liệu


8

Thông thường tôi đạt được khớp nối thấp bằng cách tạo các lớp trao đổi danh sách, bộ và bản đồ giữa chúng. Bây giờ tôi đang phát triển một ứng dụng bó Java và tôi không thể đặt tất cả dữ liệu vào cấu trúc dữ liệu vì không đủ bộ nhớ. Tôi phải đọc và xử lý một khối dữ liệu và sau đó chuyển sang dữ liệu tiếp theo. Vì vậy, có khớp nối thấp khó khăn hơn nhiều vì tôi phải kiểm tra ở đâu đó nếu vẫn còn dữ liệu để đọc, v.v.

Những gì tôi đang sử dụng là:

Nguồn -> Quá trình -> Kiên trì

Các lớp xử lý phải yêu cầu các lớp Nguồn nếu có nhiều hàng để đọc.

Các thực tiễn tốt nhất và hoặc các mẫu hữu ích trong các tình huống như vậy là gì?

Tôi hy vọng tôi đang giải thích chính mình, nếu không nói với tôi.


3
một trong những cách để đạt được kết nối thấp là thiết lập một giao thức giao tiếp tốt giữa các lớp nguồn và các lớp xử lý
treecoder

3
Tôi nghĩ rằng bạn có thể muốn xem xét bằng cách sử dụng hàng đợi tin nhắn - một loại bus dữ liệu - để các lớp của bạn sắp xếp mọi thứ vào hàng đợi và kéo chúng khỏi hàng đợi thay vì tương tác trực tiếp.
Murph

@Murph có cách nào đơn giản hay thư viện Java tốt để sử dụng hàng đợi tin nhắn không?
Виталий Олегович

@vitalik - Tôi là một nhà phát triển .NET và vẫn cảm thấy theo cách của tôi với hàng đợi tin nhắn nói chung vì vậy không thực sự ở vị trí để đưa ra câu trả lời tự tin (do đó phản hồi của tôi là nhận xét)
Murph

1
@Murph ok, dù sao cũng cảm ơn bạn! Tôi đoán tôi cũng sẽ bắt đầu học xếp hàng!
Виталий Олегович

Câu trả lời:


7

Từ các bình luận tôi thấy bạn đang sử dụng Java. Có một cái nhìn vào các triển khai hàng đợi khác nhau . Đặc biệt, BlockingQueue rất hữu ích cho các tình huống của nhà sản xuất-người tiêu dùng . Bạn có thể có hai hàng đợi: một giữa Nguồn (nhà sản xuất dữ liệu) và Quy trình (người tiêu dùng dữ liệu) và một hàng khác giữa Quy trình (nhà sản xuất kết quả) và Kiên trì (người tiêu dùng kết quả).

Với các hàng đợi chặn công suất giới hạn, việc triển khai hiệu quả khá dễ dàng (phần tắc nghẽn, dù là gì, được giữ bằng dữ liệu 100% thời gian), vẫn chỉ sử dụng một lượng bộ nhớ bị ràng buộc cho dù có bao nhiêu dữ liệu.


Giải pháp của bạn là rất tốt. Nhưng điều gì xảy ra nếu tôi sử dụng hàng đợi có dung lượng hạn chế và hàng đợi đã đầy và tôi cố gắng thêm thứ gì vào đó?
Виталий Олегович

@vitalik sau đó bạn phải đặt một chiến lược vào vị trí như tạm thời lưu trữ dữ liệu trong bộ nhớ DB hoặc vào đĩa khác giải pháp khác.
Martijn Verburg

@MartijnVerburg có, nhưng tôi đoán sẽ dễ dàng hơn nếu có khả năng làm cho nhà sản xuất ngủ cho đến khi có nhiều không gian hơn trong hàng đợi.
Виталий Олегович

1
@vitalik tất nhiên có khả năng đó (để ngủ một nhà sản xuất) bạn chỉ cần làm điều đó. Một số hàng đợi có thể được cấu hình để chặn, do đó, nếu nhà sản xuất cố gắng chèn vào một hàng đợi đầy đủ, bạn chỉ cần chặn và ngủ / quay hiệu quả (xem ra cái nào) trên hàng đợi để có không gian.
sdg

1
@vitalik: Xem ví dụ tài liệu BlockingQueue.put : Chèn phần tử được chỉ định vào hàng đợi này, chờ nếu cần thiết để có chỗ trống. Đơn giản và tiện lợi! :)
Joonas Pulakka

2

Một hàng đợi chặn (từ Joonas Pulakka) là câu trả lời nặng nề. Một câu trả lời đơn giản hơn có thể làm việc. Nếu bạn có tất cả dữ liệu được lưu trữ trong nguồn, bạn có thể chuyển tham chiếu đến bộ xử lý và nó có thể lấy dữ liệu ra khỏi nguồn. Tất nhiên, đây có lẽ là những gì bạn đã làm trong quá khứ. Bạn có thể không có tất cả dữ liệu trong bộ nhớ trong nguồn và bạn có thể không có được khớp nối thấp mà bạn muốn.

Bước tiếp theo sẽ là sử dụng giao diện Enumerator hoặc Iterator. (Các trình vòng lặp là phổ biến hơn trong Java, mặc dù hầu hết các lần removephương thức đó chỉ là một vấn đề.) Bộ xử lý sẽ lấy Iterator từ nguồn, sau đó gọi các phương thức cho đến khi hoàn thành. Nếu nguồn đang lấy terrabyte dữ liệu từ một nơi nào đó, mỗi cuộc gọi có thể mất một lúc. Nhưng nếu bạn sẽ ngủ bộ xử lý cho đến khi có thứ gì đó trong hàng đợi, thì điều này sẽ tự động làm điều đó. Và nếu nguồn đi trước nhà sản xuất, nguồn sẽ tự động chờ nhà sản xuất gọi hasNextnext.

Mặt khác, nếu bạn muốn nguồn lấy dữ liệu từ nguồn của nó nhanh nhất có thể và dự trữ nó cho đến khi bộ xử lý bắt kịp, không phải ngồi chờ bộ xử lý xử lý, thì hàng đợi - và nhiều luồng-- bắt đầu giống như một ý tưởng tốt, nếu phức tạp hơn. Bây giờ nguồn có thể chồng dữ liệu khi nó có thể chạy nhanh hơn (giới hạn của nó có lẽ là một cái gì đó giống như I / O của đĩa) và bộ xử lý có thể giảm kích thước của cọc khi có thể chạy nhanh hơn (giới hạn của nó là tốc độ bền bỉ nhanh như thế nào mô-đun có thể duy trì dữ liệu).

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.