Здравствуйте, удусекшл, Вы писали:
У>Если жирнющий файл — база SQLite, несколько десятков гигов, собрана через инет. Она постоянно обновляется — но, скорее всего, основная запись идёт в конец, да может в начале какие-то указатели обновляются. Ничего не удаляется. Хотелось бы её использовать в нескольких местах. Везде заново формировать — не вариант — очень долго. Хочется, чтобы можно было шарить основную базу, чтобы она скачивалась сразу, ну, а потом уже может и пусть каждый обновляется, это уже не критично. Но, или если клиент долго сам не обновлялся, то ему проще скачать обновления с актуальной базы с сервака, чем самому обновляться.
А сконвертить в клиент-серверную БД, типа постгреса или Марии, и поднять БД сервак? Сейчас даже самые дешманские хостера дают это сделать с минимумом усилий. Коннектиться из любого клиента, например dbeaver. Мне кажется, ты недооцениваешь простоту и надёжность этого решения.
Здравствуйте, удусекшл, Вы писали:
У>Тут подумалось — надо, во-первых, таки проверить свои догадки, по поводу того, какие места в файле меняются. И вторая идея — если основная масса не меняется и не перемещается — то тогда может ручками нарезать хоть по гигу, и тогда с большой вероятностью целиком будет перекачиваться только первый и последние файлы?
Ты почти изобрел инкрементальный бэкап (и синхронизацию).
Инструментов готовых много, выбирай. rsync, Syncthing, zsync, zpaq и т.д.
Здравствуйте, удусекшл, Вы писали:
G>>А сконвертить в клиент-серверную БД, типа постгреса или Марии, и поднять БД сервак? Сейчас даже самые дешманские хостера дают это сделать с минимумом усилий. Коннектиться из любого клиента, например dbeaver. Мне кажется, ты недооцениваешь простоту и надёжность этого решения.
У>Мне не нужно какое-то централизованное решение. Мне нужно, чтобы у обычного простого человека с моей программой была возможность расшарить эту базу на пару других своих компов — с домашнего — на рабочий, или ещё куда. Кто в такой схеме должен заниматься базами у хостера?
Ну так встрой постгрес в свою программу. Я подобные решения видел, именно на постгресе.
Если жирнющий файл — база SQLite, несколько десятков гигов, собрана через инет. Она постоянно обновляется — но, скорее всего, основная запись идёт в конец, да может в начале какие-то указатели обновляются. Ничего не удаляется. Хотелось бы её использовать в нескольких местах. Везде заново формировать — не вариант — очень долго. Хочется, чтобы можно было шарить основную базу, чтобы она скачивалась сразу, ну, а потом уже может и пусть каждый обновляется, это уже не критично. Но, или если клиент долго сам не обновлялся, то ему проще скачать обновления с актуальной базы с сервака, чем самому обновляться.
На флешке носить — не вариант.
Закачивать на какой-то сервак ftp/http — тоже так себе вариант, хоть и автоматом можно попробовать настроить.
Думал было на торренты — но вроде как если файл поменялся, он ему просто всему хэш пересчитает, и файл будет заново весь качаться. Или я не прав?
В какую сторону ещё можно посмотреть?
Тут подумалось — надо, во-первых, таки проверить свои догадки, по поводу того, какие места в файле меняются. И вторая идея — если основная масса не меняется и не перемещается — то тогда может ручками нарезать хоть по гигу, и тогда с большой вероятностью целиком будет перекачиваться только первый и последние файлы?
У>Думал было на торренты — но вроде как если файл поменялся, он ему просто всему хэш пересчитает, и файл будет заново весь качаться. Или я не прав?
В торрентах передаются только изменившиеся чанки (а скачивание нового торрента сводится к созданию пустого файла и докачиванию изменений).
Соответственно, при скачивании нового файла поверх существующего, будут рассчитаны хеш-суммы существующих чанков, и если они совпадут, то на этом для них всё закончится.
Но более-менее эффективной репликации нужно чтобы чанки не меняли своё положение в файле (в торрентах они жёстко привязаны к смещениям) и достаточно редко менялись.
У>В какую сторону ещё можно посмотреть?
rsync — классика синхронизации. Также умеет отслеживать неизменные фрагменты и передавать отличия. Лучше чем всегда тянуть полный файл через http/ftp.
Но конкретно для баз данных может быть интереснее посмотреть на проблему не со стороны файлов, а со стороны репликации средствами СУБД. То есть чтобы модификации мастер-БД рассылались в online по своему протоколу по репликам.
W>Ты почти изобрел инкрементальный бэкап (и синхронизацию). W>Инструментов готовых много, выбирай. rsync, Syncthing, zsync, zpaq и т.д.
Это всё здорово, но хотелось бы, чтобы можно было связаться между собой, сидя за натом. Торренты в это умеют, настраивать роутер под себя, а с остальным возится надо
Здравствуйте, watchmaker, Вы писали:
У>>Думал было на торренты — но вроде как если файл поменялся, он ему просто всему хэш пересчитает, и файл будет заново весь качаться. Или я не прав? W>В торрентах передаются только изменившиеся чанки (а скачивание нового торрента сводится к созданию пустого файла и докачиванию изменений). W>Соответственно, при скачивании нового файла поверх существующего, будут рассчитаны хеш-суммы существующих чанков, и если они совпадут, то на этом для них всё закончится.
W>Но более-менее эффективной репликации нужно чтобы чанки не меняли своё положение в файле (в торрентах они жёстко привязаны к смещениям) и достаточно редко менялись.
Спс.
У>>В какую сторону ещё можно посмотреть? W>rsync — классика синхронизации. Также умеет отслеживать неизменные фрагменты и передавать отличия. Лучше чем всегда тянуть полный файл через http/ftp.
W>Но конкретно для баз данных может быть интереснее посмотреть на проблему не со стороны файлов, а со стороны репликации средствами СУБД. То есть чтобы модификации мастер-БД рассылались в online по своему протоколу по репликам.
Мне надо сидя за НАТом синкаться. Торренты в это умеют. Хотя, я особо не изучал вопрос, идея только родилась — что будет, если есть только два узла, из которых один раздаёт, а другой хочет получить, и имеет, может, торрент файл, или вообще магнет ссылку — это может взлететь?
И у SQLite вроде нет встроенных средств синхронизации. Взрослую БД предлагать не надо, с ними возни много, и смысла для меня нет. База на компе с программой, которая имеет исключительный доступ к ней, нужно чтобы всё было встроено в прогу — ни каких тебе серверов, никакой настройки соединения с базой, никакого её администрирования — всё это не нужно
Здравствуйте, удусекшл, Вы писали:
У>На флешке носить — не вариант. У>Закачивать на какой-то сервак ftp/http — тоже так себе вариант, хоть и автоматом можно попробовать настроить. У>Думал было на торренты — но вроде как если файл поменялся, он ему просто всему хэш пересчитает, и файл будет заново весь качаться. Или я не прав? У>В какую сторону ещё можно посмотреть?
Мужики тут мегу пользуют, зашибись удобно. Рекомендую.
Здравствуйте, gyraboo, Вы писали:
G>А сконвертить в клиент-серверную БД, типа постгреса или Марии, и поднять БД сервак? Сейчас даже самые дешманские хостера дают это сделать с минимумом усилий. Коннектиться из любого клиента, например dbeaver. Мне кажется, ты недооцениваешь простоту и надёжность этого решения.
Мне не нужно какое-то централизованное решение. Мне нужно, чтобы у обычного простого человека с моей программой была возможность расшарить эту базу на пару других своих компов — с домашнего — на рабочий, или ещё куда. Кто в такой схеме должен заниматься базами у хостера?
Здравствуйте, удусекшл, Вы писали:
У>Это всё здорово, но хотелось бы, чтобы можно было связаться между собой, сидя за натом. Торренты в это умеют, настраивать роутер под себя, а с остальным возится надо
То есть вопрос не настолько важный, что стоит этой (единоразовой) возни? ОК.
Есть Bittorrent Sync. Теперь он стал Resilio Sync и платным, но предыдущие версии доступны.
Здравствуйте, удусекшл, Вы писали:
У>Мне не нужно какое-то централизованное решение. Мне нужно, чтобы у обычного простого человека с моей программой была возможность расшарить эту базу на пару других своих компов — с домашнего — на рабочий, или ещё куда.
Ну здрасьте, эт оуже совсем другая постановка задачи! Сразу так надо было.
Значит тебе нужно в своей программе реализовать какой-то протокол синхронизации. И NAT punching тоже.
Или это для тебя тоже "слишком много возни"?
Здравствуйте, wildwind, Вы писали:
W>Ну здрасьте, эт оуже совсем другая постановка задачи! Сразу так надо было.
W>Значит тебе нужно в своей программе реализовать какой-то протокол синхронизации. И NAT punching тоже. W>Или это для тебя тоже "слишком много возни"?
Ну, в libtorrent вроде всё это есть, потому и посматриваю. Если отдельно со всем разбираться, то да — слишком много возни. Может, есть что-то аналогичное libtorrent'у по функционалу, что мне лучше подойдёт?
У>Ну, в libtorrent вроде всё это есть, потому и посматриваю.
Откуда все? Торрент это лишь транспорт, а какие данные синхронизировать, в каком объеме, — это кроме тебя никто не знает.
Тупо синхронизировать файл с базой целиком так себе идея, по-моему. Там наверняка есть часть данных, относящаяся к конкретному рабочему месту. Над базой могут проводиться всякие служебные операции, оптимизации, перестроения индексов, которые будут перемешивать данные на физ. уровне. Сами индексы, кстати могут до половины объема занимать. Зачем их гонять туда-сюда? А еще журнал транзакций есть и прочие нюансы.
Нужно синхронизировать данные на прикладном уровне.
У>Если отдельно со всем разбираться, то да — слишком много возни. Может, есть что-то аналогичное libtorrent'у по функционалу, что мне лучше подойдёт?
Стандартный "простой" подход сейчас — синхронизация через облачное хранилище. Оно почти у всех есть. Для инкрементальной синхронизации бесплатных квот хватит с головой.
Здравствуйте, wildwind, Вы писали:
W>Откуда все? Торрент это лишь транспорт, а какие данные синхронизировать, в каком объеме, — это кроме тебя никто не знает. W>Тупо синхронизировать файл с базой целиком так себе идея, по-моему. Там наверняка есть часть данных, относящаяся к конкретному рабочему месту. Над базой могут проводиться всякие служебные операции, оптимизации, перестроения индексов, которые будут перемешивать данные на физ. уровне. Сами индексы, кстати могут до половины объема занимать. Зачем их гонять туда-сюда? А еще журнал транзакций есть и прочие нюансы.
"Справочники", которые могут меняться, хоть и редко — они в одной базе, данные пользователя — в другой. Их не надо синхронизировать. Жирная база — третья.
Индексы хз, конечно, как они там строятся. А данные я вливаю без транзакций.
W>Нужно синхронизировать данные на прикладном уровне. У>>Если отдельно со всем разбираться, то да — слишком много возни. Может, есть что-то аналогичное libtorrent'у по функционалу, что мне лучше подойдёт? W>Стандартный "простой" подход сейчас — синхронизация через облачное хранилище. Оно почти у всех есть. Для инкрементальной синхронизации бесплатных квот хватит с головой.
