2009-02-26 3 views
0

Я немного ознакомился с базами данных ReadOnly.Запрос на ввод в базу данных Readonly?

Поэтому я задавался вопросом, будет ли какая-либо польза в наличии базы данных readonly, используемой в основном для чтения и запроса данных, а отдельная база данных записи, используемая для всей работы CRUD, когда база данных записи не использует блокировку.

+0

Не могли бы вы пояснить свой вопрос немного, пожалуйста? Будут ли эти базы данных иметь одни и те же данные, синхронизированные в какой-то момент, какова взаимосвязь между ними? –

ответ

3

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

Edit: В реальном мире, например, несколько лет назад у моего клиента они имели трудное время получить полезный AdHoc отчеты из их производственной базы данных (SQL Server), работающий на очень мощную машину, которая стоит вверх $ 50,000 только для оборудования.

Я говорил им о создании базы данных только для чтения с де-нормированными данными r/o и установке SQL-сервера, работающего на настольном компьютере (стоимостью около 2500 долларов США для аппаратного обеспечения) и 2500 долларов США настольный ПК сдул на величину 10X производительность массивного процессора обработки процессоров compaq с кусками ram и gobs диска, пытаясь обслуживать OLTP, пакетную обработку и отчетность.

Излишне говорить, что пользователи были очень счастливы и, несмотря на первоначальное сопротивление ИТ-специалистов, в конце концов, освободили ценные циклы на «производственной» машине, а модель была эмулирована в другом месте.

0

Преимущества базы данных readonly ясны: нет блокировки таблицы, никто не меняет данные, пока вы пытаетесь ее прочитать.

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

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

0

Я не думаю, что есть большая польза от базы данных Relational.

Возможно, то, о чем вы думаете, это OLAP, где данные сильно декомпозируются в многомерные матрицы. Посмотрите на службы анализа SQL-запросов.

0

Если ваше приложение ограничивает выполняемые SQL-запросы к базе данных с помощью известных хранимых процедур, отчетов и т. Д., Не беспокойтесь о копии только для чтения. В конце концов, база данных предназначена для одновременного чтения, записи и обновления. В конце концов, вы проверите свою систему и убедитесь, что ваши запросы SELECT не блокируют таблицы, чтобы другие пользователи не могли вставлять INSERT/UPDATE/DELETE.

Однако, если вы предоставляете ах hoc-метод доступа к данным (то есть MS Access со связанными таблицами), то вы определенно хотите иметь базу данных только для чтения. В противном случае пользователи могли бы писать специальные запросы, такие как SELECT * FROM TheBiggestTableEveryoneUses, потенциально создавая взаимоблокировки с другими пользователями, пытающимися записывать INSERT/UPDATE/DELETE в эту таблицу.

0

Это архитектурный вопрос и входит в планирование ресурсов.

  • Вы должны планировать свой груз HTTP/SQL вызова/транзакции
  • определить, сколько хитов вам нужно, кто ваша аудитория
  • Сколько одновременного БД SQL хитов
  • Caching
  • SQL модели параллельности
  • и каков уровень стресса

S о архитектуре вы определяете, что известно как транзакционной базы данных и базы данных отчетов When to build a separate reporting database?

Так что я работал в отделе образования и мы имеем 100TB данные 5 миллиардов студентов учителей родителей и т.д. Таким образом, мы сделали SQL Кластеризация и репликация. Таким образом, наши данные реплицируются каждые 5 минут, а из реплицированной базы данных мы запускаем ежемесячную еженедельную и тонну отчетов без ущерба для нашей транзакции db. Опять же, если ваша компания не может позволить себе несколько баз данных, вы можете сделать это в одном и том же банке. Как и в случае с компаниями-автозаводами. Если аудитория не критична, просто сохраните $$ LOL Это вопрос $$$, вам нужно построить свою инфраструктуру. Как кто-то уже почему это необходимо 1. Когда производительность транзакции имеет решающее значение. 2. Когда трудно получить окно обслуживания транзакционного приложения. 3. Если отчетность должна сопоставлять результаты не только с этим приложением, но и с другими силосами приложений. 4. Если отчеты должны поддерживать тренды или другие типы отчетов, которые лучше всего подходят для среды звездочки/среды бизнес-аналитики. 5. Если отчеты работают долго. 6. Если транзакционное приложение находится на дорогостоящем аппаратном ресурсе (кластер, мейнфрейм и т. Д.) 7. Если вам нужно выполнить операции очистки данных/извлечения-преобразования-нагрузки транзакционных данных (например, имена состояний в каноническом состоянии аббревиатуры).

Смежные вопросы