Applications SQL Sharding et réseautage social SQL

Question

Le concept d'ombrage sur SQL azure est l'une des meilleures options recommandées pour dépasser la limite de taille de base de données de 50 Go, pour l'instant. Une stratégie clé dans le sharding consiste à regrouper les enregistrements associés appelés unités atomiques dans un seul fragment, de sorte que l'application doit uniquement interroger une seule instance SQL azure pour récupérer les données.

Toutefois, dans des applications telles que les applications de réseaux sociaux, le regroupement d'une unité atomique dans un même fragment n'est pas trivial, en raison de l'interconnexion des entités et des enregistrements. Quelle pourrait être une approche recommandée basée sur un tel scénario?

Dans une base de données partitionnée, quelles clés primaires doivent être utilisées pour les tables? Big Int ou GUID. J'utilise actuellement des colonnes d'identité BIGINT, mais si les données devaient être fusionnées pour une raison quelconque, cela serait un problème en raison des conflits entre les valeurs dans différents fragments. J'ai entendu certaines personnes recommander des GUID (UniqueIdentifier), mais je me méfie de la façon dont cela pourrait affecter les performances. L'indexation de serveurs SQL sur site avec des colonnes UniqueIdentifier n'est pas possible, et je me demande comment SQL azure implémente des stratégies similaires si je devais employer une colonne UniqueIdentifier.

Answer 1

Pour une application de réseau social, je préfèrerais renoncer à utiliser SQL et utiliser plutôt une solution noSQL telle que MongoDB ou Azure Table Storage. Ces systèmes non normalisés mais coûteux vous permettent de créer plusieurs ensembles de données d'entités personnalisés selon vos différents besoins d'indexation.

Ainsi, au lieu d'avoir quelque chose comme ... Utilisateur1 - < relationshiptable - < Utilisateur2

Vous auriez plutôt avez des tables comme utilisateurs de User1 Amis User2 Amis

Si les utilisateurs 1 et 2 sont les deux amis, alors vous auriez deux entrées pour définir cette relation, pas une. Mais si rend la récupération d'une liste d'amis d'un utilisateur spécifique trivial. Il vous permet également d'exécuter des tâches en parallèle, en recherchant plusieurs tables d'index à la fois.

Ce processus s'adapte extrêmement bien, mais nécessite que vous investissiez plus de temps dans la façon dont les relations sont maintenues. Certes, c'est un exemple simplex. Les choses deviennent beaucoup plus complexes lorsque vous commencez à discuter de tâches comme la recherche dans l'ensemble de votre base d'utilisateurs.