В ближайшее время будет существовать приложение, которое написано в виде двух-звенки (первая версия) — MS SQL 2008 и C#.
Необходимо реализовать работу с локальными актуальными данными (из удаленной БД).
Что я пока придумал: после выполнения любого действия с данными происходит синхронизация БД в новом процессе, и такая же синхронизация по таймеру скажем раз в секунду (но синхронизация умная – только для задействованных "справочников на форме – данных из этих справочников").
Т.к. в локальной версии БД нам не обязательно хранить старые данные, то мы синхронизируем только актуальные – не старше текущей даты и времени. После происхождения события – время наступило, данные удаляются в новом процессе. В случае если нам потребовались старые данные, делается запрос старых данных из удаленной БД.
Толкните идею? Логичны ли такие действия? Что можно еще придумать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Ortrix, Вы писали:
O>>Толкните идею? Логичны ли такие действия? Что можно еще придумать?
W>Все зависит от бизнес-требований. Они могут быть разными для разных данных и действий. W>Проще всего IMHO просто синхронизация раз в сутки или в час.
Nein — я же указал, что очень актуально на клиенте иметь всегда новые данные.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[3]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, Ortrix, Вы писали:
W>>Все зависит от бизнес-требований. Они могут быть разными для разных данных и действий. W>>Проще всего IMHO просто синхронизация раз в сутки или в час.
O>Nein — я же указал, что очень актуально на клиенте иметь всегда новые данные.
А какой примерно обьем данных для синхронизации? Если 1-2К — приемлемо. Если 1-2Мб — уже получишь затык в плане быстродействия/нагрузки на сетку.
Кстати, чем оправдана такая частая синхронизация и зачем вообще она нужна, если при обычной работе клиента он и так получает самые последние данные из основной БД (если медленные каналы — смотри выше).
WBR, Dmitry Beloshistov AKA [-=BDS=-]
Re[3]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, Ortrix, Вы писали:
W>>Все зависит от бизнес-требований. Они могут быть разными для разных данных и действий. W>>Проще всего IMHO просто синхронизация раз в сутки или в час.
O>Nein — я же указал, что очень актуально на клиенте иметь всегда новые данные.
Что, именно все и всегда? И показ клиенту значения, которое было инменено в БД миллисекунду назад, грозит миллионными убытками? Не верю.
Проведи анализ, не ленись. Распредели данные и действия с ними по "категориям актуальности", сформулируй четкие требования, выраженные количественно. Тогда и решение начнет вырисовываться, можно будет предлагать конкретные алгоритмы и технологии.
Re[4]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, DarkMaster, Вы писали:
DM>Здравствуйте, Ortrix, Вы писали:
W>>>Все зависит от бизнес-требований. Они могут быть разными для разных данных и действий. W>>>Проще всего IMHO просто синхронизация раз в сутки или в час.
O>>Nein — я же указал, что очень актуально на клиенте иметь всегда новые данные.
DM>А какой примерно обьем данных для синхронизации? Если 1-2К — приемлемо. Если 1-2Мб — уже получишь затык в плане быстродействия/нагрузки на сетку. DM>Кстати, чем оправдана такая частая синхронизация и зачем вообще она нужна, если при обычной работе клиента он и так получает самые последние данные из основной БД (если медленные каналы — смотри выше).
До 10 пользователей в офисе. 4 пользователя работают в режиме пришел, ушел(клиент) – 20-30 сек на клиента(2-3) клиента в минуту.
До 1000 онлайн (100 работают как клиенты) в минуту – 4000 запросов на выборку в минуту. 800 -1000 на изменение и 1000 на вставку. Онлайн работает с теме же данными, что и 4 в офисе.
Вот такая нагрузка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[4]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Ortrix, Вы писали:
W>>>Все зависит от бизнес-требований. Они могут быть разными для разных данных и действий. W>>>Проще всего IMHO просто синхронизация раз в сутки или в час.
O>>Nein — я же указал, что очень актуально на клиенте иметь всегда новые данные.
W>Что, именно все и всегда? И показ клиенту значения, которое было инменено в БД миллисекунду назад, грозит миллионными убытками? Не верю.
W>Проведи анализ, не ленись. Распредели данные и действия с ними по "категориям актуальности", сформулируй четкие требования, выраженные количественно. Тогда и решение начнет вырисовываться, можно будет предлагать конкретные алгоритмы и технологии.
До 10 пользователей в офисе. 4 пользователя работают в режиме пришел, ушел(клиент) – 20-30 сек на клиента(2-3) клиента в минуту.
До 1000 онлайн (100 работают как клиенты) в минуту – 4000 запросов на выборку в минуту. 800 -1000 на изменение и 1000 на вставку. Онлайн работает с теме же данными, что и 4 в офисе.
Вот такая нагрузка.
Как и написал выше.
Миллионными, не миллионными – но неприятностями да, и тем что клиент больше не придет. А это до 50.000 потенциальных клиентов ежедневно, из них 10.000 где-то уходят в обслуживание. С одного клиента 5(2000 клиентов) – 200(1000 клиентов) (остальные в промежутке.)$ для онлайн сервиса. И до 12.000-15.000 за сутки в офисе(уже непосредственно клиентов)- ну это максимальная нагрузка (есть места где меньше).
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, Ortrix, Вы писали:
O>В общем, вернусь к старым баранам.
O>Покритикуйте идею:
O>В ближайшее время будет существовать приложение, которое написано в виде двух-звенки (первая версия) — MS SQL 2008 и C#.
O>Необходимо реализовать работу с локальными актуальными данными (из удаленной БД).
O>Что я пока придумал: после выполнения любого действия с данными происходит синхронизация БД в новом процессе, и такая же синхронизация по таймеру скажем раз в секунду (но синхронизация умная – только для задействованных "справочников на форме – данных из этих справочников").
O>Т.к. в локальной версии БД нам не обязательно хранить старые данные, то мы синхронизируем только актуальные – не старше текущей даты и времени. После происхождения события – время наступило, данные удаляются в новом процессе. В случае если нам потребовались старые данные, делается запрос старых данных из удаленной БД.
O>Толкните идею? Логичны ли такие действия? Что можно еще придумать?
Нашел идею у клинта будет Rest-сервис, на базе ADO.NET Data Services. А у нас будет ASP.NET приложение Там, мы легко сможем оперировать ошибками в ответе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[5]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, Ortrix, Вы писали:
O>Миллионными, не миллионными – но неприятностями да, и тем что клиент больше не придет. А это до 50.000 потенциальных клиентов ежедневно, из них 10.000 где-то уходят в обслуживание. С одного клиента 5(2000 клиентов) – 200(1000 клиентов) (остальные в промежутке.)$ для онлайн сервиса. И до 12.000-15.000 за сутки в офисе(уже непосредственно клиентов)- ну это максимальная нагрузка (есть места где меньше).
Цифры не совсем понял, но раз все так серьезно, зачем вам вообще локальные данные? Работайте только с базой. Не напрямую конечно, через серверное приложение. То есть получается уже трехзвенка.
Re[6]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Ortrix, Вы писали:
O>>Миллионными, не миллионными – но неприятностями да, и тем что клиент больше не придет. А это до 50.000 потенциальных клиентов ежедневно, из них 10.000 где-то уходят в обслуживание. С одного клиента 5(2000 клиентов) – 200(1000 клиентов) (остальные в промежутке.)$ для онлайн сервиса. И до 12.000-15.000 за сутки в офисе(уже непосредственно клиентов)- ну это максимальная нагрузка (есть места где меньше).
W>Цифры не совсем понял, но раз все так серьезно, зачем вам вообще локальные данные? Работайте только с базой. Не напрямую конечно, через серверное приложение. То есть получается уже трехзвенка.
Ну ты говарил что мол миллионы убытков но 100к$ в день может возникнуть недополученного оборото и где-то от 10 до 36 прибыли.
Дело в том, что если хранить базу на сервере полностью удаленно... Могут быть проблемы с интернетом, а приоритет у оффиса. Поэтому и умная синхронизация(репликация).
Да и если что-то ляжет не в офисе, то это будет большая проблема.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[7]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, Ortrix, Вы писали:
W>>Цифры не совсем понял, но раз все так серьезно, зачем вам вообще локальные данные? Работайте только с базой. Не напрямую конечно, через серверное приложение. То есть получается уже трехзвенка. O>Ну ты говарил что мол миллионы убытков но 100к$ в день может возникнуть недополученного оборото и где-то от 10 до 36 прибыли.
O>Дело в том, что если хранить базу на сервере полностью удаленно... Могут быть проблемы с интернетом, а приоритет у оффиса. Поэтому и умная синхронизация(репликация).
Нет, это ты говоришь (подтверждаешь мое описание), что если клиент проведет операцию на основе данных, устаревших всего на миллисекунду, это уже убыток великий. Если это так, то единственный выход — работать с гарантированно актуальными данными, то есть прямо с сервера. Да еще и пессимистичную блокировку на них накладывать.
Либо приводи реальные требования.
P.S. 10% прибыли с оборота за день — это что ж за бизнес такой? Не прием платежей случайно?
Re[8]: [Репликатор]: Идея Update, Insert, Select, Delete
Здравствуйте, wildwind, Вы писали:
W>Нет, это ты говоришь (подтверждаешь мое описание), что если клиент проведет операцию на основе данных, устаревших всего на миллисекунду, это уже убыток великий. Если это так, то единственный выход — работать с гарантированно актуальными данными, то есть прямо с сервера. Да еще и пессимистичную блокировку на них накладывать. W>Либо приводи реальные требования.
W>P.S. 10% прибыли с оборота за день — это что ж за бизнес такой? Не прием платежей случайно?
Maybe Прекрощаем офтопить.
Там, мы легко сможем оперировать ошибками в ответе.
но 100к$ в день может возникнуть недополученного оборото и где-то от 10 до 36 прибыли.
Не прием платежей случайно?
