MS SQL Server
  1. MS SQL Server
  3. Devrions-nous commencer avec plusieurs bases de données à petite échelle pour une application qui peut massivement échelle
Intereting Posts
Mettre à jour le noeud XML (dans une colonne XML) dans SQL Server 2005 avec une autre valeur de colonne dans la même ligne Comment puis-je seulement returnner une partie d'une string avec des longueurs variables en SQL? Comment se connecter à SQL Server à partir de .Net Core sans utiliser Entity Framework? SQL Server: sum des valeurs de plusieurs lignes dans une ligne JPA SET IDENTITY_INSERT ne fonctionne pas Comment appeler sp_help pour SQL Server lors de l'utilisation de Oracle SQL Developer en tant que client Le package SSIS s'exécute sur le server mais pas en tant que travail planifié (Agent SQL) Sélectionnez une colonne seulement si la condition est remplie Regex LIKE de Sql Server – clarification du comportement? Est-ce que est un niveau aussi bien qu'un membre SQL Server ORDER BY DESC / ASC Comment get la moyenne de trois loggings dans une colonne à partir du premier logging dans MS Access / SQL? SQL Server – Insertions simultanées dans la table à partir de plusieurs clients – Vérifier la limite et bloquer Supprimer certains caractères d'une string Comment vérifier la disponibilité de la database

Devrions-nous commencer avec plusieurs bases de données à petite échelle pour une application qui peut massivement échelle

Nous développons un nouveau site eCommerce et utilisons NHibernate pour la première fois. Actuellement, nous divisons nos données en plusieurs bases de données SQL Server, divisées par domaine de fonctionnalité. Nous en avons donc un pour UserInfo, un pour les commands, un pour ProductCatalogue et ainsi de suite …

Notre justification de cette décision est double:

  1. le site Web a le potentiel d'être ÉNORME (c'est un nouveau site web pour l'une des plus grandes marques en ligne au Royaume-Uni) et nous pensons qu'en partitionnant nos données selon des lignes fonctionnelles, nous pourrons déplacer les bases de données sur leurs propres servers. donnez-nous une voie d'échelle facile si nous en avons besoin;

  2. mon équipe a toujours travaillé de cette façon – en partie à la suite de suivre le model MS Commerce Server des projets précédents.

Cependant, en lisant cette décision sur internet, nous trouvons que la réponse normale à ce type de model est extrêmement cinglante. "Créer plus de travail pour les développeurs maintenant afin de créer plus de travail pour les devs plus tard" est un exemple de commentaire de Stack Overflow!

En outre, NHibernate est beaucoup plus facile à utiliser avec une seule database (une seule SessionFactory est nécessaire). Et sachant que Stack Overflow a fonctionné pendant une longue période, je pense que nous ne devrions peut-être pas essayer d'être aussi intelligent.

Alors, ma question est la suivante: "Avons-nous raison de penser que l'utilisation de bases de données à granularité fine pourrait augmenter notre capacité d'échelle ou devrions-nous sacrifier cela pour un développement plus facile"?

Pourquoi ne concevez-vous pas correctement votre database et ne placez pas les files sur le disque approprié? Utilisez un cluster si nécessaire. La création de plusieurs bases de données n'est pas une solution insortingnsèquement mise à l'échelle. Aussi – l'intégrité référentielle de la database croisée? Bonne chance.

Quelle est votre définition de "ÉNORME"? SQL Server peut gérer des bases de données volumineuses, mais une chose que j'ai apprise est que les gens n'ont souvent aucune idée de ce qui constitue un grand nombre de données.

Je n'ai jamais travaillé dans un projet comme celui-ci. Je suis habitué aux bases de données avec plusieurs centaines de tables, ce qui n'a jamais été un problème.

Par conséquent, je ne peux pas dire si votre idée est une bonne idée, je n'ai jamais essayé. Le «mon équipe a toujours travaillé de cette façon» – l'argument est un moteur majeur pour de nombreuses décisions, et je ne peux même pas dire que c'est toujours faux.

Avec NHibernate, vous organisez vos données dans des classs. Ils peuvent être dans des namespaces et des assemblages différents. En général, vous ne travaillez pas beaucoup avec la database, vous n'avez pas besoin de ce type de structure.

À propos de l'argument de l'évolutivité: je ne suis pas sûr que la mise à l'échelle soit efficace lorsque vous devez accéder à plusieurs bases de données à chaque fois. Je veux dire: vous avez toujours besoin d'users et de commands et probablement plus. Ensuite, vous devez get toutes ces données à partir de plusieurs bases de données.

Entièrement d'accord avec starskythehutch – gardez vos tables liées set dans le même DB. MAIS, vous voudrez peut-être envisager d'avoir des bases de données séparées pour les choses qui ne sont pas liées ou non critiques à votre produit principal; mais cela fait partie de l'application.

Par exemple: si vous décidez d'save chaque visite / hit sur le site dans une database, vous devriez probablement le conserver dans une database séparée.

La raison pour laquelle vous devriez considérer: 1. un grand nombre de transactions – disons des centaines de milliers / sec. Avoir un contenu non-critique non-critique dans une database séparée assurera que les conflits tlog à cause de cela sont évités.

  1. Restore, DBCC CHECKDB, time de sauvegarde. Si vous insérez vos données non critiques non liées dans votre database principale, vous augmentez essentiellement la taille de votre database et cela affectera ces opérations. L'avoir dans une database distincte vous aidera à améliorer les performances de ces opérations.