Quand est-il temps de changer de base de données?

https://stackoverflow.com/questions/74261

09-06-2019
|

Question

Existe-t-il une règle générale à suivre lors du stockage des données d'application Web pour savoir quel système de base de données doit être utilisé? Le nombre de visites par jour, le nombre de lignes de données ou d’autres statistiques à prendre en compte lors du choix est-il?

Mon idée initiale est que l'ordre de cette commande ressemblerait à ce qui suit (mais pas nécessairement, c'est pourquoi je pose la question).

Fichiers plats
BDB
SQLite
MySQL
PostgreSQL
SQL Server
Oracle

La solution

Ce n'est pas si facile. La seule règle générale est que vous devriez chercher une autre solution lorsque la solution actuelle ne peut plus suivre. Cela pourrait inclure l’utilisation de différents logiciels (pas nécessairement dans un ordre fixé globalement), de matériel ou d’architecture.

Vous obtiendrez probablement plus d'avantages en mettant en cache des données en utilisant quelque chose comme memcached , en passant à un autre backend de stockage aléatoire.

Autres conseils

Si vous pensez avoir besoin de l’un des poids lourds (SqlServer, Oracle), commencez par l’un de ceux-ci au début. Les migrations de données sont extrêmement difficiles. À long terme, il vous en coûtera moins de commencer par le sommet et d'y rester.

Je pense que vous êtes trop spécifique dans votre classement. Vous pouvez très bien commencer avec des fichiers plats et similaires pour de très petits ensembles de données, aller jusqu'à DBM pour des fichiers légèrement plus grands qui ne nécessitent pas de syntaxe SQL, puis dans une sorte de base de données SQL.

Mais qui veut faire toute cette réécriture? Si l'application bénéficie de l'accès aux jointures, procédures stockées, déclencheurs, validation de clé étrangère, etc., utilisez simplement une base de données SQL, quelle que soit la taille de l'ensemble de données.

Lequel devrait davantage dépendre des installations existantes du client et des compétences DBA disponibles que de la quantité de données que vous possédez.

En d'autres termes, la taille de votre base de données est loin d'être la seule considération, et peut-être pas la plus importante.

Il n’ya pas de réponse générale à cette question, mais PRESQUE presque toujours, l’utilisation de fichiers plats n’est pas une bonne idée. Vous devez les analyser (je suppose) et ils ne s’adaptent pas bien. Commencer avec une base de données appropriée, telle qu'Oracle ou SQL Server (ou MySQL, Postgres si vous recherchez des options gratuites) est une bonne idée. Pour très peu de frais généraux, vous épargnerez plus tard beaucoup d'efforts et de maux de tête. Ils vous permettent également de structurer vos données de manière non-stupide, vous laissant ainsi libre de penser à CE QUE vous ferez avec les données plutôt qu’à COMMENT vous les ferez entrer / sortir.

Cela dépend vraiment de vos données et de la manière dont vous envisagez de les utiliser. À l'un de mes postes précédents, nous utilisions Postgres en raison de la géolocalisation et des extensions de fuseau horaire natives, car cela nous permettait de gérer nos données à l'aide de types de données polygonaux. Pour nous, nous devions le faire et nous voulions également utiliser des procédures stockées, des vues, etc.

Maintenant, un autre endroit où je travaillais utilisait MySQL simplement parce que les données étaient normalisées, des données standard ligne par ligne.

SQL Server, pendant longtemps, avait une limite de base de données de 4 Go (voir SQL Server 2000), mais malgré cette limitation, il reste une plate-forme très stable pour les applications petites à moyennes pour lesquelles les anciennes données sont purgées.

Maintenant, après avoir travaillé avec Oracle et SQL Server 05/08, tout ce que je peux vous dire, c'est que si vous voulez la crème de la crème pour la stabilité, l’évolutivité et la flexibilité, alors ces deux solutions sont votre meilleur choix. Pour les applications d’entreprise, je les recommande fortement (simplement parce que c’est ce que nous utilisons là où je travaille maintenant).

Autres points à prendre en compte:

Intégration linguistique (stockage de session ASP.NET, gestion des rôles, etc.)
Types de requête (Sélection, Mise à jour, Suppression) [Bien qu'il s'agisse davantage d'un problème de conception de schéma que d'un problème de SGBD)
Exigences en matière de stockage de données

L'utilisation de la base de données par votre application est la plus critique. Quelles sont les requêtes les plus utilisées (SELECT, INSERT ou UPDATE)?

Dites si vous utilisez SQLite, il s'agit d'une vitesse pour une application plus petite mais pour " web " application, vous pourriez en avoir un plus gros comme MySQL ou SQL Server.

La façon dont vous écrivez les scripts et vos plates-formes d'applications Web est également importante. Si vous développez sur une plate-forme Microsoft, SQL Server est une meilleure alternative.

En règle générale, j'utilise ce qui est communément accepté par le framework que j'utilise. Donc, si je fais .NET = > SQL Server, Python (via Django ou Pylons) = > MySQL ou SQLite.

Cependant, je n'utilise presque jamais de fichiers plats.

Le choix d’une solution de SGBDR ne se limite pas à une "puissance d’arrière-plan". La possibilité de contrôler les engagements, par exemple, pour pouvoir annuler une transaction ayant échoué en est une. raison.

À moins que vous ne vous trouviez dans l'application de taux de conversion moyenne, la plupart des moteurs de base de données seraient suffisants. Il faut donc savoir combien vous voulez payer pour le logiciel, s'il fonctionne sur le matériel et l'environnement du système d'exploitation souhaités, et ce que vous voulez. l'expertise que vous avez dans la gestion de ce logiciel.

Cette progression semble douloureuse. Si vous souhaitez inclure des produits MS (en particulier le serveur SQL payant) dans n'importe quel emplacement, vous pouvez également utiliser la totalité de la pile, car vous ne payez que le dernier élément.

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered).

Si vous ciblez initialement votre application sur SQL Server Compact, tout votre code SQL est garanti pour pouvoir être mis à l'échelle à la version suivante, sans modification. Si vous devenez plus gros que SQL Server Enterprise, alors félicitations. C’est ce qu’ils appellent un bon problème.

Aussi: revenez en arrière et vérifiez les podcasts de SO. Je crois qu'ils en ont parlé brièvement.

Cette question dépend vraiment de votre situation.

Si vous avez le contrôle sur le serveur sur lequel vous déployez et que vous pouvez installer tous les services dont vous avez besoin, le temps d'installation d'un serveur MySql ou MSSQL Express et d'un code par rapport à une infrastructure de base de données existante, codant VERSUS par rapport à une structure de fichier à plat n'est pas vaut la peine de considérer l'effort.

Qu'en est-il de FireBird? Où cela s'insérerait-il dans cette liste?

Et n'oublions pas les exigences du " client " de votre solution doit également avoir en place. Si vous écrivez une application commerciale pour une petite entreprise, Oracle pourrait ne pas être un bon choix ... mais si vous écrivez une solution personnalisée pour une grande entreprise qui doit partager des données entre plusieurs campus et qui possède un service informatique de bonne taille, décision d’Oracle vs SQL Server se résumerait à ce que le client a probablement déjà déployé.

La migration des données n’est pas si mauvaise aujourd’hui, car nous disposons des excellents outils d’Embarcadero. Je laisserais donc les besoins du client guider sa décision.

Si vous avez l'option SQL Server, c'est un bon choix dès le départ, principalement parce que vous avez accès à des procédures et des fonctions solides et que les fonctions de sauvegarde de la base de données sont totalement fiables. En intégrant autant que possible votre logique dans la base de données elle-même (plutôt que dans le langage que vous utilisez), la sécurité et les performances sont optimales. En effet, il existe un bon argument pour toujours utiliser des procédures de logique d'insertion / mise à jour, car elles vous invulnérable aux attaques par injection.

Si j’ai le choix, je préférerais utiliser uniquement une base de données volumineuse, assez simple, principalement utilisée pour un accès en lecture. Ce n’est pas pour décrypter MySQL qui s’est nettement amélioré récemment et que j’utilise volontiers si je n’ai pas le choix, mais pour les systèmes plus complexes avec une activité de mise à jour / insertion, MSSQL est généralement l’option supérieure.

Je pense que votre liste est subjective mais je vais jouer à votre jeu.

Fichiers plats

BDB

SQLite

MySQL

PostgreSQL

SQL Server

Oracle

Teradata

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow