Как мне реализовать отдельные базы данных для операций чтения и записи? - PullRequest
28 голосов
/ 26 мая 2010

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

1. Что было бы хорошим ресурсом, чтобы узнать больше об этой архитектуре?
2. Это просто вопрос репликации между двумя одинаковыми схемами, или ваши схемы будут отличаться в зависимости от операций, нормализация тоже будет меняться?
3. Как вы гарантируете, что данные, записанные в одну базу данных, сразу же доступны для чтения из второй?


Любая дальнейшая помощь, советы, ресурсы будут оценены. Спасибо.

EDIT
После некоторых исследований я нашел эту статью, которая я нашел очень информативной для тех, кто заинтересован ..

http://www.codefutures.com/database-sharding/

Я нашел этот масштабируемый статья очень информативным

Ответы [ 3 ]

18 голосов
/ 26 мая 2010

Я не специалист, но база данных master для чтения и записи и ведомые устройства только для чтения - это «общий» шаблон, особенно для больших приложений, выполняющих в основном операции чтения или хранилища данных:

  • позволяет масштабировать (при необходимости вы добавляете больше ведомых устройств только для чтения)
  • позволяет по-разному настраивать базы данных (для эффективного чтения или эффективной записи)

Каким будет хороший ресурс, чтобы узнать больше об этой архитектуре?

В Интернете имеются хорошие ресурсы. Например:

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

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

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

Полагаю, вам понадобится синхронная репликация для этого (что, конечно, медленнее, чем асинхронная). Хотя некоторые базы данных поддерживают этот режим, не все поддерживают AFAIK. Но взгляните на этот ответ или этот для SQL Server.

3 голосов
/ 26 мая 2010

Вы можете посмотреть хранилища данных.Они служат базой данных типа «нормализовано для отчетности», в то время как вы можете сохранить нормализованный экземпляр стиля OLTP для обслуживания данных.

Не думаю, что идея «немедленной» эквивалентности будет реальностью.Будет некоторая задержка, пока новые данные и изменения переносятся в другую систему.График и объем будут ваши важные решения здесь.

1 голос
/ 26 мая 2010

По вопросам 2:

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

Я работал в подобных системах, где была бы база данных для чтения / записи, которая использовалась бы только администраторами. Затем эта база данных будет реплицирована в базу данных только для чтения во время ночного процесса.

Вопрос 3: Как быстро мы говорим здесь? Меньше секунды? 10 секунд? Минуты

...