Ne stockez pas les données de plusieurs clients dans la même base de données - j'ai connu des entreprises qui ont dû passer beaucoup de temps / effort / argent à corriger cette erreur. J'ai même connu des clients refusant de partager un ordinateur de base de données même si les bases de données sont séparées - du côté positif, ces clients sont généralement prêts à payer pour le matériel supplémentaire.
-
Les problèmes liés à la sécurité seule devraient vous empêcher de faire cela. Vous perdrez de gros clients à cause de cela.
-
Si vous avez des clients qui refusent de mettre à jour leur logiciel, cela peut être très difficile si vous partagez une seule base de données. Des bases de données séparées permettent aux clients de continuer à utiliser l'ancienne structure de base de données jusqu'à ce qu'ils soient prêts à mettre à jour.
-
Vous limitez artificiellement une partition de données naturelle qui pourrait offrir une évolutivité significative à votre solution. De petits clients multiples peuvent toujours partager un serveur de base de données, ils voient simplement leurs propres bases de données/catalogues, ou ils peuvent fonctionner sur des serveurs/instances de base de données séparés.
-
Vous compliquez la conception de votre base de données car vous devrez distinguer les données des clients qui seraient autrement naturellement séparées, c'est-à-dire devoir fournir CustomerID sur chaque clause where.
-
Vous ralentissez votre base de données en raison de plus de lignes dans toutes les tables. Vous utiliserez la mémoire de la base de données plus rapidement car CustomerID fait maintenant partie de chaque index, et moins d'enregistrements peuvent être stockés dans chaque nœud d'index. Votre base de données est également plus lente en raison de la perte de l'avantage inhérent de la localité de la référence.
-
Un retour en arrière des données pour 1 client peut être très difficile, voire essentiellement impossible à mesure que la base de données grandit - vous aurez besoin de procédures personnalisées pour le faire qui sont beaucoup plus lentes et gourmandes en ressources qu'une restauration simple et standard à partir d'une sauvegarde.
-
Les grandes bases de données peuvent être très difficiles à sauvegarder/restaurer en temps opportun, nécessitant éventuellement des dépenses supplémentaires en matériel pour le rendre assez rapide.
-
Vos applications utilisant la base de données seront plus difficiles à maintenir et à tester.
-
Les erreurs peuvent être beaucoup plus destructrices car vous pouvez compromettre tous vos clients par une seule erreur.
-
Vous empêchez l'amélioration possible des performances à faible latence en contraignant votre base de données à un seul emplacement. Par exemple, un client étranger utilisera des réseaux lents et à haute latence tout le temps.
-
Vous serez connu en tant que DBA stupide, ou DBA au chômage, ou peut-être les deux.
Il y a cependant quelques avantages à une conception de base de données partagée.
-
Les schémas de table communs, les tables de code, les procédures stockées, etc. n'ont besoin d'être entretenus et stockés qu'à un seul endroit.
-
Les coûts de licence peuvent être réduits dans certains cas.
-
Certaines opérations de maintenance sont plus faciles, bien que presque certainement pires dans l'ensemble en utilisant une approche combinée.
-
Si la plupart de vos clients sont très petits, vous pouvez avoir une faible utilisation des ressources en ne combinant pas les serveurs (c'est-à-dire un coût relativement élevé). Vous pouvez atténuer le coût élevé en regroupant les clients avec leur autorisation et leur compréhension explicites, mais en utilisant toujours des bases de données séparées pour les clients plus importants. Vous devez certainement être explicite et upfront avec vos clients dans cette situation.
Sauf le partage des coûts des serveurs, c'est toujours une très mauvaise idée - mais le coût peut aussi être un aspect très important. C'est vraiment la seule justification pour cette approche - évitez-la autant que possible cependant. Peut-être vaudrait-il mieux augmenter un peu plus le prix de votre produit, ou ne pas être en mesure de supporter des clients très petits pour un prix bon marché.
La lecture d'une analyse de la panne récente d'Atlassian révèle que cette erreur est précisément la raison pour laquelle ils ont tant de mal à se remettre.
Il y a cependant un problème :
Atlassian peut, en effet, restaurer toutes les données à un point de contrôle en quelques heures.
Cependant, s'ils le faisaient, alors que les ~400 entreprises impactées récupéreraient toutes leurs données, tout le monde perdrait toutes les données engagées depuis ce point
Maintenant, les données de chaque client doivent être restaurées sélectivement. Atlassian n'a pas d'outils pour le faire en masse.
L'article souligne également que certains clients migrent déjà loin d'Atlassian pour leur produit OpsGenie, et perdront certainement aussi des affaires futures. Au minimum, ce sera un gros problème pour leur entreprise.
Ils ont également commis une grosse erreur en ignorant le client pendant cette panne.
