Выбор подходящего контейнера STL для регистрации данных

Question

Мне требуется механизм ведения журналов и фильтрации в моем клиент-серверном приложении. Где клиент может запрашивать данные журнала на основе определенного параметра.

В журнале будет MACID, дата и время, тип команды и направление в качестве поля.

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

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

Таким образом, процесс-сервер сначала выполнит сортировку по определенным критериям для вектора <>, а затем отфильтрует его с помощью бинарного поиска.

Я планирую использовать вектор в качестве контейнера STL для данных регистрации в памяти.

Я немного растерялся, подойдет ли вектор в этой ситуации или нет.

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

Answer 1

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

Answer 2

Я бы пошел с двухсторонней очередью.Это как вектор, но вы можете добавлять / удалять элементы с обоих концов.

Answer 3

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

Если в большинстве случаев используется только один просмотр данных, и вам нужно всего лишь несколько раз показать другой порядок, я бы сохранил std::vector или std::deque элементов, и отфильтруйте с remove_copy_if при необходимости.Если требуется другая сортировка, я бы скопировал и отсортировал копию, чтобы избежать необходимости повторной сортировки по времени для продолжения добавления элементов в журнал.Будьте осторожны, если приложение продолжает загружать данные, которые вам понадобятся для обновления copy с новыми элементами на месте (или для обеспечения фиксированного представления и периодического запуска операции).ни одно конкретное представление, которое встречается гораздо чаще, чем остальные, о том, что если вы не хотите испытывать трудности при реализации вышеизложенного, посмотрите на многоиндексные контейнеры.Они сохраняют синхронизированные представления одних и тех же данных по разным критериям.Это, вероятно, будет наиболее эффективным в последнем случае, и даже если оно будет менее эффективным в общем случае доминирующего представления, это может упростить ситуацию, поэтому оно все же может стоить этого.