Только для чтения запросов к базе данных?

Question

Я немного прочитал о базах данных ReadOnly.

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

Answer 1

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

Редактировать: Как пример из реальной жизни, несколько лет назад на одном из моих клиентов им было трудно получать полезные отчеты adhoc из своей производственной базы данных (SQL Server), работая на очень мощной машине, которая Стоимость аппаратного обеспечения превышает 50 000 долларов США.

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

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

Answer 2

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

• Вы должны спланировать загрузку http / SQL-вызовов / транзакций
• определите, сколько хитов вам нужно, кто ваша аудитория
• Сколько одновременных обращений sql db
• Кэширование
• Модель параллелизма SQL
• и что такое уровень стресса

Итак, архитектура, которую вы определяете, называется База данных транзакций и база данных отчетов Когда создавать отдельную базу данных отчетов?

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

Answer 3

Если ваше приложение ограничивает выполнение операторов SQL для базы данных с помощью известных хранимых процедур, отчетов и т. Д., Не беспокойтесь о доступной только для чтения копии. Ведь база данных предназначена для одновременного чтения, записи и обновления. В конце концов, вы протестируете свою систему и убедитесь, что ваши запросы SELECT не блокируют таблицы, чтобы другие пользователи не могли ВСТАВИТЬ / ОБНОВИТЬ / УДАЛИТЬ.

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

Answer 4

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

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

Answer 5

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

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

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