SQL Server - это PK на основе GUID, наилучшая практика для поддержки горизонтального разбиения на основе клиента

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

Некоторые грубые номера в базе данных ..

Общее количество арендаторов составит около 10000. Объем данных, хранящихся на одного арендатора, варьируется от 500 МБ до 3 ГБ. Число арендаторов начнется с малого и увеличится до 10000 в течение нескольких лет, поэтому изначально мы можем начать с одной базы данных с несколькими арендаторами, но в более долгосрочной перспективе это потребуется для горизонтального масштабирования в целях повышения производительности.

Обновление - усложняющим фактором является то, что иногда арендаторы (компании) могут объединяться, и я должен также поддержать это ...,

Мультитенантность будет реализована с использованием общей базы данных, архитектуры общей схемы, как описано в этом документе.http://msdn.microsoft.com/en-us/library/aa479086.aspx

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

Я знаю, что использование GUID приводит к снижению производительности, поскольку основной ключ - это компромисс, который мне просто нужно принять? Есть ли другой способ дизайна для горизонтального разделения в будущем?

Вот пример - допустим, я хочу объединить компании с арендаторами 100 и 200 в будущем, если PK является целым числом, может возникнуть коллизия, когда я копирую строки из базы данных 2 в базу данных 1, с {guids} я гарантирован не будет столкновения ...

база данных 1 база данных 2 tenantid, id, описание tenantid, id, описание 100, 1, 'foo' 200, 1, 'xxx' 100, 2, 'boo' 200, 2, 'yyy'

база данных 1 база данных 2 tenantid, id, описание tenantid, id, описание 100, {aaa}, 'foo' 200, {ccc}, 'xxx' 100, {bbb}, 'boo' 200, {ddd}, 'yyy'