создать новую тему раскрыть все
 
Когда мы говорим про версию AbilityCash для мобильных устройств, мы подразумеваем, что эта версия сможет синхронизировать данные с версией программы для настольных компьютеров. Между тем, синхронизация сама по себе является непростой задачей и имеет кучу разных способов решения. Я долго думал, как именно должна работать синхронизация и вот к чему пришел:
 
Для синхронизации предполагается использовать сервис Dropbox. Вообще, я рассматривал и другие варианты, начиная от синхронизации через USB-провод, по локальному wi-fi и организации собственного сервера синхронизации. Однако, в конечном итоге пришел к тому, что облачный сервис является наиболее гибким и удобным для решения таких задач. Выбор в пользу Dropbox-а был сделан исключительно по интуитивной оценке популярности, мне показалось, что это один из самых известных сервисов такого рода. Ну и наличие у него программного интерфейса для доступа тоже сыграло свою роль.
 
Я планирую построить синхронизацию на основе журналов обновления. Работать это должно примерно так: всякий раз, когда вы изменяете что-то в своих данных (и если настроена синхронизация), программа формирует маленький файлик, который содержит описание этого изменения, например, «удалена такая-то операция», «добавлена новая статья расхода» или «изменено положение счета в плане счетов». Этот файлик пересылается на сервер и выкладывается в выделенной для синхронизации папочке. Точно так же, с некоторой периодичностью будет проверяться наличие новых изменений на сервере, выложенных другими пользователями (другими устройствами). При наличии таких изменений, они тут же загружаются с сервера и применяются к актуальному файлу данных. Конечно, при этих операциях выполняется проверка на наличие конфликтов.
 
Если учет ведет один человек, он может синхронизировать все свои устройства при помощи своего аккаунта Dropbox. Если с одним файлом работают несколько человек, папку для синхронизации потребуется сделать разделяемой и выделить соответствующие полномочия для участников процесса.
 
Собственно, зачем я это пишу? Мне хотелось бы услышать критику, замечания или пожелания к изложенной концепции. Сейчас я работаю над переводом файла данных на SQLite и в процессе этой работы мне хочется предусмотреть возможность синхронизации.
 
Заранее благодарю.
 
Моя база уже сейчас хранится в облаке Dropbox'а, доступ к ней с компьютеров и из дома и на работе + нетбук всегда со мной (пользователь я один). Если не происходит синхронизация вовремя, то у меня появляется несколько файлов у которых к имени файла базы приписка имени компьютера, с которого были внесены изменения и времени внесения изменений. Если "файлик" решит проблемы несвоевременной синхронизации и объединения всех "конфликтных" по времени, но не по сути изменений в одном, основном файле базы, то замечательно!
Разделения полномочий - вообще Ура! Если я правильно понял, то можно будет выделить участнику некую статью, в которую он сможет вносить изменения, а я (полноправный обладатель) смогу видеть и контролировать историю изменений? Так?
По разделенным полномочиям вообще множество вопросов, но сначала нужно уловить саму суть.
Вообще-то синхронизация больше интересна если она решает вопросы внесения изменений как со станционарных, так и с мобильных клиентов (а мобильного клиента АС, как видно пока не предвидится), но вот РАЗДЕЛЕНИЕ ПОЛНОМОЧИЙ!!!
 
...уже сейчас может положить файл в облако и работать с ним с разных устройств.
 
Если "файлик" решит проблемы несвоевременной синхронизации и объединения всех "конфликтных" по времени, но не по сути изменений в одном, основном файле базы, то замечательно!

Должен решить. Выглядеть это будет так: запускаете программу, она показывает данные и параллельно подгружает изменения с сервера. Пока идет подгрузка, программа должна быть работоспособной.
 
Если я правильно понял, то можно будет выделить участнику некую статью, в которую он сможет вносить изменения, а я (полноправный обладатель) смогу видеть и контролировать историю изменений? Так?

Так, но это в идеале. На первом этапе мне хотелось бы сделать хотя бы просто одновременную работу без разделения полномочий. Но разделение полномочий необходимо и мне понятно как его реализовать корректно. Это будет следующим шагом, после синхронизации.
 
Вообще-то синхронизация больше интересна если она решает вопросы внесения изменений как со станционарных, так и с мобильных клиентов (а мобильного клиента АС, как видно пока не предвидится)

Мобильный клиент без синхронизации не имеет смысла. Синхронизация как раз и должна открыть дорогу и к мобильному клиенту и к разделению полномочий.
 
По разделенным полномочиям вообще множество вопросов

Да нет, там как раз все более или менее понятно. Однако, мне не хотелось бы это обсуждать в этой ветке, тут по синхронизации вопросов хватит. Если интересно про полномочия, создайте отдельную ветку форума, я там отвечу и расскажу.
 
 
В качестве альтернативы предлагаю рассмотреть возможность использования Google Drive. Любой человек, имеющий почтовый аккаунт на GMail, автоматически получает доступ к сервису. А с учётом того, что учётную запись GMail имеют практически все владельцы Android-устройств (и даже некоторые владельцы техники Apple To wink ), этот вариант кажется более практичным.
 
Обязательно посмотрю, какие средства для программного доступа предоставляет google.
свернуть/развернуть ветвь Кстати, про Google Drive [Дим(м) 24/04/2013 12:40] # написать ответ
 
Недавно Гугл открыл API для создания полу-скрытых папок "для данных программ" на Google Drive.
 
Благодаря этому любая программа может сохранять свои файлы в это облако, но они не будут видны пользователю, не будут мешаться под руками среди прочих, обычных таблиц, документов, архивов.
 
Вот тут подробнее: http://pocketnow.com/2013/04/04/google-drive-app-folders
 
Также у них есть Realtime API, предназначенное для обеспечения одновременной работы с данными, разрешения конфликтов (!) и пр.
http://googledevelopers.blogspot.nl/2013/03/build-collaborative-apps-with-google.html
 
...отличной новостью. Похоже, Google будет вне конкуренции при выборе средства для AbilityCash.
 
А что Вы думаете про сам подход к синхронизации посредством инкрементных логов? Честно говоря, меня самого немного смущает такой подход, видимо, потому что в голове до сих пор сидит идеология, принятая в ActiveSync от Microsoft, там синхронизация проводилась при полном доступе к синхронизируемым базам. Тут же будет идти накопление изменений.
 
В предложенном мною подходе меня смущает то, что (а) нужно придумывать схему по обработке конфликтов, это пока для меня не очевидно и (б) возможные непонятки, связанные, например, с непоставкой на сервер очередного инкрементного лога из-за разрыва связи или еще по какой причине.
 
Я понимаю, что можно либо целиковый файл хранить на сервере, либо обмениваться с сервером инкрементными логами (третьего варианта просто не вижу), мне пока больше нравится подход с логами, но сомнения еще остались.
 
Посоветуете чего-нибудь?
свернуть/развернуть ветвь Некоторые соображения [Дим(м) 24/04/2013 17:15] # написать ответ
 
Думаю, одними логами всё же не обойтись - сама база целиком тоже должна быть в облаке. Например, для сценария "запустил программу на новом устройстве".
 
Что касается использования логов для синхронизации, это, мне кажется, весьма широко используемая практика.
Возьмите те же (распределённые) системы контроля версий, например, журналируемые файловые системы или кластеры баз данных.
 
Каждую запись в такой лог можно дополнительно снабжать разнообразной мета-информацией. Например, о том, кто автор этого изменения, когда оно было внесено, на основании какой версии базы было сделано.
 
К сожалению, никакого практического опыта реализации подобных систем у меня нету. Так что с технической стороны я мало что смогу посоветовать.
 
Что касается вопросов
(а) конфликт, по сути, будет только в том случае, если изменения затрагивают одну и ту же запись и при этом не идентичны
 
решение в таком случае только одно - спросить у пользователя
все так делают: Windows при копировании, если файл уже существует, системы контроля версий предлагают откорректировать результат merge с помощью 3-way diff, разнообразные редакторы, если редактируемый файл был кем-то изменён на диске
 
думаю, будет вполне нормально, если AC будет показывать сообщение с конфликтными изменениями и спрашивать пользователя, каким должен быть итог
 
при этом, конечно, количество конфликтных ситуаций нужно минимизировать
например, было бы крайне неудобно считать конфликтом создание двух разных записей с одинаковым внутренним id
 
(б) изменения должны отправляться на сервер "поштучно" (это, кстати, позволит и синхронизацию сделать более real time)
тогда всё, что пришло на сервер, идёт "в работу" без каких-либо непоняток
с клиентской стороны тоже нужно хранить аналогичный лог "своих" изменений и удалять из него записи, когда от сервера пришло подтверждение получения
тогда после восстановления соединения клиент просто дошлёт изменения, которые не удалось доставить в прошлый раз
 
как вариант, могу попробовать предложить такую схему:
- в базе создаются триггеры на модификацию всех синхронизируемых таблиц и для каждого изменения в специальную таблицу сохраняется, что, где и как изменилось (например, в виде соответствующего SQL-запроса: "INSERT TO transactions (...) VALUES (...)")
(в общем-то, с помощью аналогичного подхода обычно делают UNDO - Undo/Redo in SQLite)
 
- специальный поток, ответственный за синхронизацию, периодически читает данные из этой таблицы и отправляет их на сервер
- когда сервер подтверждает получение, запись из таблицы удаляется
 
- на сервере каждой записи в логе присваивается уникальный инкрементальный номер или метка времени (см. также HTTP ETag)
- вместе с записью из лога клиенту всегда отправляется и эта метка
 
- ещё один поток на клиенте периодически опрашивает сервер: "были ли какие-то не мои изменения после метки Х?"
- и когда от сервера приходит какое-то обновление, применяет его к локальной базе без занесения в локальный лог изменений
- и запоминает у себя "последнюю успешную метку" для использования в следующем запросе
 
остаётся открытым вопрос удаления старых записей из лога на сервере
но сервер, по сути, знает всех своих клиентов "в лицо" и может хранить "последнюю использованную метку" для каждого из них
соответственно, записи в логе, более старые, чем самая старая метка клиентов, можно безболезненно удалять
 
м-м-м..
я вот только сейчас подумал, что этот сценарий требует использование "активного сервера"
а вы же, наверное, хотели бы использовать сервер только в качестве "разделяемого хранилища"...
(отсюда, кстати, вытекает и отличие в подходе ActiveSync - когда нету сервера-арбитра, нужна база целиком (?), чтобы самостоятельно провести анализ)
 
... но если присмотреться, то сервер тут всё же может быть "почти пассивным"
всё, что от него требуется - INSERT с auto_increment для колонки с меткой и SELECT с парой условий (чистку логов пока оставляем за рамками)
т.е. вполне подойдёт обычная БД
но с Dropbox, например, это всё равно не прокатит, да и в случае p2p придётся придумывать что-то другое..
свернуть/развернуть ветвь Активный сервер [Loki 25/04/2013 11:06] # написать ответ
 
кто-то должен установить и поддерживать. А еще он где-то должен быть расположен и неплохо бы худо-бедно следить за его безопасностью. В общем непонятно кто этим всем будет заниматься.
 
Что касается фоновой синхронизации, то лично у меня возникает вопрос с undo/redo  в данном случае:
1. ввел я некую операцию
2. в фоне прошла синхронизация с сервером, в результате которой что-то добавилось/изменилось в моей базе
3. я пытаюсь выполнить undo.
 
И вот тут для меня не очевидно что должно произойти: должна ли отмениться моя последняя операция? или должны отмениться результаты синхронизации? или должна отмениться последняя по времени операция (возможно, одна из загруженных).
 
Ну и еще момент: мне кажется было бы правильным, если бы лог выгружался на сервер только после сохранения БД.
свернуть/развернуть ветвь Я буду рад помочь [Maxim 02/05/2013 20:18] # написать ответ
 
В качестве администратора сервера (Linux, DB, C++/Java).
Программой пользуюсь давно, почему бы не помочь Well
 
MS сейчас в авральном порядке обновляет свои облачные сервисы и уже на данный момент их возможности как минимум не уступают Google. Разумеется, я говорю с точки зрения пользователя, как там обстоит дело с API я не интересовался. А популярный ранее DropBox скорее всего уступит место этим локомотивам.
 
...поинтересуюсь, как обстоят дела с этим у Майкрософта, но поддержку нескольких облачных сервисов обещать не буду. Каждый сервис, это лишние усилия по разработке и поддержке. Поэтому я ограничусь всего одним облаком. Ну еще, возможно, подумаю над синхронизацией просто по локальной сети специально для тех пользователей, кто не хотел бы выкладывать свою информацию на публичные сервера.
 
There must be only one. Well
свернуть/развернуть ветвь Вот-вот... [latan 24/04/2013 15:44] # написать ответ
 
"...специально для тех пользователей, кто не хотел бы выкладывать свою информацию на публичные сервера". Спасибо!
 
... на поддержке нескольких сервисов, просто DropBox, на мой взгляд, сейчас не лучший выбор. А так собсно пофиг - будет это GoogleDrive или SkyDrive. В пользу первого распространенность Android, а в пользу второго тесная интеграция с Windows и Office. Впрочем, для Android есть официальные клиенты SkyDrive и Outlook.com, так что сервис от MS выглядит универсальнее.
свернуть/развернуть ветвь А как же Линукс? (-) [Maxim 03/05/2013 10:41] # написать ответ
 
 
Из перечисленных сервисов клиент для Linux имеется только у Dropbox. Это надёжный и популярный сервис. Я думаю он будет наилучшим вариантом. Хотя если использовать Апи сервисов, то наличие клиента роли не играет.
Из популярных подобных сервисов есть ещё Box.com, странно что его никто не назвал. Он как раз специализируется на предоставлении своего Апи и интеграции со всевозможными сторонними приложениями/сервисами.
Наличие у пользователей аккаунта gmail.com преимущество сервису от Гугла не даёт, так как большинство популярных сервисов позволяют зарегистрироваться в один клин с помощью аккаунта того-же Гугла, Твиттера и прочих. Кроме того, у Гугла есть плохая привычка закрывать, казалось бы успешные, сервисы. Dropbox.com и Box.com мне кажутся в этом плане более надёжными.
 
У dropbox всегда хранится локальная копия файла её можно менять, а как только появится сеть сразу произойдет синхронизация с облаком, как с этим у google/skydrive?
 
 
рассмотрите в качестве центральной базы обычные почтовые сервера с доступом по протоколу IMAP. Протокол простой, с лёгкостью организуется многоуровневый формат хранения записей в виде дерева, т.к. IMAP поддерживает обычную древовидную структуру а-ля файловое хранилище. А записи в виде обычных текстовых писем в удобном формате: хоть читаемом хоть xml.
Удобство в том, что легко найти сервер и несложно написать протокол, уж отдельную папку для содержимого нужной программы любой пользователь легко вытерпит, особенно если для чтения и понимания содержимого ему не потребуется программа, т.е. он при желании сможет посмотреть что его интересует с мобилы даже без наличия клиента под данную платформу
свернуть/развернуть ветвь Экзотика. [Dervish 17/05/2013 10:17] # написать ответ
 
Даже и не знаю, с одной стороны, конечно, IMAP-сервер должен справиться с такой задачей... Но, с другой стороны, предназначение-то его совсем другое... Очень непривычна такая идея.
свернуть/развернуть ветвь Новая версия SQLite [Дим(м) 22/05/2013 12:37] # написать ответ
 
Вышла новая версия - 3.7.17 - в которой добавили возможность работы с базой через memory-mapped I/O.
Пишут, что это ускоряет скорость работы почти в два раза и снижает потребление памяти. Правда, не без ложки дёгтя.
Подробнее здесь - http://sqlite.org/mmap.html
 
...AbilityCash, она называлась просто Cash, использовала как раз memory-mapped files. Ох и нахлебался я тогда с этим. В общем, желание пользоватьсятакой возможностью у меня отбито напрочь. Well
 
Так что, мы уж как-нибудь обойдемся без этого. Well
свернуть/развернуть ветвь Оказывается, SQLite... [Дим(м) 24/05/2013 12:02] # написать ответ
 
... был разработан для использования в управляемых ракетах: http://en.wikipedia.org/wiki/SQLite#History
 
А ещё у него есть "братья":
модный нынче NoSQL вариант - UnQLite - http://unqlite.org/
и клон SQLightning, использующий другой движок БД (Lightning DB aka MDB) - пишут, что вставка 1000 записей на нём происходит в 20 раз быстрее - http://gitorious.org/mdb/sqlightning#more (а сама библиотека при этом стала на 50 КБ меньше)
 
У самого SQLite, кстати, более 2 миллионов (!) тестов, которые запускаются для проверки каждой новой версии - http://www.sqlite.org/testing.html
 
Американский сервис YNAB (ynab.com) сделал синхронизацию через Dropbox. Можно изучить их опыт...