RFC: Какой хороший подход для удаленного редактирования очень больших двоичных файлов?

Question

У меня есть несколько довольно больших двоичных файлов (записи фиксированной длины, формат которых описан в другом - текстовом - файле). Файлы данных могут получить до 6 ГБ. Файлы макетов (cobol copybooks) имеют небольшой размер, обычно менее 5 КБ.

Все файлы данных сосредоточены на сервере GNU / Linux (хотя они были сгенерированы в мэйнфрейме).

Мне нужно предоставить тестировщикам средства для редактирования этих двоичных файлов. Существует бесплатный продукт RecordEdit (http://record -editor.sourceforge.net / ), но у него есть два серьезных недостатка:

1. Это заставляет тестеров загружать огромные файлы через SFTP, только для загружать их еще раз каждый раз, когда небольшое изменение было сделано. Very неэффективен.

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

Я имею в виду архитектуру клиент / сервер, основанную на Java:

• Сервер будет работать постоянно процесс, слушая ориентированные на издание запросы от клиент. Такие запросы будут включать такие вещи, как

  • вернуть список доступных файлов

  • заблокировать определенный файл для издания

  • изменить эти данные в этой записи

  • вернуть n-ю страницу записей

  и так далее ...

• Клиент может принимать любую форму (На основе RCP на рабочем столе, который является моим первым кандидатом, ncurses на том же сервере, в средней сети приложение…) до тех пор, пока оно способно отправлять запросы на сервер.

Я изучал NIO (из-за его буферов) и MINA (из-за прозрачности протокола), чтобы реализовать схему. Тем не менее, перед дальнейшим продвижением этой работы, я хотел бы собрать ваши экспертные мнения.

Мой разумный способ решить проблему?

Возможно ли сделать это, используя язык и рамки, о которых я думаю? Это удобно?

Знаете ли вы какие-либо шаблоны, чертежи, примеры успеха или открытые проекты, которые напоминают или имеют отношение к тому, что я пытаюсь сделать?

Answer 1

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

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

Может быть, имеет смысл сделать что-то, что действует как база данных (или использовать существующую базу данных) для этих данных? Или его слишком много?

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

Answer 2

Мой разумный способ решить проблему?

ИМО, да.

Возможно ли сделать это, используя язык и рамки, о которых я думаю?

Я так думаю. Но есть и другие альтернативы. Например:

• Поместить записи в базу данных и получить доступ по ключу, состоящему из имени файла + номер записи. Это может быть полная СУБД или более легкое решение.

• Реализация в виде веб-службы RESTful с пользовательским интерфейсом, реализованным в HTML + javascript.

• Реализация с использованием масштабируемой распределенной файловой системы.

Кроме того, из вашего описания, кажется, нет острой необходимости использовать сильно масштабируемый / транспортно-независимый слой ... если только вам не нужно поддерживать сотни одновременных пользователей.

Это удобно?

Удобно для кого? Если вы говорите о себе как о разработчике, это зависит от того, знакомы ли вы с этими фреймворками.

Answer 3

Рассматривали ли вы использование распределенной файловой системы, такой как OpenAFS ?Это должно быть в состоянии обрабатывать очень большие файлы.Затем вы можете написать клиентское приложение для редактирования файлов, как если бы они были локальными.