какую структуру данных использовать для

Question

У нас есть система обмена сообщениями, в которой один модуль отправляет несколько сообщений другому удаленному модулю с высокой скоростью. Принимающий модуль декодирует это сообщение в определенном формате и пересылает его в два потока. Один называется потоком журнала, а другой - потоком пересылки.

Прежде чем мы отправим это сообщение в эти темы, нам нужно выполнить некоторую группировку этих сообщений.

Обратите внимание, что эти сообщения приходят с высокой скоростью около 800 в секунду.

Структура оповещения следующая:

1. тип INT
2. INT Идентификатор системы отправки
3. INT Recpt ID системы
4. INT отметка времени
5. INT коды
6. INT Порт источника
7. INT Порт назначения
8. IP-адрес источника (ipv4 или ipv6)
9. IP-адрес назначения (ipv4 или ipv6)

В конце матча нам нужно сохранить структуру со следующими деталями

struct{
  INT COUNT
  INT First Alert Timestamp
  INT Last Alert Timestamp
  INT First Alert ID
  INT Last Alert ID
}

Для каждого предупреждения, которое соответствует 8 критериям, будет создана / выбрана группа, и количество будет увеличено вместе с другими деталями.

Поля IP-адреса могут быть структурой из 5 полей (тип адреса INT, адрес INT1, адрес INT2, адрес INT3 и адрес 4 INT) или могут быть преобразованы в строку и затем сохранены в структуре.

Мы довольно долго ломали голову, но не смогли найти структуру или алгоритм, достаточно эффективный, чтобы можно было использовать память и скорость.

Поэтому подумал о том, чтобы обратиться к вам за помощью.

Answer 1

Что вы планируете записать? Любое предложение будет сильно зависеть от языка.

Лучше всего начинать с чего-то вроде Dictionary<string, ContainerObject>, где ключ состоит из необходимых параметров, объединенных для быстрого поиска. Продолжайте работать с этим словарем в памяти, пока другие процессы регистрируют значения соответствующим образом, например, в БД или плоском файле.

Сохраняйте это простым, и 800 секунд не должны быть проблемой. Однако средства коммуникации будут основным фактором. Это локальный или удаленный? если он удаленный и поступает из одного источника, у вашего заклятого врага будет задержка, если это будет сделано в отдельных запросах.

Answer 2

Двойной связанный список для хранения соответствующих предупреждений.Позволяет легко получить первый и последний AlertID.Возможно, вам понадобится расширить двойной связанный список, чтобы иметь поле подсчета.

В зависимости от ваших требований к производительности вы можете сгруппировать оповещения из списка с хешем на идентификаторах.И если этого недостаточно, реализуйте более сложную древовидную структуру, которая группирует по идентифицирующим полям.

Лучшее, что я могу предложить, - заставить его работать максимально простым способом, 800 в секунду - это ничто.Если у вас возникли проблемы с производительностью, оптимизируйте.Столько удовольствия от написания подобных вещей с помощью разработки, основанной на тестировании, превосходит ваш средний код!