Как эффективный способ чтения / записи очереди приоритетов в текстовый файл? - PullRequest
0 голосов
/ 05 сентября 2011

У меня есть класс очереди приоритетов, который я реализовал в Java, так как он представляет собой массив очередей. Мне нужен хороший способ (без использования сериализации) записи и хранения содержимого очереди с приоритетами после каждой «транзакции» или enqueue () / dequeue () объекта из очереди с приоритетами. Он должен служить резервной копией на тот случай, если приоритетная очередь должна быть восстановлена ​​программой из текстового файла.

Некоторые идеи, которые у меня были, и мои проблемы с каждым из них:

  • После каждой «транзакции», проходите по очередям и записывайте каждую в строку в файле, используя разделители между объектами. - Моя проблема с этим заключается в том, что для этого потребовалось бы вывести все объекты из очереди и снова поставить их в очередь, и это кажется крайне неэффективным.

  • После каждой постановки в очередь или снятия в очередь просто пишите этот объект или удаляйте этот объект из файла. - Моя проблема с этим заключается в следующем: если это тот подход, который я должен использовать, мне трудно найти способ легко найти и удалить объект после снятия с очереди.

Любые советы / советы / предложения будут с благодарностью!

Ответы [ 4 ]

1 голос
/ 05 сентября 2011

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

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

Запишите время и пространство n, повторы должны быть редкими и относительно быстрыми.

1 голос
/ 05 сентября 2011

Чтобы перебрать очередь, вы можете просто перебрать ее. Это неразрушающий (но только слабо безопасный поток)

Запись содержимого очереди на диск каждый раз, вероятно, будет очень медленной. Для типичного жесткого диска запись в небольшую очередь занимает около 20 мс. в лучшем случае 50 раз в секунду. Если вы используете SSD, это будет намного быстрее для небольшой очереди, однако вам все равно придется упорядочивать свои данные, даже если вы не используете сериализацию.

Альтернативой является использование JMS-сервера, который предназначен для поддержки транзакций, очередей и постоянства. Типичный сервер JMS может обрабатывать около 10000 сообщений в секунду. Есть много хороших бесплатных серверов.

0 голосов
/ 05 сентября 2011

еще одно предложение: (чтобы учесть, если использование одного файла точно не является обязательным):

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

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

0 голосов
/ 05 сентября 2011

Легко найти объекты при втором подходе ... У меня есть пара предложений ::

  1. Вы можете использовать свою приоритетную функцию для сохранения объектов, отсортированных в файле.
  2. Чтобы управлять вновь добавленными объектами в разных позициях, оставляйте некоторое пространство между каждым вставленным объектом в текстовом файле, и когда объект вставляется, вы можете использовать поведение, похожее на указатель, для указания смещения или что-то еще, чем можно легко управлять.
  3. Используйте буфер, так как запись содержимого evreytime может быть очень медленной.
  4. Удаление будет тривиальным, если вы будете осторожно использовать свою приоритетную функцию.
  5. Кроме того, сортировка в небольших сегментах, на которые указывают указатели, будет очень быстрой, и вы всегда можете использовать тип поведения сборки мусора, сжимая все объекты через некоторое время.
...