Какую стратегию лучше использовать в отношении производительности?Хеширование GUID или обращение к менеджеру горизонтального масштабирования? - PullRequest
0 голосов
/ 28 июня 2011

Мы создаем довольно громкий сайт, который, как ожидается, будет иметь 100 миллионов просмотров в первые дни запуска.Мой предшественник выступал за масштабную стратегию SQL с использованием одного сервера с 1 ТБ ОЗУ и 32 ядрами.Нам сообщили, что это неосуществимое решение.

В ответ я перешел к стратегии горизонтального масштабирования с несколькими серверами SQL и горизонтальным разделением.Мой вопрос вращается вокруг того, как я буду направлять DAL на соответствующий сервер базы данных.Будет много операций чтения и записи для каждого пользователя приложения.Сначала я подумал о том, чтобы использовать один сервер горизонтального масштабирования, который сохранял бы идентификатор профиля (GUID) каждого пользователя и возвращал строку соединения в шард этого пользователя.Это казалось чрезмерной нагрузкой и создало единую точку отказа.

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

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

НекоторыеОсобенности: Мы используем SQL 2008 R2 Enterprise на серверах БД.Каждый дБ будет иметь 64 ГБ оперативной памяти и 8 ядер.Базы данных будут находиться в общем хранилище.Vmotion будет использоваться, если сервер не работает.При запуске будет множество веб-серверов (30-40?), Но точное число будет зависеть от тестирования производительности.Приложение построено на .net 4.0 с Enterprise Library v5.Балансировка нагрузки веб-сервера будет обрабатываться Cisco ACE.Мы просили, чтобы каждый из серверов баз данных находился в отдельном экземпляре vsphere.

Спасибо!

1 Ответ

0 голосов
/ 28 июня 2011

Нужен ли какой-либо профиль пользователя для взаимодействия с другим профилем пользователя? Типичным примером может служить стена, например. где вы видите обновления статуса от всех ваших друзей. См. Масштабирование SQL Server с помощью надежного обмена сообщениями , чтобы понять, почему я спрашиваю об этом.

Что касается хеширования, хорошая схема хеширования может приспособить изменение в распределении (например, сегмент, принадлежащий машине A, разделен на два новых сегмента, теперь принадлежащих A и B) без изменений в приложении. Хеширование на уровне приложения не решает эту проблему, лучше иметь выделенного «менеджера горизонтального масштабирования», если вы создаете высокодоступный диспетчер горизонтального масштабирования и управляете количеством запросов, на которые он должен ответить (например, меньше, чем 1 на HTTP-запрос на внешнем уровне).

...