Приложения шардинга SQL Azure и социальных сетей

Question

Концепция шардинга в SQL Azure - это один из лучших рекомендуемых вариантов преодоления предела размера БД 50 Гб, который он имеет на данный момент. Ключевой стратегией в шардинге является группирование связанных записей, называемых атомарными единицами, в один шард, так что приложению нужно запросить только один экземпляр SQL Azure для извлечения данных.

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

Кроме того, какие первичные ключи должны использоваться для таблиц в изолированной БД? Big Int или GUID. В настоящее время я использую столбцы BIGINT Identity, но если по какой-либо причине данные должны быть объединены, это будет проблемой из-за конфликтов между значениями в разных шардах. Я слышал, что некоторые люди рекомендуют GUID (UniqueIdentifier), но я опасаюсь того, как это может повлиять на производительность. Индексирование локальных серверов SQL со столбцами UniqueIdentifier невозможно, и мне интересно, как SQL Azure реализует аналогичные стратегии, если бы я использовал столбец UniqueIdentifier.

Answer 1

Для приложения для социальных сетей я бы предпочел отказаться от использования SQL и вместо этого использовать решение noSQL, такое как MongoDB или Azure Table Storage.Эти ненормализованные, но недорогие системы позволяют вам создавать несколько наборов данных сущностей, настроенных под ваши различные потребности в индексировании.

Так что вместо того, чтобы иметь что-то вроде ... User1 -

Вместо этого у вас есть таблицы, такие как Друзья пользователя User1 Друзья пользователя2

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

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