Замена существующей базы данных в ravendb/доказательство концепции

Мы планируем изменить нашу многопользовательскую систему заказов во внутренней сети.

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

Поэтому мы планируем использовать одну кэширующую базу данных на каждого арендатора, и мы провели первые тесты с RavenDB.

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

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

Возможен ли вообще наш подход? Кто-нибудь нашел хорошее решение в подобной ситуации?

Спасибо за помощь


person ms007    schedule 05.04.2012    source источник
comment
Мы делаем много подобных вещей, и у нас был потрясающий опыт работы с RavenDB. Однако я понятия не имею, о чем вы говорите. Каков ваш конкретный сценарий? Что вы подразумеваете под кэшированием БД, промежуточным хранилищем, многопользовательской системой заказа и т. д.?   -  person Daniel Lang    schedule 06.04.2012


Ответы (1)


MS007, Использование RavenDB в качестве постоянного хранилища модели представления очень распространено. Но я не понимаю, почему вы хотите обновлять базы данных RavenDB ежечасно. Было бы намного дешевле просто обновить измененные данные, и вам не нужно беспокоиться о том, что происходит в системе, пока вы удаляете базу данных и создаете новую.

person Ayende Rahien    schedule 06.04.2012