Создать базу данных для масштабируемости

Question

Как мне создать базу данных для масштабируемости? Я нахожусь в середине http://www.slideshare.net/vishnu/livejournals-backend-a-history-of-scaling, который я не могу прочитать банкомат, и мне нужно уйти. Но я хотел бы узнать больше о создании базы данных, которая хорошо масштабируется. Нечто упомянутое и происходящее в моем сознании

• Отдельные дескрипторы для чтения и записи?
• Что происходит, когда один сервер занят (связан с IO или CPU) и мне нужно два сервера для записи?
• Могу ли я создать несколько баз данных? есть идентификатор кластера для пользователей?
• Будет ли проблема при перемещении пользователей из одного кластера в другой?
• Могу ли я кодировать это так, чтобы пользовательские ABC в БД A в кластере A и DEF в БД B в кластере B имели одинаковый ПЕРВИЧНЫЙ КЛЮЧ?
• Когда я перенесу вышеуказанное в кластер C? Означает ли это, что мне нужно написать много кода, чтобы переместить их в другой кластер / базу данных?
• Чтобы вышеописанное не было проблемой, я бы НЕ использовал PRIMARY KEY и устанавливал идентификатор вручную, читая другие БД в других кластерах?

и т.д. * * тысяча двадцать-одна

Answer 1

Чтобы создать базу данных, которая хорошо масштабируется для 99,9% случаев использования, не связывайтесь ни с чем из этого. Вместо этого спроектируйте правильно нормализованную схему; использовать первичный, внешний ключ и другие ограничения для обеспечения целостности; индексные таблицы хорошо. Изучите рекомендации поставщика СУБД по таким темам, как производительность и масштабируемость, такие как разбиение разделов, различные структуры таблиц и индексов и т. Д., И используйте то, что лучше всего подходит для вашего случая (варианты тестирования, чтобы доказать, что они улучшают масштабируемость).

Конечно, если вы работаете в Google, Ebay или Amazon, вы можете попасть в лагерь на 0,1%, который должен выбросить книгу правил и сделать все эти сумасшедшие вещи, о которых вы читаете. Но я предполагаю, что нет, верно?

Answer 2

СУБД отлично подходят для хранения непротиворечивых и транзакционных данных, но требуют большого экспертного планирования для масштабирования до сотен тысяч транзакций в секунду. Я хотел бы создать облако nosql для размещения документов, созданных из RDBMS.

Таким образом, вы используете RDBMS для необработанных данных и базы данных nosql для представлений в RDBMS '

Answer 3

Что происходит, когда один сервер занят (связан с IO или CPU) и мне нужно два сервера для записи?

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

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

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

Будет ли проблема при перемещении пользователей из одного кластера в другой?

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

Могу ли я кодировать это так, чтобы пользовательский ABC в БД A в кластере A и DEF в БД B в кластере B имели одинаковый ПЕРВИЧНЫЙ КЛЮЧ?

Нет, назначьте первичный ключ на главном сервере RDBMS / LDAP. Вы не хотите столкновения первичного ключа такого рода. Выбранный вами метод зависит от того, будет ли это сделано правильно - вам нужны глобально уникальные идентификаторы пользователей. В этом случае у вас будут общие данные, и если у вас нет GU-PK, как вы будете связывать пользователя с общими данными?

Answer 4

Чтобы добавить к совету Тони, я бы сказал, что правильно разделите ваши базы данных на каталоги (термин SQL Server для пространства имен виртуальных баз данных на физическом сервере баз данных) и попытайтесь минимизировать зависимости между каталогами, то есть запрос уровень зависимости. Если есть зависимости, убедитесь, что они доступны только для чтения.

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

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

Советы по репликации действительно полезны для наихудшего сценария и только для одного раза. Это не решение для специального роста базы данных. Вы должны отойти от RDBMS, если вам когда-либо придется расти таким образом. При правильной репликации моделей данных возможно свободное перемещение каталога