Performances des jointures multiples

Question

Greetings Overflowers,

Je dois interroger des objets avec des conditions spatiales nombreuses/complexes. Dans les bases de données relationnelles traduites en plusieurs jointures (éventuellement 10+). Je suis nouveau à cette entreprise et je me demande si aller avec MS SQL Server 2008 R2 ou Oracle 11g ou des solutions basées sur des documents tels que RavenDB ou simplement aller avec une base de données spatiales (GIS) ...

Des idées?

Cordialement

MISE À JOUR: Merci à tous pour vos réponses. Quelqu'un choisirait-il des bases de données documentaires/spatiales? Ma base de données serait composée de dizaines de millions à quelques milliards d'enregistrements. Principalement en lecture seule. Presque pas de mises à jour, sauf en cas d'erreurs dans la saisie. Insertions de nuit et pas si fréquentes. Les tables jointes sont prédites au préalable mais le nombre de self-jointures (tables se rejoignant plusieurs fois) ne l'est pas. Les petites pages des résultats de ces requêtes seront affichées sur un site Web hautement interactif, de sorte que le temps de réponse est critique. Des prédictions sur la façon dont cela peut fonctionner sur MS SQL Server 2008 R2 ou Oracle 11g? Je suis également préoccupé par l'amélioration des performances en ajoutant plus de serveurs, dont on évolue mieux? Que diriez-vous de PostgresQL?

Answer 1

Construire et tester. C'est la seule façon de savoir si votre idée va fonctionner. Il existe des versions gratuites d'Oracle, SQL Server et Teradata disponibles pour le téléchargement. PostgreSQL est gratuit, période.

L'aide à la création de base de données n'est peut-être pas gratuite. Les performances SQL souffrent de mauvaise conception plus que toute autre cause unique. J'ai fait un test (proof of concept) hier (?? jours sont en cours dans ma tête) sur 20 tables de 50 millions de lignes, des clés naturelles (pas de numéros d'identification), 20 jointures à gauche, temps d'accès médian de 40 millisecondes. Utilisation d'un ordinateur de bureau avec des disques lents et 2 Go de RAM.

---

Edit: Il semble il y a aussi un free, single-server version of Greenplum qui est seulement limitée à deux prises CPU, aucune limitation sur les cœurs de processeur. Aucune limitation sur la taille de la base de données non plus. Je ressens le besoin de jouer avec quelques téraoctets.

Answer 2

Il est beaucoup plus courant d'effectuer 10 jointures sur un ensemble de tables dans une application pratique que vous ne le pensez. Les ramifications des jointures internes et externes qui sont aussi élevées sont différentes, mais je ne serais pas trop inquiet à moins que la quantité de données à laquelle vous appartenez soit très grande. Les bases de données sont optimisées pour traiter les ensembles.

Exemple:

Hier, j'ai écrit une requête qui effectue 13 jointures. Il s'exécute sur un jeu de plus de 50 000 enregistrements en moins d'une seconde.

Answer 3

D'accord, ce n'est pas tant les jointures qui posent problème que la quantité de données interrogées. Bien que j'admette que dans un environnement qui utilise MS SQL Server 2005, MS SQL Server 2008 R2 et ORACLE 10g et 11g, il semble que nos bases de données MS SQL soient légèrement plus sujettes aux verrous morts lorsque de grandes requêtes sont exécutées.

Answer 4

L'une des grandes inconnues de votre question est la dynamique du SQL et des instructions SQL similaires, à quelle fréquence les valeurs des prédicats changent-elles? Est-ce qu'ils utilisent des paramètres de liaison au lieu de valeurs en ligne (ils devraient si possible). S'il y a beaucoup de possibilités de réutilisation, Oracle serait mon choix.

Quelle que soit la complexité du SQL, Oracle dispose d'un ensemble de fonctionnalités pouvant vous aider. Les vues matérialisées et la réécriture SQL peuvent fournir des avantages de performances drastiques dans les cas où les résultats légèrement vieillis sont acceptables par rapport aux résultats en temps réel. Avec 11g, la mise en cache de l'ensemble de résultats est également disponible. Une fois que la base de données choisit un plan d'optimisation, ce n'est pas tant le nombre de jointures qui compte que la qualité de la base de données pour ces jointures spécifiques qui importe. L'indexation, les statistiques mises à jour et les vues matérialisées peuvent être critiques.

Answer 5

MS SQL Server 2008 R2 et ORACLE 11g devraient être capables de gérer cela sans difficulté. En termes d'extensibilité, je recommanderais Oracle 11g dans un environnement RAC. Vous pouvez également faire du clustering Microsoft avec MS SQL Server 2008 R2, mais dans mon expérience, le RAC d'Oracle est une solution plus solide.

Dans le même temps, les applications que vous prévoyez d'utiliser avec la base de données devraient également jouer un rôle dans la décision.Si vous utilisez MS SharePoint ou d'autres applications MS, MS SQL Server 2008 R2 peut être une meilleure solution. En termes de PostgreSQL, je n'ai pas beaucoup d'expérience avec ça, mais j'ai entendu des histoires de cauchemar de personnes qui l'ont utilisé dans un environnement d'entreprise et dans une grande entreprise. D'après ce que je sais, ce n'est pas exactement adapté à l'évolutivité. Personnellement, je pense que MySQL serait une meilleure solution que PostgreSQL si vous êtes à la recherche d'une solution open source, mais gardez à l'esprit que les solutions sql open source ne sont pas les plus simples en termes d'évolutivité ou de haute disponibilité. objectif.