2013-06-12 25 views
5

Tôi có một chương trình theo dõi thời gian thực hoạt động nhưng kiến ​​trúc lớp học của nó quá phức tạp. Và điều này làm tôi rất rối loạn. Hãy để tôi bắt đầu bằng cách giải thích chương trình.Kiến trúc lớp dữ liệu nhật ký giám sát

User Interaction

Đây là một chương trình giám sát với tương tác người dùng. Có nghĩa là, người dùng có thể chọn các thứ nguyên khác nhau, các chỉ số khác nhau, bao gồm chúng, loại trừ chúng hoặc nhóm chúng và mọi thay đổi biểu đồ theo thời gian thực theo quyết định của người dùng.

Ví dụ Log Dữ liệu từ DB

Req Success OrderFunction 5 60ms WebServer2 
Req Failed OrderFunction 2 176ms WebServer5 
Resp Success SuggestFunction 8 45ms WebServer2 

Các chuyển đổi

Vì vậy, mỗi hàng là rất quan trọng với nó mỗi cột. Và nó phải ở phía khách hàng như thế này. Bởi vì người dùng có thể chọn để xem thành công OrderFunctions hoặc Tất cả các chức năng trên WebServer2 hoặc Tất cả thất bại yêu cầu vv Tôi cần tất cả các mối quan hệ giữa các cột này để làm điều này.

Một điều nữa là đây là những giá trị xuất phát từ Cơ sở dữ liệu. Tôi cũng có tra cứu cho các giá trị này chứa các văn bản mà người dùng cần xem. Giống như Req là Yêu cầu, Resp là Response.

Tôi biết bạn có thể xem câu hỏi này là câu hỏi chung. Nhưng tôi đang cố tìm cách. Có thể loại kiến ​​trúc lớp này có tên trong ngành. Tôi chỉ ở đây cho một số lời khuyên để dẫn tôi đến một cách đúng đắn.

Thanks a lot

+0

Trông tôi giống như một bộ thông thường trong cơ sở dữ liệu. – darijan

+0

Có nhưng giữ nó như thế trong lớp là một nỗi đau. Có 15k hồ sơ trong một khoảng thời gian 3 phút. – Xelom

+1

Sau đó, suy nghĩ về việc giữ nó trong một cơ sở dữ liệu quan hệ và khai thác thông tin bạn cần thông qua một tập hợp các dịch vụ. OR, bạn có thể làm tất cả những gì với cấu trúc hiện tại và các đối tượng thực, nhưng cho phép sự bền bỉ của các đối tượng đó (thường là tự động, khi tạo và sửa đổi) vào một cơ sở dữ liệu đối tượng (xem ví dụ Versant). – darijan

Trả lời

1

15k ghi lại mỗi 3 phút, âm thanh rất giống những gì tôi sử dụng để xem với các ứng dụng giám sát mạng tại các trung tâm dữ liệu (snmp có thể nhận được rất ồn ào trong những môi trường đó). Những gì chúng tôi sẽ làm là xác định lượng dữ liệu chúng tôi cần, trong bao lâu, ở mức độ chi tiết nào và thông tin đó đi vào xác định loại chiến lược cuộn lên nào - cũng có bao nhiêu không gian lưu trữ mà chúng tôi sẵn sàng để giải quyết vấn đề. Với chiến lược cuộn lên nơi bạn kết hợp theo hàng thời gian, bằng cách hợp nhất các cột của chúng, bạn có thể đảm bảo có giới hạn hữu hạn về kích thước của cơ sở dữ liệu.

Có thể có các công cụ mới hơn trong những ngày này nhưng tôi thường sử dụng RRD (http://oss.oetiker.ch/rrdtool/) và BerkeleyDB ví dụ cho các loại vấn đề giám sát này. Bạn cũng có thể tận dụng lợi thế của một số phần mềm de-duplication, một cách tiếp cận trong đó bạn chỉ cập nhật một số nếu một hàng được tìm thấy là tương tự như một hàng trước đó, bởi bản chất của nội dung của các cột của nó. Chúng tôi đã từng làm điều này để ngăn chặn các cơn bão sự kiện từ màn hình lũ lụt của NOC và khiến các kỹ thuật viên bỏ lỡ các sự kiện quan trọng. Nhân tiện, tôi đã để lại điều này làm bình luận, nhưng stackoverflow làm điều danh tiếng này ngăn cản tôi và tôi mới bắt đầu trả lời các câu hỏi ở đây hôm qua.

Vì vậy, để được hoàn thiện hơn, sử dụng dữ liệu của bạn như là một ví dụ:

Req Success OrderFunction 5 60ms WebServer2 
Req Failed OrderFunction 2 176ms WebServer5 
Resp Success SuggestFunction 8 45ms WebServer2 

tôi giả Req/Resp là hai giá trị duy nhất - tương ứng với yêu cầu và phản ứng? Nếu trường hợp này xảy ra, hãy tạo cột nhị phân đó, 1 bit - cho dù đó là một yêu cầu hay không. Cột thứ hai, Thành công/Không thành công - có vẻ giống như một bit 1 hoặc ở trường 2 bit thấp nhất. Các chức năng (OrderFunction, SuggestFunction, vv) có thể được liệt kê - hoặc nếu bạn đang làm pc ở đây bạn có thể làm cho nó một bitmask. Bạn cũng có thể chỉ cần sử dụng một khóa nước ngoài cho điều này vào một bảng tham gia. Trong tùy chọn liệt kê, cho phép nói rằng bạn có ít hơn 256 trong số này nhưng nhiều hơn 128, sử dụng một byte.Nếu bạn có thể cuộn chúng trong một giải pháp de-duplication sự kiện để lưu hàng, đặc biệt là khi chúng đến nhanh như vậy, và bạn có 256 tùy chọn, thì bạn cần chính xác nhiều bit cho bitmask của bạn, trừ khi nó trường hợp không phải mỗi hoán vị được yêu cầu để được biểu diễn, trong trường hợp này, tìm ra số hoán vị tối đa, và đó là số bit trong bitmask của bạn để loại bỏ trùng lặp cuộn lên một cách chính xác. Các cột tiếp theo với 5,2, và 8 trong nó, tôi không chắc chắn những gì đại diện cho, một số nguyên của một số loại hoặc có thể chỉ là một byte? Các mili giây có thể được biểu diễn, tùy thuộc vào phương ngữ SQL của bạn và số mili giây tối đa bạn mong muốn cần đại diện, với một int hoặc có thể là một dấu ngắn, hoặc có thể chỉ ngắn (khoảng 32,7 giây). Nếu bạn sử dụng ngắn hoặc unsigned ngắn, chỉ cần chắc chắn rằng một giá trị vượt quá tối đa là đại diện như là tối đa, và không số không, trong logic ứng dụng của bạn. Cột cuối cùng trông giống như một chuỗi đại diện cho máy chủ của bạn để có thể là một cột mà bạn sẽ sử dụng để giúp hướng dẫn xóa trùng lặp hoặc cuộn lên. Vì vậy, bạn có thể làm cho rằng một chìa khóa nước ngoài có lẽ.

Dù sao, RRD thường rất tốt nhưng tôi đã không sử dụng nó trong gần một chục năm - tôi lấy lại, tôi đã không sử dụng RRD trong hơn một chục năm :). Tôi chắc chắn BerkeleyDB vẫn là một cơ sở dữ liệu tốt mặc dù cho loại điều này - vì vậy hãy kiểm tra những công cụ và công cụ như họ và tôi chắc chắn một giải pháp tốt sẽ đi ra khỏi nó.

Hy vọng điều đó sẽ hữu ích!

+0

Cảm ơn bạn đã trả lời chi tiết. Tôi không có vấn đề gì về cấu trúc cơ sở dữ liệu của tôi. Vấn đề duy nhất là dữ liệu của tôi trong ứng dụng. Và bạn giải thích vấn đề của tôi thực sự tốt. Hủy trùng lặp. Vì tôi muốn giữ tất cả dữ liệu và muốn người dùng thay đổi dữ liệu, hãy lọc hoặc nhóm dữ liệu đó. Tôi giữ rất nhiều dữ liệu trùng lặp. Ví dụ: nếu người dùng không muốn thấy các giao dịch không thành công. Tôi cần phải lọc từng hàng với thất bại trong ứng dụng của tôi và nó phải giảm số thứ tự OrderFunction thất bại. – Xelom

+0

Một cách tiếp cận có thể là làm cho logic ứng dụng trở nên mỏng hơn - có nghĩa là, trao đổi nhiều chuyến đi tới cơ sở dữ liệu và đặt giới hạn về số lượng hàng trả về được crunched trong tầng ứng dụng hoặc trong ứng dụng khách để tăng hiệu suất và giảm độ phức tạp.Bạn có thể sử dụng các thủ tục được lưu trữ để thực hiện crunching, thậm chí bạn có thể thực hiện việc crunching trên một cơ sở dữ liệu nhân bản hoặc nô lệ và dự trữ master cho các chèn. Xóa trùng lặp khi chèn sẽ làm cho các truy vấn của người dùng cuối nhanh hơn trong khi tính năng de-duplicating tại thời điểm truy vấn cung cấp tính linh hoạt cho các yêu cầu trong tương lai. – hoonto

+0

Vì vậy, một số tính năng lọc có thể diễn ra trong ứng dụng hoặc ứng dụng khách, nhưng trên một tập dữ liệu đã giảm. Ngoài ra, đối với những trường hợp bạn thực sự cần lọc nhiều dữ liệu thô, hãy làm điều đó như một thủ tục được lưu trữ với các tùy chọn lọc. – hoonto

Các vấn đề liên quan