Qu'est-ce BIG TROP pour une base de données?

Question

J'ai un copain qui dirige une application web pour les listes de voitures à vendre. Il y a quelques milliers de clients qui l'utilisent, et chaque client a des centaines et parfois des milliers de lignes dans la base de données (certains ont été pendant 5 ans avec des centaines de voitures de vente chaque mois, et 10s de lignes par vente (commentaires, messages, etc)). Il gère ce système dans une base de données SQL Server dans un serveur physique avec comme 20GB ou RAM et un processeur de couple pour tout le temps, sans problème. Est-ce une sorte de miracle?

Tout comme la plupart des programmeurs, je ne suis pas DBA et vivoter grâce à ORM, etc. Partout où je regarde, les gens parlent d'avoir la nécessité de tesson ou d'obtenir un serveur de base de données séparée pour les grands utilisateurs d'une application web. Pourquoi est-ce? Est-ce vraiment inefficace d'avoir un grand DB avec beaucoup ou lignes? Devrais-je me utiliser Cassandra ou quelque chose, ou puis-je compter sur l'extension bien avec Postgres?

Answer 1

Personnellement, je ne pense pas que ce que vous avez décrit est que d'une grande base de données. Le serveur (20 Go de RAM;)) semble décent. Il est plus sur l'utilisation et le design. Si la base de données est indexé et bien conçu, il peut se développer beaucoup, beaucoup plus sur le matériel actuel.

Avant de faire toute sorte de commutateur, je voudrais simplement regarder l'archivage des données inutiles et l'optimisation des requêtes s'il y a une peur des problèmes de performance.

Answer 2

La raison de sharding et serveurs db séparés est que, à un moment donné, il va être moins cher d'utiliser plusieurs machines moins cher que l'un d'un cher. prix du matériel n'échelle pas de façon linéaire avec des performances et une fois que vous atteignez un certain point, il sera beaucoup moins cher pour obtenir deux fois plus de machines que pour obtenir une machine qui est deux fois plus vite.

Answer 3

Vous devriez avoir aucun problème dans le serveur SQL, Oracle, ou une base de données relationnelle ou non relationnelle moderne. J'ai administré des bases de données avec 100 de millions d'enregistrements et téraoctets de données.

Answer 4

En général, vous séparation des composants jusqu'à sur différents serveurs afin que vous puissiez gérer le temps, la résilience et la performance plus facilement.

Il est certainement tout à fait possible d'avoir une machine monstre qui fait tout, mais vous pouvez avoir besoin une autre machine monstre dans le cas où votre carte mère meurt ou votre centre de données est indisponible.

En divisant un site Web ou une application en place, entre autre serveur est il est plus facile d'obtenir des machines moins chères, et plusieurs d'entre eux. Ainsi, vous pouvez construire la résilience, et ne pas avoir des composants qui ont similiar exigences sur froissement du matériel.

Il est également important de penser à temps de restauration pour les serveurs et les plans de récupération.
Qu'advient-il lorsque votre machine meurt, vous pouvez le remplacer dans l'heure convenue? Pouvez-vous restaurer à partir des sauvegardes en ce moment?

SQL Server ou d'autres bases de données de classe entreprise ne doit pas avoir de problèmes avec 10 ou 100Go bases de données, tant qu'elles ne visent pas trop mal. (Nous avons quelques machines avec cette capacité / utilisation qui ne sont pas du mal du tout.).

Answer 5

Dans mon esprit, c'est rien. Avoir des dizaines de millions de lignes sur plusieurs tables avec la taille de base de données supérieure à 10 Go n'a pas causé des problèmes pour MS SQL Server. Bien sûr, il est pas trop vite que beaucoup de données, mais sinon il fonctionne très bien.

Et pour répondre à la question, trop grand est si grand qu'il provoque des problèmes. Et quand il commence causant des problèmes dépend de la structure de la table et vos exigences de performance.

Answer 6

Les bases de données sont extrêmement efficaces pour le stockage et la récupération de données relationnelle (à savoir des données qui sont structurées et a des références à d'autres données) - c'est ce qu'ils sont conçus pour faire. Honnêtement, 99% des personnes crachant sur les magasins à valeur clé et Cassandra et tout le reste ont aucune idée de ce qu'ils font. Un serveur de base de données est très bien pour le stockage de gros volumes de données, en particulier si vous êtes prêt à mettre un peu de travail dans l'accord correctement.

Cela dit, il y a des cas d'utilisation pour Cassandra et. Al. -. Si vous avez la clé pour la plupart non structurées / données de valeur ou ne pas besoin de cohérence ou si vous voulez shard pour la redondance, il peut être utile d'examiner

Sauf si vous êtes un site Web très populaire, vous pouvez probablement vous en tirer très bien avec un serveur de base de données décent - ne pas changer jusqu'à ce que vous avez déterminé pourquoi vous avez besoin de changer. La commutation est très bien, assurez-vous juste que vous passez, car il sert mieux à vos besoins, et pas parce que c'est la « chose cool web échelle à faire »