Oracle contre PostgreSQL. Pourquoi choisir Oracle pourrait être une décision intelligente

En lisant de nombreux articles sur le hub sur la migration réussie d'Oracle vers PostgreSQL, un lecteur inexpérimenté peut avoir l'impression que PostgreSQL n'est ni pire ni même meilleur qu'Oracle. Et le choix est évident. Et les centaines de milliers d'entreprises qui finissent par payer des milliards de dollars à Oracle ne font que gaspiller leur argent. Mais je vais essayer de vous rassurer, où, où et dans les grandes entreprises, ils savent compter l'argent. Et leurs décisions ne sont nullement erronées.

Le but de l'article est de créer un grain de doute dans l'âme d'un lecteur qui essaie de faire un choix entre des bases de données relationnelles qui fonctionnent en mode versionné. Pourquoi exactement le mode versionné? Ici, le choix n'est pas grand, mais dans les bloqueurs, il y a de dignes concurrents et le choix est encore plus difficile (combien coûte la version gratuite de DB2 pour les petites bases de données?)

Je ne suis pas un expert de la base de données Oracle, bien que je travaille avec cette base de données depuis de nombreuses années et pas seulement avec. Tout ce que je peux faire, c'est utiliser ses avantages et atteindre des performances optimales. De plus, je ne suis pas un expert PostgreSQL (je ne l'ai jamais utilisé en production).

Lire des articles sur une migration réussie - Je comprends que ces entreprises n'avaient même pas besoin d'Oracle ou que la base de données avait initialement été mal sélectionnée. Ils n'ont utilisé qu'une petite fraction des capacités de cette base de données. Ce n'est qu'ainsi qu'ils pouvaient prendre une décision sur la migration et la mettre en œuvre. Simplement, si vous utilisez toute la puissance de cette base de données, vous n'aurez jamais envie de migrer car cela revient à écrire votre application à partir de zéro.

Parlons enfin des avantages de performances qu'Oracle offre et, sur la base de ces informations, vous trouverez la réponse par vous-même.

1. Partition (8i) . Partition - permet la croissance du volume de données avec pratiquement aucun effet sur les performances globales. Un bonus agréable et important est le partitionnement des index. Les partitions PostgreSQL n'apparaîtront que dans la version 10. Avant cela, l'héritage (HÉRITAGES) est un hack sale. Et les capacités de partitionnement d'Oracle augmentent avec chaque version.
2. Fusionner (8i) . Oui, oui, la même fusion qui a été dans MSSQL pendant de nombreuses années (2008) et qui n'existera même pas dans PostgreSQL 11. Elle donne une multiplication par dix de la vitesse par rapport aux opérations individuelles. Oui, je sais que PostgreSQL prend en charge les sous-requêtes et vous pouvez tout implémenter via Insert Select et la mise à jour délicate. Mais c'est loin d'être pareil.
3. RESULT_CACHE (Sélectionnez) (11g). Chez Oracle, cette technologie est apparue relativement récemment. Si vous utilisez cette technologie à bon escient - cela donne un gain à certains égards des dizaines ou des centaines de fois. L'essentiel est d'apprendre à l'utiliser intelligemment.
4. Option INMEMORY ( 12 ) Il n'y a pas d'analogue dans PostgreSQL. Une croissance réelle sur certaines requêtes des centaines de fois.
5. Optimiseur + optimisation des requêtes . À partir de 11g, il s'est transformé en presque un clic suivant-> suivant dans EM. PostgreSQL est plus compliqué avec cela et le manque d'un homologue EM en général est assez inconfortable.
   
   PL / SQL. Oui, je connais la variété des langages de PostgreSQL. Mais Oracle améliore constamment le langage en mettant l'accent sur les performances.
   
   • Compilation . Le bycode se produit lors de la sauvegarde (dans PostgreSQL lors du premier appel de la session + plan de requête lors de la première exécution). À partir de 10g, Oracle peut compiler en code natif.
   • Native Integer - accélère considérablement le travail avec les nombres. PostgreSQL peut utiliser d'autres langages plus appropriés (traducteurs). Dans Oracle, cela peut également être résolu en utilisant Java et C.
   • Changer le «contexte» de PL / SQL. Oracle est très soucieux d'optimiser cette métrique, de l'améliorer d'une version à l'autre. Pour réduire les retards Changer de «contexte» propose BULK COLLECT et FORALL et plus encore.
     
     Compte tenu de l'état des langages PostgreSQL, cette tâche n'est pas du tout importante à ce stade.
   • Cache de résultat (fonction) (11g) Avec une utilisation appropriée, la réactivité de l'application dans son ensemble peut augmenter plusieurs fois sans nécessiter beaucoup d'efforts. Sur certaines requêtes, des dizaines de fois.
     

Eh bien, comme on dit, le diable est dans les détails, et Oracle a beaucoup mieux travaillé ces détails. Oracle ne cesse de surprendre avec chaque version. Et peu importe à quelle base de données vous transférez après Oracle - vous aurez toujours le sentiment: Eh bien, bon sang, depuis longtemps Oracle, ou dans Oracle c'est mieux fait.

Je suis presque sûr qu'avec le même matériel et en utilisant toutes les fonctionnalités de PostgreSQL et Oracle, vous pouvez obtenir de meilleures performances, avec moins d'efforts sur ORACLE.

PS En aucun cas ne considérez cet article comme une base de données PR Oracle.

Je comprends bien qu'il y a toujours des choses qui sont mieux faites dans PostgreSQL. Mais en général, Oracle dans ce segment de la base de données numéro 1.

Je n'ai pas spécifiquement abordé les choses liées à l'administration. Imaginez simplement que vous pouvez transférer le fichier de date d'un disque à l'autre ou restaurer le «bloc cassé» à l'état En ligne. Et vous pouvez effectuer la transition vers de nouveaux serveurs sans arrêter la base de données. Et ce ne sont pas de nouvelles fonctionnalités. Chez Oracle, tout va bien mieux là-bas, et je ne suis pas administrateur de base de données.

Auparavant, quelque part jusqu'à la version 10, l'administrateur était presque toujours nécessaire. Maintenant, le besoin d'administrateur a considérablement diminué, bien que les qualifications de l'administrateur soient désormais plus élevées. Peut-être que dans la version 15, le concept de base de données «admin» appartiendra au passé :)

Oui, et Pl / SQL est plus réfléchi que les autres, bien que ce ne soit bien sûr pas C # :). C'est vrai, c'est purement individuel.

Eh bien, je n'ai pas abordé les choses qui aident mal à la vitesse.

PSS Et oui, je me souviens à peine de toutes les possibilités. Seuls ceux qui étaient à la "surface" ajoutent donc dans les commentaires. Je vais inclure dans la mise à jour.