Вопрос кеширования данных из базы на локальной машине

← →
Alek Arbuzov (2007-04-25 16:37) [0]

В базе данных хранятся тысячи записей, которые регулярно запрашиваются клиентами и относительно нечасто меняются. С целью ускорения процесса получения информации а также снижения сетевого траффика неплохо было бы иметь возможность сохранять данные на локальной машине каждого клиента. Синхронизация данных, точнее получение информации об изменениях за определенный период не представляет сложности, вопрос лишь в том, где и как хранить "закешированные" данные.
Возникла смелая идея установить на каждом клиенте локальную базу и держать данные в ней, при необходимости лишь обновляя ее. Подход, возможно, неоптимален, поскольку увеличит требования к локальным машинам.
Подскажите, пожалуйста, какие технологии можно использовать и насколько эта идея оптимальна. Возможно, кто-то уже имеет опыт подобных экспериментов..
(в качестве основной СУБД используем ORACLE, хотелось бы иметь максимальную совместимость)
Заранее благодарю всех неравнодушных :)

← →
zdm © (2007-04-25 16:42) [1]

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

извини, но звучит бредово. Рильный и стандартный выход- не открывать всю таблицу сразу, а открывать их на определенное кол-во записей, например 100

← →
Jan1 (2007-04-25 16:44) [2]

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

они реально нужны клиенту? клиенты удаленно расположены?

← →
Gadenysh (2007-04-25 16:45) [3]

в памяти

← →
Desdechado © (2007-04-25 16:50) [4]

3-звенка. Кэширующий долгоиграющий сервер приложений.

← →
Виталий Панасенко © (2007-04-25 16:51) [5]

Использовать ClientDataSet... Позволяет реализовать ВСЕ из вопроса автора...

← →
Jan1 (2007-04-25 16:58) [6]

> Синхронизация данных, точнее получение информации об изменениях
> за определенный период не представляет сложности,

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

← →
zdm © (2007-04-25 17:01) [7]

> Виталий Панасенко © (25.04.07 16:51) [5]

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

...where rownum <= 100 , по моему так должно выглядить

← →
Виталий Панасенко © (2007-04-25 17:10) [8]

> zdm © (25.04.07 17:01) [7]

Полностью согласен. Но автор просил советы по реализации локальной БД... С возможностью отключения/подключения к удаленной БД.. Все это реализует CDS. Ну, сделал человек так.. Или начал уже так делать, много сотворил..

← →
zdm © (2007-04-25 17:13) [9]

> Виталий Панасенко © (25.04.07 17:10) [8]

а автор, по моему, совсем интерес потерял :)

← →
Alek Arbuzov (2007-04-25 17:48) [10]

2 zdm:
>"Рильный и стандартный выход- не открывать всю таблицу сразу, а открывать их на определенное кол-во записей, например 100"
согласен, так и делаем. Фактически клиенты запрашивают информацию за определенный период (неделя, месяц..)
Поначалу наугад попробовал написать компонент, который умеет сохранять данные на диск в виде файлов. Возникла проблема фильтрации данных на локальной машине, да и механизмы работы с данными на уровне файлов это неэффективно..
Потому возникла идея локальной базы.
2 Jan1: клиенты - локальная сеть. Но думает о работе через интернет, поэтому нужны механизмы снижения траффика. Опять же, не гонять то, что было выбрано раньше и не изменилось.

← →
Jan1 (2007-04-25 18:00) [11]

> Alek Arbuzov (25.04.07 17:48) [10]

чувтсвую что без репликации вам не обойтись. С Ораклом не сильно знаком, но кажеться у них уже встроена она на уровне сервака. Может даже офф-лайн репликация есть.

← →
Alek Arbuzov (2007-04-25 18:04) [12]

2 jan1:

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

об офф-лайн работе пока речь не идет, нужны механизмы, которые бы позволили делать запросы из локальных ресурсов (что автоматически влечет за собой их
синхронизацию). Вносить изменения без связи с базой невозможно

← →
Jan1 (2007-04-25 18:11) [13]

Я так понимаю Вам нужен локальная база не для всех данных а для справочников? Наверное Вам можно попробовать снап-шот репликацию именно этих справочников. Кажется такая должна быть в Оракле, в МС есть. При этой репликации данные как правило передаются из центральной точки - в Вашем случае сервер, где хранятся справочные даннные. И Вам нужно будет в программе учесть, что для таких данных, лезем с локальную базу, а если такое-то - то в базу на сервер.

← →
Alek Arbuzov (2007-04-25 18:15) [14]

2 Jan1: идею поняли правильно. Про снап-шот"ы почитаю. Спасибо

← →
ANB © (2007-04-25 18:30) [15]

> Alek Arbuzov (25.04.07 18:15) [14]
> 2 Jan1: идею поняли правильно. Про снап-шот"ы почитаю. Спасибо

Не читай. Уже попробовали - граблей немерянно, ставить тяжело, ломается мухой и тяжело чиниться.
Только что обкатали решение :
Сервера на каждую машину (XE оптимальненько). Данные прокачивать триггерами. В случае рассинхронизации локальной БД с основной сделать процедуру полной закачки данных (применив логирование недоехавших изменений можно сделать и частичную закачку)

← →
ANB © (2007-04-25 18:31) [16]

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

← →
Alek Arbuzov (2007-04-25 18:46) [17]

> Только что обкатали решение :
> Сервера на каждую машину...

А что использовали в качестве СУБД на локальных машинах? И какие требования к ним получились в итоге?

← →
ANB © (2007-04-25 19:08) [18]

> А что использовали в качестве СУБД на локальных машинах?
> И какие требования к ним получились в итоге?

Не, мы 2 сервера связали.
Но я ставил XE на рабочую лошадку - проблем особых не возникает. Целерон 1600 тянул без проблем. Диски по любому наращивать, если хотите локально базу держать. А памяти вот желательно очень гектарчик, а то тормозить будет.

Кстати, у нас у одного клиента база 160 террабайтиков, более тысячи одновременных пользователей и никаких проблем с траффиком и сервером, хотя работают как обычные клиенты и даже есть избыточность обращения к серверу.
Так что есть ли смысл огород городить ?

> [0] Alek Arbuzov (25.04.07 16:37)
> в качестве основной СУБД используем ORACLE

> [10] Alek Arbuzov (25.04.07 17:48)
> клиенты - локальная сеть.

Забей на все свои идеи и оптимизируй программу.

← →
Jan1 (2007-04-26 10:12) [20]

> Не читай. Уже попробовали - граблей немерянно, ставить тяжело,
> ломается мухой и тяжело чиниться.

Может вы е готовить не умеете?

> Сервера на каждую машину (XE оптимальненько). Данные прокачивать
> триггерами. В случае рассинхронизации локальной БД с основной
> сделать процедуру полной закачки данных (применив логирование
> недоехавших изменений можно сделать и частичную закачку)

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

Уверен что у Оракла есть синхронизация снап-шот репликации через веб сервисы как в МС. и тогда автору подойдет, если они захотят через инет синхронизироваться...

> Уверен что у Оракла есть синхронизация снап-шот репликации
> через веб сервисы как в МС.

Нету. При неустойчивой связи вообще штатная репликация ложиться.
Более того, если в запрос снапшота входит более одной таблицы в любых вариантах, оракл автоматом отключает FAST режим, а это значит, что при обновлениях будет перекачиваться вся выборка, а не дельта. По мне уж лучше толкать каждый ДМЛ между серверами, чем укладывать оба при обновлении данных. Да и разрешение конфликтов - только апдейт пишеться просто, все прочие - надо писать довольно много кода на каждую реплицируемую таблицу.
Первое же тестирование (конфликты не разрулили) создало конфликт, попытка его зачистить привела к разрушению БД (пришлось чистить ручками сисовые таблицы). Может мы, конечно, не так что то чистили, но делали это штатными механизмами.

← →
Alek Arbuzov (2007-04-26 10:25) [22]

Спасибо всем
Хотел бы уточнить, что жалоб на траффик и производительность у нас пока не возникает, это просто идея дальнейшего развития. Ну, вроде как дополнительная фича.Просто в свое время неудачно потратили время (читай выше), жаль теперь идею бросать...
Про ORACLE Express тоже думали. Еще знакомые посоветовали в сторону Berkley DB посмотреть. Может, кто-нибудь уже имел с ней дело, интересно было бы выслушать мнения..

← →
Jan1 (2007-04-26 10:55) [23]

> Нету. При неустойчивой связи вообще штатная репликация ложиться.
>
> Более того, если в запрос снапшота входит более одной таблицы
> в любых вариантах, оракл автоматом отключает FAST режим,
> а это значит, что при обновлениях будет перекачиваться
> вся выборка, а не дельта. По мне уж лучше толкать каждый
> ДМЛ между серверами, чем укладывать оба при обновлении данных.
> Да и разрешение конфликтов - только апдейт пишеться просто,
> все прочие - надо писать довольно много кода на каждую
> реплицируемую таблицу.
> Первое же тестирование (конфликты не разрулили) создало
> конфликт, попытка его зачистить привела к разрушению БД
> (пришлось чистить ручками сисовые таблицы). Может мы, конечно,
> не так что то чистили, но делали это штатными механизмами.
>

странно все это как-то. Оракл всегда позиционировался как надежная СУБД с надежными механизмами. В МС настройка и управление репликацией на уровне клика мишкой... При неустойчивой связи есть докачка репликации - правда это в 2005, а не 2000.

> Оракл всегда позиционировался как надежная СУБД с надежными
> механизмами.

:)
Хоть МС СКЛ и рядом с ораклом не стоял по удобству и возможностям для программиста, оракл хоть позиционируется менеджерами в таком ключе, но с одной оговоркой - если не лазить в ненадежные механизмы. К сожалению, довольно много фич оракла никто не юзаюет именно из-за их ненадежности. Впрочем, надежных и удобных фич тоже хватает.
Для иллюстрации моих слов достаточно сходить на металинк и посмотреть список найденных ошибок и патчей.

К сожалению, оракл переувлекся оутсорсингом в индии.

>zdm © (25.04.07 16:42) [1]
>> Возникла смелая идея установить на каждом клиенте локальную
>> базу и держать данные в ней, при необходимости лишь обновляя
>> ее.
>извини, но звучит бредово.

Ничего бредового нет. Как пример - корпорация, где масса слабых компов, к тому же не подключенных из-за соображений безопасности к локальной сети напрямую. Сервер "комнатного" формата, общающийся с SQL-сервером, к которому подключены "отключенные" клиенты - одно из решений.
Своего рода "прокси"-решение, но для БД.

>zdm © (25.04.07 17:01) [7]
>ClientDataSet- конечно хорошо, но опять-же, очень круто напрягает клиентскую машину

Еще один бред. Идущий, вероятно, либо от неопытности, либо от криворукости

ЗЫ. Вот не совсем понятно, желание посоветовать лишь бы посоветовать чем диктуется ?

Вопрос кеширования данных из базы на локальной машине Найти похожие ветки