Delphi - Синхронизация папок по сети

У меня есть приложение, которое подключается к базе данных и может использоваться в многопользовательском режиме, при котором несколько компьютеров могут подключаться к одному и тому же серверу базы данных для просмотра и изменения данных. Один из клиентов всегда назначается «главным» клиентом. Этот мастер также получает текстовую информацию от входа RS232 или UDP и записывает эти данные каждую секунду в текстовый файл на локальном компьютере.

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

  1. Напишите класс синхронизации папок для синхронизации папки на удаленном (главном) компьютере с папкой на локальном (клиентском) компьютере. Это будет процедура копирования файлов с буферизацией в потоках.
  2. Реализуйте клиент / сервер, чтобы главный компьютер мог передавать эти данные любому клиенту, который подключается и запрашивает данные. Мастер отправит файл через TCP / UDP запрашивающему клиенту.

Решение должно будет учитывать следующее:

а. Файлы журнала записываются каждую секунду. Он должен избегать любых потенциальных проблем с блокировкой файлов.

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

c. Будьте максимально эффективны

d. Все машины подключены к локальной сети

е. Синхронизацию необходимо выполнять, скажем, каждые 10 минут или около того.

f. Объем данных составляет порядка ~ 50 МБ, но после завершения начальной (первой) синхронизации объем данных для передачи будет порядка ~ 1 МБ. Это будет увеличиваться в будущем

Какой метод лучше использовать? Какие плюсы / минусы? Я также видел сообщение Fast File Copy, которое я собираюсь использовать.


person Simon    schedule 05.07.2011    source источник


Ответы (4)


Если вы используете базу данных, почему «мастер» записывает данные в текстовый файл, а не в базу данных, если эти данные должны использоваться совместно?

person Community    schedule 05.07.2011
comment
Количество «полезных» данных в этих текстовых файлах несущественно по сравнению с требованиями к хранилищу, если бы я должен был хранить их в базе данных. Я подумал об этом, но решил не хранить все это по многим причинам. - person Simon; 05.07.2011
comment
Итак, чтобы сэкономить дешевое дисковое пространство на сервере базы данных, вы тратите время на реализацию сложного решения для синхронизации на основе файлов, реплицирующего одни и те же данные n раз вместо того, чтобы сохранять их один раз в базе данных, что также хорошо решило бы одновременный доступ? - person ; 05.07.2011
comment
Да, я знаю, но есть и другие причины, по которым это происходит. Мне когда-либо понадобится около 0,001% этих данных, и время резервного копирования на сервере БД критично. «Дешевое дисковое пространство» на самом деле не дешево в данном конкретном случае, поскольку данные БД должны быть сведены к минимуму из-за отсутствия дешевого доступа в Интернет на месте - данные необходимо отправлять через дорогостоящую спутниковую связь в чрезвычайно удаленном месте. . Хотя это хороший момент, спасибо. - person Simon; 06.07.2011
comment
Не знаю, какую базу данных вы используете, но если резервное копирование базы данных критично, вы можете использовать две отдельные БД (или схемы), одну для данных и одну для журналов, чтобы вы могли создавать резервные копии по отдельности. Какие данные нужно отправлять через спутниковую связь? БД удалена? В таком случае используйте другую базу данных в локальной сети (пункт d выше) и используйте ее для журналов. - person ; 06.07.2011
comment
+1, потому что, честно говоря, решение для базы данных действительно проще всего реализовать, и оно также переносимо (работает через TCP / IP, вы можете получить к нему доступ откуда угодно). Подойдет любой db с открытым исходным кодом (т.е. без затрат на лицензирование), накладные расходы на хранилище будут минимальными. - person Cosmin Prund; 06.07.2011
comment
@ldsandon, это хорошая идея, думаю, я серьезно подумаю об использовании отдельной БД. В настоящее время используется MySQL. Основная БД составляет всего около 100 КБ в сжатом виде, и ее необходимо отправлять через спутниковую связь. Вторичная БД со временем значительно вырастет, примерно на 10 МБ в день, в течение нескольких лет. Надеюсь, поиск (через поле DateTime по-прежнему будет таким же быстрым, как и моя текущая процедура, которая занимает всего около 20-50 мс для каждого запроса) - person Simon; 06.07.2011
comment
Как долго вам нужно хранить данные в сети? Вы также можете сохранить скользящие окна и удалять через определенные промежутки времени данные, которые больше не нужны (разбиение на разделы действительно полезно для таких задач). Если таблица базы данных, индексы, кеши и запросы хорошо настроены, это будет очень быстро. В зависимости от структуры данных и использования вы также можете подумать о базе данных NoSQL. - person ; 06.07.2011
comment
Данные можно архивировать каждый год. Я вижу порядка 15-20 миллионов строк в год. - person Simon; 06.07.2011
comment
Если вам нужно хранить около 10 МБ в день, это около 4 ГБ в год, что на сегодняшний день очень мало. Даже если вы выберете систему SAS RAID 1 или 10 15k RAID, вы получите диски на 146 ГБ по разумной цене - это 30 лет хранения ... если вы используете MySQL 5.5, я бы посоветовал попробовать разбиение на разделы из соображений управляемости и скорости. - person ; 06.07.2011

Зачем изобретать колесо? Вместо этого используйте rsync. Пакет для Windows: cwrsync.

Например, на главном компьютере установите сервер rsync, а на клиентских машинах установите клиенты rsync или просто поместите файлы в каталог проекта. При необходимости ваше приложение на клиентском компьютере должно выполняться rsync.exe с запросом на синхронизацию необходимых файлов с сервера.

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

person andrius    schedule 05.07.2011
comment
+1 для rsync. В последний раз, когда мне это было нужно, я долго работал над решением на delphi. Затем я отказался и установил RSYNC и использовал его вместо этого, и больше не оглядывался назад. Это утилита unix / linux, но она отлично работает в Windows, и уже есть установщик / служба Windows. - person Warren P; 06.07.2011
comment
Я использую выделение rsync как в Windows, так и в Linux; Это инструмент для Linux, который еще не нашел подходящего варианта для Windows. В порте Windows (с использованием cygwin) есть ошибки, иногда он не работает по неизвестным причинам. В 99% случаев он работает так, как ожидалось, и я использую его, потому что 99% мне достаточно, но если требуется 100% надежность, это не выход! - person Cosmin Prund; 06.07.2011
comment
@Simon, rsync, с его корнями Linux, легко управляется из командной строки и возвращает значимые коды состояния, которые можно использовать для проверки успешности выполнения. - person Cosmin Prund; 06.07.2011
comment
rsync великолепен, но у меня нет хорошего опыта работы с rsync в Windows (и особенно в общих папках). Ограничения длины файла, ограничения имени файла, прерванные действия и т. Д. - person Marco van de Voort; 22.01.2012

Напишите интерфейс веб-службы, чтобы клиенты могли подключаться к серверу и получать новые данные по мере необходимости. Или вы могли бы написать его как механизм подписки / push, чтобы клиенты подключались к серверу, «подписывались», а затем сервер отправлял весь новый контент зарегистрированным клиентам. Клиентам необходимо будет выполнить полную синхронизацию (получить все изменения с момента последней синхронизации) при регистрации, если они были в автономном режиме, когда произошли обновления.

person Chris Thornton    schedule 05.07.2011

Оба решения отлично работают в локальной сети, выбор за вами. Возможно, вы захотите также рассмотреть вопросы, связанные с выбранной вами технологией:

  • Гибкость развертывания. Использование общих файловых ресурсов и копирования файлов требует, чтобы общий доступ к файлам работал, и все пользователи локальной сети могли получить доступ к файлам журнала.
  • Долгосрочные планы: общие файловые ресурсы хороши только в локальной сети, в то время как решения на основе IP работают в маршрутизируемых сетях, включая Интернет.
  • Файловое решение было бы значительно проще реализовать по сравнению с IP-решением.
person Cosmin Prund    schedule 05.07.2011
comment
+1 Спасибо за дополнительные вопросы. Поскольку это программное обеспечение будет использоваться только через локальную сеть (поскольку оно всегда находится в удаленном месте без Интернета), мне не о чем беспокоиться. Я думал, что на основе файлов тоже будет проще - person Simon; 05.07.2011