Migration achevée : Amazon’s Consumer Business a déconnecté sa dernière base de données Oracle

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/08/2018, 04h40
Stan Adkens

1 pièce(s) jointe(s)

Migration achevée : Amazon’s Consumer Business a déconnecté sa dernière base de données Oracle

Amazon envisage d'abandonner complètement les SGBD et services d’Oracle d’ici 2020
Oracle serait incapable de répondre à ses besoins de performance

Pour rappel, Oracle a enregistré déjà des départs de clients à cause de ses tactiques de vente agressives, menaçant les clients de ses logiciels sur site avec des audits d'utilisation potentiellement coûteux et proposant fortement la migration vers sa solution cloud comme une panacée à leurs problèmes. Par ailleurs, d’après les résultats d’une étude réalisée en avril par Jefferies & Company, Oracle s’est fait surclasser sur le marché des infrastructures et plateformes en tant que services (IaaS / PaaS) par Amazon, le leader du marché du cloud, Microsoft et autres. L’annonce de JP Morgan du mois de juin dernier selon laquelle Oracle serait en train de perdre la faveur des acheteurs de technologies pour des principaux fournisseurs de solutions de cloud computing participe à ce que l’on pourrait qualifier de chute de la société de Redwood Shores.

Oracle serait devenu l’un des rivaux d’Amazon, le leader du marché du cloud computing, à cause de ses prouesses en la matière, selon CNBC. Amazon prévoit, par ailleurs, abandonner complètement les logiciels d’Oracle d’ici 2020. La raison principale serait l'incapacité de la technologie de base de données à évoluer pour répondre aux besoins de performances d'Amazon, selon une personne qui a connaissance du dossier. Le plan de retrait intervient aussi dans un contexte où la plupart des infrastructures ont été transférées en interne à Amazon Web Services. La séparation d’avec Oracle serait effective en mi-2019, a déclaré une autre source, qui selon elle, il n’y existerait pas de développement récent de nouvelles technologies basées sur Oracle.

Pièce jointe 401226

Pour cette raison, Amazon qui avait déjà commencé à déployer ses propres infrastructures en interne, envisage de se séparer complètement de son fournisseur de longue date en base de données sur site, Oracle, d'ici 2020. Ce probable arrêt est un signe de maturité de plus que laisse voir le géant du commerce électronique à ces concurrents. En effet, son fournisseur Oracle ne s’adapterait plus à ses besoins de performance de migration de ses charges vers le cloud abandonnant les solutions sur site d’Oracle.

Amazon doit cette performance à l'expansion d'Amazon Web Services qui lui a, par ailleurs, permis de surclasser Alphabet en début d’année pour devenir la deuxième entreprise cotée en bourse la plus importante au monde. Au second trimestre de cette année, AWS a enregistré une croissance de 49 %. Tandis que les résultats d’Oracle stagnent et les actions continuent de chuter.

Selon l’une des sources, il y a 4 ou 5 ans qu’Amazon a commencé sa migration. Néanmoins, une partie de ses activités de base est toujours hébergée sur Oracle le temps de mener à bien la transition vers ses propres infrastructures. Selon une source d’information, la migration complète interviendrait dans environ 14 à 20 mois.

Toutefois, l’infrastructure d’Amazon n’est pas sans reproche. Une panne d'un programme interne appelé Sable, utilisé par Amazon pour fournir des services de stockage à ses entreprises de détail et numériques a entrainé de nombreuses erreurs lorsque les clients essayaient d’accéder au site lors du Prime Day d'Amazon, le mois dernier, selon CNBC.

A propos des efforts fournis par Amazon pour son autonomie complète, Larry Ellison, président exécutif et directeur technique d'Oracle Corporation objecte en déclarant : « Laissez-moi vous dire qui ne quitte pas Oracle », a déclaré Ellison. « Une société dont vous avez entendu parler nous a donné ce trimestre 50 millions de dollars supplémentaires pour acheter une base de données Oracle et d’autres technologies Oracle. Cette société est Amazon. », a-t-il ajouté, infirmant ainsi les déclarations selon lesquelles Amazon s’apprêterait à se séparer d’avec les solutions Oracle. Ellison a poursuivi, par ailleurs, en soulignant que « les concurrents, qui n’ont aucune raison de nous aimer beaucoup, continuent d’investir et de gérer l’ensemble de leurs activités sur Oracle ».

Les dirigeants d’Amazon continueraient d’investir dans la technologie d’Oracle selon un communiqué d’un porte-parole d’Oracle. Selon Oracle, Amazon ne serait pas prêt pour que ses gros clients puissent migrer vers sa plateforme.

Amazon a réagi aux attaques de son fournisseur de base de données sur site pour défendre son infrastructure. Ses dirigeants ont loué, en 2017, les avantages de coût de l'utilisation du logiciel de base de données d’Amazon. Dans une riposte, le PDG d'AWS, Andy Jassy, a affirmé qu'Oracle était « très loin dans le cloud ».

Cette guerre des mots a commencé avec le lancement d’Aurora, le service de base de données relationnelle d’Amazon ainsi qu’un outil permettant aux entreprises de déplacer des bases de données vers le cloud qui visent le marché d’Oracle et qui attitreraient déjà certains de ses clients.

Cette guerre pourra durer encore longtemps, cependant depuis lors, Oracle n'a pas réussi à conquérir des parts de marché notables dans l'infrastructure cloud. AWS est en tête sur ce marché et est suivie par Microsoft, Google, Alibaba et IBM.

Source : CNBC

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Amazon est-il prêt pour son autonomie vis-à-vis de son fournisseur Oracle ?

Voir aussi

:fleche: Les clients d'Oracle seraient en train de migrer vers SQL Server et d'autres SGBD, Oracle perdrait du terrain sur tous les fronts selon des analystes
:fleche: Les techniques de vente agressives d'Oracle s'avèrent contre-productives, elles ont tendance à chasser certains clients
:fleche: Gartner : Le marché des logiciels d'infrastructures et middleware en croissance en 2017, IBM en tête suivi par Oracle et Salesforce
03/08/2018, 14h15
Mat.M

ce qu'il faut en penser ?
moua ha ha je me marre je me marre...
les entreprises qui ont basé leurs système d'information sur cette solution technologique si elles choisissent de changer de techno (indépendamment de l'éditeur Oracle) eh bien le risque c'est de devoir refaire les projets info de A à Z donc ça fera du boulot pour les programmeurs mais une charge pour les entreprises.

On ne le répètera jamais assez mais dans un projet informatique et dans les lignes de code faites le plus abstrait possible en scindant le code en modules,entités qui ne soient pas dépendantes d'une techno en particulier ( ici Oracle)
Car si vous changez de techno ici un SGBDR là faut réecrire une bonne partie du code
03/08/2018, 14h53
Saverok

Citation:

Envoyé par Stan Adkens

:fleche: Qu’en pensez-vous ?

Travailler avec de gros éditeurs et tjrs une galère.
J'ai été en relation avec MS, SAP, Salesforce, Amazon, IBM et Oracle et le pire de tous est Oracle.
Ils sont d'une arrogance et d'une agressivité que je n'ai jamais vu ailleurs.
Tout est bon pour nous faire raquer et dans des proportions démesurées.

Côté SGBD, ça fait des années que tous les nouveaux projets auquel j'ai participé se font sous Pg et je participe de plus en plus à des projets de migrations d'Oracle vers Postgres.
Rien qu'avec les économies de licences, les ROI de ces projets de migrations sont phénoménaux.

Citation:

Envoyé par Stan Adkens

:fleche: Amazon est-il prêt pour son autonomie vis-à-vis de son fournisseur Oracle ?

Pas encore mais ça viendra
Amazon a les ressources pour y parvenir et ne l'a jamais caché.
03/08/2018, 15h21
Anselme45

Citation:

Envoyé par Mat.M

ce qu'il faut en penser ?
moua ha ha je me marre je me marre...
les entreprises qui ont basé leurs système d'information sur cette solution technologique si elles choisissent de changer de techno (indépendamment de l'éditeur Oracle) eh bien le risque c'est de devoir refaire les projets info de A à Z donc ça fera du boulot pour les programmeurs mais une charge pour les entreprises.

Refaire le projet de A à Z? Rien que cela?

Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème et surtout en refaisant le projet de la lettre A à ... La lettre B! Pas besoin de passer en revue les 26 lettres de l'alphabet :mrgreen:
03/08/2018, 15h24
Anselme45

Citation:

Envoyé par Saverok

Côté SGBD, ça fait des années que tous les nouveaux projets auquel j'ai participé se font sous Pg et je participe de plus en plus à des projets de migrations d'Oracle vers Postgres.
Rien qu'avec les économies de licences, les ROI de ces projets de migrations sont phénoménaux.

Idem...

Oracle prend depuis trop longtemps ses clients pour des pigeons... Pour finir, les pigeons se révoltent et c'est... parfaitement normal!
03/08/2018, 15h27
Saverok

Citation:

Envoyé par Anselme45

Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème et surtout en refaisant le projet de la lettre A à ... La lettre B! Pas besoin de passer en revue les 26 lettres de l'alphabet :mrgreen:

C'est surtout si le projet contient des procédures stockées qu'il y a du taff.
Par contre, pour le SQL de base, c'est particulièrement basique.

Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
Rien de bien méchant mais parfois chronophage.
03/08/2018, 15h45
Anselme45

Citation:

Envoyé par Saverok

Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
Rien de bien méchant mais parfois chronophage.

Pense aux économies que l'entreprise va faire en n'ayant plus à envoyer ses admin Oracle suivre les cours à l'Oracle University (Put... Même là, ces c... se la pête!) :mur:

Avec le fric économisé qu'il faut débourser à chaque nouvelle édition du sgbd Oracle, l'entreprise peut financer du temps pour les proc liés à la maintenance et même se payer une nouvelle imprimante pour imprimer des jolis certificats de formation avec entête "My University" :mouarf:
03/08/2018, 16h12
hotcryx

Tout refaire? Non dans le cadre d'un projet classique c'est le plus facile à changer.
Ce n'est qu'un SGBD.
Il y a sacré panel de SGBD SQL (Sql Server, MariaDb, Postgress SQL...).

Concernant Amazon il doit y avoir une toute autre problématique: les serveurs dédiés et probablement fine-tunés.
03/08/2018, 16h15
hotcryx

Citation:

Envoyé par Anselme45

Pense aux économies que l'entreprise va faire en n'ayant plus à envoyer ses admin Oracle suivre les cours à l'Oracle University (Put... Même là, ces c... se la pête!) :mur:

Avec le fric économisé qu'il faut débourser à chaque nouvelle édition du sgbd Oracle, l'entreprise peut financer du temps pour les proc liés à la maintenance et même se payer une nouvelle imprimante pour imprimer des jolis certificats de formation avec entête "My University" :mouarf:

Oui mais pense aussi aux frics qu'ils vont perdre quand leurs serveurs ne répondront pas, avec la charge non supportées.
De quoi flinguer 2, 3 ingénieurs :)
03/08/2018, 16h59
commandantFred

Est-ce que les comportements des grands éditeurs ont des conséquences sur le choix de leurs clients malmenés de chercher à les remplacer ?
La réponse est OUI et ça ne vaut pas que pour cet éditeur même s'il caricature le genre.

Le temps des monopoles est révolu. Le software ne peut pas rester indéfiniment l'industrie la plus arrogante au monde.

Par ailleurs, il me semble que les réactions ci-dessus ont oublié MongoDb et NoSql.

Difficile d'estimer le coût moyen d'une migration mais force est de constater que les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?

Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)

SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.
03/08/2018, 17h37
Invité

Citation:

Envoyé par Saverok

Là où il y a du taf, c'est surtout du côté des administrateurs qui doivent revoir les proc de monitoring, de sauvegarde, d'indexation, vacuum, etc.
Rien de bien méchant mais parfois chronophage.

De plus une migration depuis Oracle vers un autre SGBD peut imposer selon la criticité des données d'effectuer des tests de restauration à partir des bandes archivées au bunker.

Sûrement est-ce ce que tu appelle monitoring mais il faut également réviser les scenarios de supervision, les chaînes de traitement de l'ordonnanceur et les crontab.

Puis enfin mettre à jour la documentation parfois foisonnante et dérouler les mises en production en heures non ouvrées...

C'est une charge de travail dont Oracle a probablement conscience qu'elle dissuade des migrations et je m’inquiète d'ailleurs de voir les mêmes travers se dessiner avec le big data dont les solutions sont principalement propriétaires (en tout cas concernant le SI sur lequel je bosse).
03/08/2018, 23h36
steel-finger

Nous on s'est fait attaqué pour une histoire de licence qu'ils ont voulus arrangés a leur sauce et depuis ce jour la, les produits Oracles c'est fini !
04/08/2018, 15h26
Mat.M

Citation:

Envoyé par Anselme45

Refaire le projet de A à Z? Rien que cela?

bonjour je me suis fait mal comprendre sans doute étais-je insuffisament explicite.
La problématique est la suivante : admettons que vous déclariez une classe Java ou C++ (ou C# ) donc vous déclarez la directive import ou #include sur une API Oracle pour piloter la base de donnée
Ensuite admettons que cette classe serve à instancier un client en particulier (ceci à titre d'exemple) et que vous déclariez une méthode qui appelle directement une API Oracle pour lister les clients du SGBDR
Eh bien si vous avez plusieurs classes avec des appels à des API Oracle ( ou autre SBGDR) ,du genre execute_procedure_stockee(), avec execute_procedure_stockee() répétée plusieurs fois c'est là où il va falloir refaire le code le cas échéant si vous changez de techno
05/08/2018, 21h31
pachot

Bonjour,

Ce sont des annonces politiques et marketing faites par des companies rivales, bien loin des réalités techniques. C'est trés bien pour la compétition qui fait évoluer les produits. Mais l'inconvénient c'est que, comme toutes les startups et PME on l'habitude de s'identifier avec les géants, tout le monde pense pouvoir faire pareil.

La raison invoquée dans l'article est l'incapacité à suivre la charge:

Citation:

The primary issue Amazon has faced on Oracle is the inability for the database technology to scale to meet Amazon's performance needs, a person familiar with the matter said.

S'il y a une chose où Oracle a fait ses preuves, c'est sur les très grosses bases critiques (telecom, aerien, retail, CERN, ...). Personne ne peut concurrencer Parallel Query, Partitioning, RAC pour ces très grosses bases.

Le marketing BigData et NoSQL a fait croire que le SQL est dépassé:

Citation:

Envoyé par commandantFred

les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?
Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)
SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.

La particularité du SQL est qu'il travaille sur des ensembles de donnée et non ligne à ligne. Il est basé sur des concepts mathématiques. C'est un language de 4ème génération - un des seul en production aujourd'hui. Il est loin d'être dépassé par des langages de 3ème génération et des modèles hierarchiques (comme OO, XML, JSON) qui ont montré leurs limites il y a 30 ans, d'où l'invention du relationnel. D'ailleurs, Hadoop, Kafka,... se mettent au SQL. L'approche ensembliste est nécessaire aux gros volumes.

@commandantFred J'aimerais bien voir la question sur les 'index trop aléatoires' et les index partiels dans le forum pour répondre la dessus.

Certains pensent que la migration d'un SGBD à l'autre est facile. C'est loin d'être le cas dès qu'on a une application serieuse, multi-utilisateurs, avec un grand historique de données.

Citation:

Envoyé par Anselme45

Pour info, les "SGBD Oracle", ce n'est rien d'autre que de la base de données SQL! A part de rares exceptions où il serait fait appel à des concepts très exotiques propres à Oracle, le remplacement d'une "SGBD Oracle" par une autre solution de base de données SQL se fait sans problème

Non, même les comportements les plus basiques sont très différentes. Un simple SELECT va verouiller sur certains SGBD, pas sur d'autres, et ne va pas montrer les mêmes données dès qu'il a d'autre utilisateurs en train de faire des modifications. C'est peut-être acceptable pour une appli simple et non-critique, mais pas pour un ERP. Et il est certain que si le but n'est d'utiliser que les fonctionnalités qui se trouvent dans SQLite, il ne faut pas acheter Oracle ;)

Citation:

Envoyé par Saverok

C'est surtout si le projet contient des procédures stockées qu'il y a du taff.
Par contre, pour le SQL de base, c'est particulièrement basique.

Au contraire, lorsque les accès à la base sont encapsulés dans des procédures, il est facile de les réécrire dans une autre langage. Et de tester les procédures de manière unitaire. Lorsque le code applicatif attaque directement les tables, c'est plus compliqué. Le but des vues et des procédures stockées est justement d'avoir une application (couches présentation et parfois business) indépendente de la plateforme.

Citation:

Envoyé par hotcryx

Tout refaire? Non dans le cadre d'un projet classique c'est le plus facile à changer.
Ce n'est qu'un SGBD.
Il y a sacré panel de SGBD SQL (Sql Server, MariaDb, Postgress SQL...).

Ils ont tous des comportements différents, visibles dans les performances mais aussi dans les données. Le travail gigantesque de migration n'est pas dans la réécriture du code mais dans les tests. Et peu d'éditeurs de logiciel on envie de se lancer dans ce travail. Sans parler de l'immense effort de re-design qu'il faudra faire pour retrouver des performances correctes car l'optimiseur d'oracle a, au fur et à mesure des version, intégré plein de workarounds pour des problèmes de performance applicatif. Les vendeurs de progiciels y réfléchissent, mais la réalité les ralentit. Le coût de développement peut être monstueux si l'on compare avec une application APEX par exemple.

Puisque Amazon invoque des limites de performances, il s'agit d'un use-case bien précis où le relationnel a ses limites et où il faut troquer la flexibilité pour une solution dédiée. Ce qu'ont développé Google, Amazon, Facebook... dans des domaines précis est très bien. Mais penser qu'on peut faire pareil pour toutes les applis de toutes les entreprises est utopique. Un exemple: Google a développé Spanner pour remettre un peu de SQL et de relationnel dans son BigTable lorsque le NoSQL a montré ses limites. Mais il n'y a pas de types de donnée décimale. Ca ne pourra jamais remplacer un SGBDR existant sauf pour quelques cas particuliers. Vers PostgreSQL, d'autres problèmes: PostreSQL ne fait pas d'updates mais recopie toute la ligne. Un appli qui fait beucoup de mises à jour ne sera jamais scalable. Et pas d'opérations online: maintenance difficile sur une appli 24/7. Et les autres SGBD où les lectures bloquent les écritures. Il faudra tout réécrire sauf si l'application n'a qu'un seul utilisateur.

Cordialement,
Franck.
06/08/2018, 09h13
commandantFred

Citation:

Envoyé par pachot

S'il y a une chose où Oracle a fait ses preuves, c'est sur les très grosses bases critiques (telecom, aerien, retail, CERN, ...). Personne ne peut concurrencer Parallel Query, Partitioning, RAC pour ces très grosses bases.

Le marketing BigData et NoSQL a fait croire que le SQL est dépassé:

La particularité du SQL est qu'il travaille sur des ensembles de donnée et non ligne à ligne. Il est basé sur des concepts mathématiques. C'est un language de 4ème génération - un des seul en production aujourd'hui. Il est loin d'être dépassé par des langages de 3ème génération et des modèles hierarchiques (comme OO, XML, JSON) qui ont montré leurs limites il y a 30 ans, d'où l'invention du relationnel. D'ailleurs, Hadoop, Kafka,... se mettent au SQL. L'approche ensembliste est nécessaire aux gros volumes.

@commandantFred J'aimerais bien voir la question sur les 'index trop aléatoires' et les index partiels dans le forum pour répondre la dessus.

Certains pensent que la migration d'un SGBD à l'autre est facile. C'est loin d'être le cas dès qu'on a une application serieuse, multi-utilisateurs, avec un grand historique de données.

Non, même les comportements les plus basiques sont très différentes. Un simple SELECT va verouiller sur certains SGBD, pas sur d'autres, et ne va pas montrer les mêmes données dès qu'il a d'autre utilisateurs en train de faire des modifications. C'est peut-être acceptable pour une appli simple et non-critique, mais pas pour un ERP. Et il est certain que si le but n'est d'utiliser que les fonctionnalités qui se trouvent dans SQLite, il ne faut pas acheter Oracle ;)
(...)
Cordialement,
Franck.

Bon, les "concepts mathématiques" de SQL coté dev, c'est la théorie des ensembles qu'on a tous appris en 6eme... Vous restez sur des notions très théoriques, j'ai travaillé sur une dizaine de front ends Oracle (mais pas que...)

Non, le NoSQL n'est pas un mouvement né du marketing. Il est arrivé avec les sites web à très forte charge (10 ^ 8/jour). Les bases noSQL ont été développées en interne chez ces fournisseurs pour faire sauter les goulots d'étranglement de SQL (d'où le nom). Ce n'est qu'ensuite qu'ils ont été mis aux normes pour être distribués et que le marketing s'y est intéressé.

Encore une fois, je n'ai rien contre SQL, au contraire, je continuerai à l'employer à cause de sa formidable facilité d'utilisation. Mais il faut remettre les choses dans le contexte : SQL régnait en maître alors que les bases de données se limitaient aux logiciels spécifiques qui proposaient surtout des formulaires à remplir et des choses comme ça. Les gros volumes de l'époque dépassaient rarement les 10 milliards de lignes.

Aujourd'hui que fait-on avec dix giga-lignes quand ont est un GAFAM.. ?? Pas grand chose...

La limitation structurelle de SQL dans les très gros datasets provient de la conception de ses indexes. Disons pour faire simple, que ses concepteurs ont souhaité rendre les indexes aussi transparents que possible. Leur usage dans une recherche est implicite ou encore 'aléatoire' parce qu'il est quasi-impossible de forcer SQL à utiliser un index précis sans passer par les spécificités constructeur. Sous oracle, ça passe par l'ajout d'un hint en commentaire dans la clause select (que le schema d’exécution ne respecte pas toujours). Sur d'autres implémentations, il faut faire des acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements.

Si vous avez fait un peu de gros volumes (tera-lignes) , vous réaliserez tôt ou tard que les index SQL sont inadaptés.
J'en ai fait la cruelle expérience le mois dernier sur une requête portant sur 300 milliards de lignes dont l'index avait été désynchronisé par un client situé de l'autre coté de la planète. Résultat au lieu de durer 2 heures, la requête s’exécute en ... 15 ans ? 150 ans ? Je n'ai pas attendu pour vérifier...

Le modèle conceptuel de SQL prévoit de limiter la portée des requêtes en passant par les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes. La performance n'est pas au rendez-vous. Je soupçonne les VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE des requêtes et non pas les perfs.

J'en reviens donc à ce que je disais plus haut. Tant que SQL n'autorise pas de WHERE dans le CREATE INDEX ni l'ouverture d'un index comme une table (figurer dans une clause SELECT), il sera condamné à rester aux volumes des années 90 (fichiers sécu, impôts et douanes américaines) mais ne pourra pas s’accommoder des volumes d'aujourd'hui.
06/08/2018, 18h19
SQLpro
Citation:

Envoyé par commandantFred

Difficile d'estimer le coût moyen d'une migration mais force est de constater que les disques durs font 4 To et que SQL s’accommodait mieux de volumes 10 à 50 fois inférieurs à ceux qu'on rencontre aujourd'hui. Alors "technologie déclinante" ?

je pense que vous êtes un peu à côté de la plaque... Personnellement j'ai plus d'une vingtaines de clients qui ont des bases de plusieurs dizaines de To (SQL Server)...

Citation:

Un peu à cause de sa gestion des index trop aléatoire et l'impossibilité jusqu'ici de mettre une clause WHERE dans un CREATE INDEX (le vieux Xbase le faisait pourtant...)

La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE

Citation:

SQL reste génial mais les gros volumes d'hier sont devenus petits et les SGBD ne sont plus la chasse gardée des deux premiers éditeurs mondiaux. A bons entendeurs, salut.

La plupart des grands éditeurs (IBM, Oracle, MS) ont intégrés des technologies mature venant du NoSQL comme (je parle pour SQL Server) :
- les types objets, notamment : XML, geometry, geography, JSON...
- la modification à chaud des structures de données (pas de blocage des données des tables en cours de restructuration)
- la création/reconstruction à chaud des index (pas de blocage des données lors de la création et la maintenance des index)
- Le partitionnement des tables
- la réplication des données entre divers noeuds (7 mécanismes différents dans SQL Server
- la haute disponibilité des nœuds (à na pas confondre avec la réplication des données)
- la compression des données et index
- les tables "in memory"
- les procédures stockées compilées en mode natif (C)
- l'indexation verticale ("columnstore")
- l'indexation des documents électroniques (type bases documentaire NoSQL)
- les vues indexées
- l'indexation sémantique (genre "elastic search")
- les tables de nœuds et d'arêtes ("graph database")
Tout ceci est disponible dans SQL Server... Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...
un Seul SGB NoSQL est capable de faire plusieurs de ces choses : Cosmos DB... et je vous laisse deviner qui en est l'éditeur !

À lire : https://blog.developpez.com/sqlpro/p...l-a-tout-faire

A +
06/08/2018, 18h28
SQLpro

Citation:

Envoyé par commandantFred

Bon, les "concepts mathématiques" de SQL coté dev, c'est la théorie des ensembles qu'on a tous appris en 6eme... Vous restez sur des notions très théoriques, j'ai travaillé sur une dizaine de front ends Oracle (mais pas que...)

Non, le NoSQL n'est pas un mouvement né du marketing. Il est arrivé avec les sites web à très forte charge (10 ^ 8/jour). Les bases noSQL ont été développées en interne chez ces fournisseurs pour faire sauter les goulots d'étranglement de SQL (d'où le nom). Ce n'est qu'ensuite qu'ils ont été mis aux normes pour être distribués et que le marketing s'y est intéressé.

Vous confondez NoSQL et Big Data. Aucun site web marchand n'a 300 milliards de lignes dans ses tables. Et presque tous utilisent des SGBDR Relationnels gérant des transaction pour la partie marchande, même AMAZON... ! Pour info, en France, TOUS les gros sites web marchand sont sur des SGBDR (Fnac, CDiscount, Ventes Privées => SQL Server, tgv.com => Oracle...)

Citation:

Encore une fois, je n'ai rien contre SQL, au contraire, je continuerai à l'employer à cause de sa formidable facilité d'utilisation. Mais il faut remettre les choses dans le contexte : SQL régnait en maître alors que les bases de données se limitaient aux logiciels spécifiques qui proposaient surtout des formulaires à remplir et des choses comme ça. Les gros volumes de l'époque dépassaient rarement les 10 milliards de lignes.

Aujourd'hui que fait-on avec dix giga-lignes quand ont est un GAFAM.. ?? Pas grand chose...

La limitation structurelle de SQL dans les très gros datasets provient de la conception de ses indexes.

Renseignez-vous il existe des technologies d'indexation pour les très grosses tables. C'est le cas des index columstore de SQL Server qui ne sont réellement utilisable qu'a partir de 100 millions de lignes, car ils travaillent avec des "pages" de 1 million de lignes au minimum...

Citation:

Disons pour faire simple, que ses concepteurs ont souhaité rendre les indexes aussi transparents que possible. Leur usage dans une recherche est implicite ou encore 'aléatoire' parce qu'il est quasi-impossible de forcer SQL à utiliser un index précis sans passer par les spécificités constructeur. Sous oracle, ça passe par l'ajout d'un hint en commentaire dans la clause select (que le schema d’exécution ne respecte pas toujours). Sur d'autres implémentations, il faut faire des acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements.

Si vous avez fait un peu de gros volumes (tera-lignes) , vous réaliserez tôt ou tard que les index SQL sont inadaptés.
J'en ai fait la cruelle expérience le mois dernier sur une requête portant sur 300 milliards de lignes dont l'index avait été désynchronisé par un client situé de l'autre coté de la planète. Résultat au lieu de durer 2 heures, la requête s’exécute en ... 15 ans ? 150 ans ? Je n'ai pas attendu pour vérifier...

Le modèle conceptuel de SQL prévoit de limiter la portée des requêtes en passant par les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes.

Sans doute ne connaissez vous pas le concept de vues indexées ou vues matérialisées....

Citation:

La performance n'est pas au rendez-vous. Je soupçonne les VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE des requêtes et non pas les perfs.

J'en reviens donc à ce que je disais plus haut. Tant que SQL n'autorise pas de WHERE dans le CREATE INDEX ni l'ouverture d'un index comme une table (figurer dans une clause SELECT), il sera condamné à rester aux volumes des années 90 (fichiers sécu, impôts et douanes américaines) mais ne pourra pas s’accommoder des volumes d'aujourd'hui.

Révisez vos jugements hâtifs et travaillez avec un vrai SGBDR !!!

A +
06/08/2018, 19h06
pachot

Bonjour,

>> théorie des ensembles qu'on a tous appris en 6eme
On va un peu plus loin quand on y ajoute des notions de transaction, cohérence de données,... La base mathématique de l'algèbre relationnelle est à mon avis la raison pour laquelle elle dure plus longtemps que les autres modes (des souvenirs des SGBDOO?) est n'est pas liée à l'époque ou au volume.

>> NoSQL ... pour faire sauter les goulots d'étranglement de SQL
Le retour aux modèles hierarchiques (car pas de jointure) et L3G (procédural) a été nécessaire pour des cas très particulier. Un peu comme certaines applis ont toujours des modules en assembleur pour des parties très critiques en performance. Ces use-cases ont été intégrés dans les SGBDR (objet-relationnel, XML, JSON,...).

>> acrobaties absurdes, non-portables et ALEATOIRES dans leurs comportements
Non, pas aléatoire. Le choix de l'index est fait par l'optimiseur et est complètement déterminé par les moyens d'accès et des statistiques. C'est complètement deterministic, et c'est le seul moyen correct d'avoir un accès performant et prédictible sans avoir à coder chaque cas particulier.

>> index avait été désynchronisé
Quel SGBD? Je pensais que la maintenance des index était toujours synchrone.

>> VIEWS de n'avoir été implémentées que pour simplifier la SYNTAXE
Les vues c'est ni pour la syntaxe ni pour les perfs mais pour une vue logique indépendante de l'implémentation physique

>> les VIEWS mais aussi géniales soient elles, ce ne sont pas des indexes
Les vues matérialisées, elles sont très similaires: stockage redondant, synchrone ou asnychrone, optimisé pour certains types de requêtes.

>> WHERE dans le CREATE INDEX
ça existe sur plusieurs SGBD, pas forcément nécessaire sur d'autres (car partitionnement, materialized views, storage index). Mais surtout, c'est souvent le partitionnement qui répond au besoin d'indexation partiel. La taille d'un index B-Tree n'impacte pas (ou très peu - une page de plus à lire en cache) la performance d'accès par index.
Au passage, Oracle n'implémente pas les index partiels mais l y a des moyens de faire la même chose (cf. https://blog.dbi-services.com/postgr...ess-paths-iii/)

Maintenant, concrètement, cette requête sur 300 milliards de lignes:
- si on veut récupérer 10 lignes sur les 300M un index B-Tree est parfait pour ça. Disons au pire 5 branches d'index à lire puis 10 accès à la table. 15 x 8 millisecondes si rien n'est en cache et stocké sur un vieux disque mécanique. C'est moins que la latence réseau du 'client situé de l'autre coté de la planète'
- si c'est 1000 lignes, 10000 c'est linéaire. L'accès par index est proportionnel au nombre de lignes lues, pas à la taille de la table
- si on veut récupérer 10 milliards de lignes, pas besoin d'index. Full Table Scan ira beaucoup plus vite. Là ça dépend de la taille de la table et non plus du nombre de lignes retournées.
- 100000 lignes: covering index peut être utile (plus besoin d'aller voir la table pour chaque ligne)
- 500000 lignes: partitionnement. De toute façon, une table de plusieurs millions de lignes devrait être partitionnée déjà pour des raisons de performance.

C'est des exemples mais les SGBD se sont adaptés depuis longtemps (~ 20 ans) à ces volumes avec partitionnement, parallel query, compression,... Les SGBD les plus puissants on aussi du columnar store, storage index, pour ces use cases. Et un optimiseur qui va choisir le plan optimal en fonction du résultat demandé, car le développeur ne sait pas toujours combien de lignes seront retournées par une requête. cf. exemple de plan adaptif sur Oracle qui parle du point d'inflexion entre accès index v. full scan: https://blog.dbi-services.com/oracle...flexion-point/

Mais bien sûr, tout ce qu'on peut faire avec un L4G comme SQL peut se faire avec un L3G. Mais c'est un effort énorme, surtout si on tient compte de tout le cycle de vie des données (sécurité, disponibilité, backups, troubleshooting,...).

Cordialement,
Franck.
06/08/2018, 19h17
pachot

Citation:

Envoyé par SQLpro

Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE

Hello SQLPro,

En fait, j'ai toujours été surpris qu'Oracle n'ait pas implémenté ce INCLUDE mais d'une part j'en ai rarement vu le besoin. Et la raison est probablement que d'autres optimisations qui sont là depuis longtemps remplissent un peu le même rôle: https://blog.dbi-services.com/coveri...d-branch-size/

Cordialement,
Franck.
06/08/2018, 23h00
commandantFred
Citation:
Envoyé par SQLpro

je pense que vous êtes un peu à côté de la plaque... Personnellement j'ai plus d'une vingtaines de clients qui ont des bases de plusieurs dizaines de To (SQL Server)... La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE
La plupart des grands éditeurs (IBM, Oracle, MS) ont intégrés des technologies mature venant du NoSQL comme (je parle pour SQL Server) :

les types objets, notamment : XML, geometry, geography, JSON...
la modification à chaud des structures de données (pas de blocage des données des tables en cours de restructuration)
la création/reconstruction à chaud des index (pas de blocage des données lors de la création et la maintenance des index)
Le partitionnement des tables
la réplication des données entre divers noeuds (7 mécanismes différents dans SQL Server
la haute disponibilité des nœuds (à na pas confondre avec la réplication des données)
la compression des données et index
les tables "in memory"
les procédures stockées compilées en mode natif (C)
l'indexation verticale ("columnstore")
l'indexation des documents électroniques (type bases documentaire NoSQL)
les vues indexées
l'indexation sémantique (genre "elastic search")
les tables de nœuds et d'arêtes ("graph database")

Tout ceci est disponible dans SQL Server... Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...
un Seul SGB NoSQL est capable de faire plusieurs de ces choses : Cosmos DB... et je vous laisse deviner qui en est l'éditeur !

À lire : https://blog.developpez.com/sqlpro/p...l-a-tout-faire

A +
Ok, je viens d'apprendre des choses sur SQL Server. Oracle ne fait pas ça correctement.

Reste que vous présentez ça comme une évidence depuis toujours alors que NoSql s'est développé à une époque où les indexes filtrés étaient impossibles en sql.
Le reste des features est un peu encombrant dans cette conversation.

A eux seuls les indexes filtrés justifient les problèmes d'Oracle (sujet de l'article).
300 milliards de lignes est effectivement un volume auquel j'ai affaire sous Oracle.

EDIT
Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...

On ne développe pas en NoSQL pour cloner les features d'un SGBD concurrent ! Il ne s'agit pas de participer à la grande bataille des SGBD mais de faire tourner un SI qui a ses propres besoins. Ces tâches sont conçues spécifiquement avec une certaine créativité... Si vous me permettez, je n’achèterai sans doute jamais de SGBDR parce que je contourne les limites de ceux qui existent. Bien sûr, je peux me tromper et "tomber" pour SQL server mais je crains un peu de ne plus pouvoir travailler sans ensuite et d'être obligé de demander à mes clients d'ouvrir un compte hotmail pour activer leur SI ...

EDIT
Finalement, les deux grands éditeurs de SGBD se ressemblent. Au début, ils sont sympas et souriants. Ensuite ils vous demandent de payer des choses, puis d'afficher leur logo sur votre porte. Enfin , ils vous expliquent que vous ne seriez rien sans eux et qu'à ce titre, votre boite leur appartient un peu. N'est-ce pas exactement ce qu'on reproche à l'un d'eux ici ?

Alors pour ceux qui ont des doutes sur les performances de SQL sur des grosses tables, un exemple sur une base où je passais par hasard ce matin. Je n'ai changé que les noms de table/schema

La table fait 3.5 Tera, contient 400 millions de lignes:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 SQL> select num_rows,blocks from dba_tables where owner='XXX' and table_name='OP'; NUM_ROWS BLOCKS ---------- ---------- 398327400 236418039 Elapsed: 00:00:00.01 SQL> select blocks,bytes/1024/1024/1024/1024 TB from dba_segments where owner='XXX' and segment_name='OP'; BLOCKS TB ---------- ---------- 238309992 3.5510956
Un requête courante fait un accès par index comme celui-ci:
Code:

1 2 3 4 5 6 7 8 9 10 11 SQL> select sum(length(data_segment)) from "XXX"."OP" where DECODE("REFERENCE",'0',"ENTITY","REFERENCE") between '000931151470664' and '000931181978026'; SUM(LENGTH(DATA_SEGMENT)) ------------------------- 8854698 Elapsed: 00:00:04.03
Donc 4 secondes. Et voici le plan d'exécution avec les statistiques d'exécution:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 SQL> select * from table(dbms_xplan.display_cursor(format=>'allstats last')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ SQL_ID cg9fkkb28t3xs, child number 0 ------------------------------------- select sum(length(data_segment)) from "XXX"."OP" where DECODE("REFERENCE",'0',"ENTITY","REFERENCE") between '000931151470664' and '000931181978026' Plan hash value: 2490914298 ------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | ------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:04.02 | 610 | 608 | | 1 | RESULT CACHE | 4zy76myzu25zg9f8v75dy3awb0 | 1 | | 1 |00:00:04.02 | 610 | 608 | | 2 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:04.01 | 610 | 608 | | 3 | TABLE ACCESS BY INDEX ROWID| OP | 1 | 6 | 604 |00:00:04.01 | 610 | 608 | |* 4 | INDEX RANGE SCAN | AK1_OP | 1 | 6 | 604 |00:00:00.01 | 6 | 4 | -------------------------------------------------------------------------------------------------------------------------------
C'est bien un accès à la table, par index. Seulement quelques pages lues (quelques pages d'index puis une page par ligne). Toutes lues sur disque ici. L'index B-Tree a une hauteur de 3 branches ici. Avec 300 milliard de lignes, il aurait peut-être une hauteur de 4 ou 5 -> juste une ou de page de plus à lire -> impact négligeable sur le temps d'exécution.

Et encore, on n'est pas en parallel query ici, il n'y a aucun partitionnement, aucune compression. On pourrait aller beaucoup plus loin. Et on est dans le cas le pire: rien encache (autant de 'Reads' que de Buffers') et lignes dispersées dans des blocs différents (Buffers=A-rows). C'est une appli qui a plus de 15 ans, utilisée tous les jours et qui tourne sans aucune administration à part rajouter des datafiles, sur un vieux serveur!

Cordialement,
Franck.

09/08/2018, 09h07
SQLpro

Pour continuer dans le sens de Franck Pachot, mais sur du SQL Server, différents extraits d'un audit réalisé sur un ensemble de très grosses bases (plusieurs dizaines de To) :

Procédure ...Exploitation.dbo.Set_Titre_Diffusion_Pour_...

... cette procédure doit être optimisée pour accélérer encore le traitement global du rapprochement.
En effet, elle est appelée de façon itérative par la procédure de rapprochement. Malheureusement, dans le temps imparti, je ne suis pas allé très loin car la création d'index sur la table ScamExImport.dbo.H_SEQUENCE_DIFFUSION_OEUVRE_LINK a pris plus d'une heure : cette table contient près de 200 millions de lignes, un peu dur à traiter pour mon PC.

En créant les deux index suivants, on obtient un bon gain, en passant de plus de 60 secondes et des millions d'IO à 700 millisecondes.
...

En récrivant un peu l'expression du premier SELECT de cette procédure, comme suit :
...

nous sommes alors à 40 ms.

Dans cette partie de l'audit nous sommes avec des tables de plusieurs centaines de million de lignes...

Bref 200 millions de lignes, 700 ms...

Autre extrait du même rapport d'audit :

... on voit clairement dans le plan d'exécution réel (en pièce jointe) un écart d'estimation de cardinalités énorme sur la table #TMP_LISTE_TITRES:
- un premier estimé à 3 555 lignes, en réalité 42 333 128 sur 12 836 boucles
- un deuxième qui amplifie le premier écart, avec toujours 3555 lignes estimées vs. 3 146 806 488 en 954 156 boucles

En effet l'exécution des jointures par boucles imbriquées pour 3555 lignes aurait été efficace.
Mais cet algorithme ne l'est plus lorsque le nombre de lignes à traiter devient plus élevé.

L'écart d'estimation est du à l'expression du filtre de la première CTE, nommée TMP_LISTE_TITRES_CTE :

AND NOT ( @b_est_radio = 1 AND TLT.D_DATE_HEURE_DIFFUSEUR >= '01/01/2009' )

Nous avons tenté une première reformulation en écrivant :

AND (@b_est_radio = 0 OR TLT.D_DATE_HEURE_DIFFUSEUR < '2009101')
AND (@b_est_radio <> 1 OR TLT.D_DATE_HEURE_DIFFUSEUR < '01/01/2009')

Mais comme bien souvent, le OR pose problème. Un remède habituel est d’exploser le OR en UNION, ce qui nous donne :

SELECT d_date_heure_diffuseur, fk_sequence_diffusion, f_Id_Rnd_File, id_titre_repartiteur, fk_Oeuvre_Repartiteur, fk_Oeuvre_Diffuseur
FROM #TMP_LISTE_TITRES TLT
WHERE TLT.F_ID_RND_FILE = 29549
AND @b_est_radio = 0
UNION
SELECT d_date_heure_diffuseur, fk_sequence_diffusion, f_Id_Rnd_File, id_titre_repartiteur, fk_Oeuvre_Repartiteur, fk_Oeuvre_Diffuseur
FROM #TMP_LISTE_TITRES TLT
WHERE TLT.F_ID_RND_FILE = 29549
AND TLT.D_DATE_HEURE_DIFFUSEUR < '20090101'

On passe alors de l'empreinte suivante :

Table 'Liste_SDOD'. Scan count 0, logical reads 27739, physical reads 18, read-ahead reads 70
Table 'D_OEUVRE'. Scan count 0, logical reads 26805
Table 'Worktable'. Scan count 3, logical reads 13918, physical reads 0, read-ahead reads 5190
Table 'Workfile'. Scan count 0, logical reads 0
Table 'R_DIFFUSEUR'. Scan count 1, logical reads 4
Table 'D_SEQUENCE_DIFFUSION'. Scan count 0, logical reads 6739106, physical reads 49, read-ahead reads 24
Table '#TMP_LISTE_TITRES__000000000029'. Scan count 966994, logical reads 23207856
(3298 row(s) affected)
SQL Server parse and compile time : CPU time = 408500 ms, elapsed time = 413230 ms.

A celle-ci :

Table 'Liste_SDOD'. Scan count 0, logical reads 26599
Table 'D_OEUVRE'. Scan count 0, logical reads 26805
Table 'Worktable'. Scan count 3, logical reads 13918
Table 'Workfile'. Scan count 0, logical reads 0
Table 'R_DIFFUSEUR'. Scan count 1, logical reads 4
Table 'D_SEQUENCE_DIFFUSION'. Scan count 0, logical reads 81639
Table '#TMP_LISTE_TITRES__000000000029'. Scan count 8, logical reads 192

SQL Server parse and compile time : CPU time = 203 ms, elapsed time = 687 ms.

Notez juste le nombre de ligne : 3 146 806 488
Vous avez bien lu... 3 milliards 146 millions de ligne dans une table... temps de traitement 687 ms...

Bref lorsqu'un développeur me parle de NoSQL comme étant beaucoup plus rapide, je me marre !!!

A +
09/08/2018, 14h09
commandantFred

Citation:

Envoyé par SQLpro

Pour continuer dans le sens de Franck Pachot, mais sur du SQL Server, différents extraits d'un audit réalisé sur un ensemble de très grosses bases (plusieurs dizaines de To) :
Notez juste le nombre de ligne : 3 146 806 488
Vous avez bien lu... 3 milliards 146 millions de ligne dans une table... temps de traitement 687 ms...

Bref lorsqu'un développeur me parle de NoSQL comme étant beaucoup plus rapide, je me marre !!!

A +

Notez que je ne cherche absolument pas à offenser. Cet article parle de pratiques commerciales contestées. Bien sûr que nous sommes tous concernés par les perfs mais ce n'est pas le sujet de fond.

La question soulevée par cet article est "Peut-on se débarrasser d'un éditeur de SGBD qui a compris que vous ne pouvez pas facilement remplacer son produit parce que vous avez beaucoup développé dessus ?"

La réponse à cette question est complexe et votre approche ne plaide pas pour l'adoption d'une technologie quelconque. D'autant que pour pertinente qu'elle soit , votre démonstration est un gros test unitaire qui ne prouve pas un comportement en charge et je vais développer ces point.

Les 300 milliards de lignes dont j'ai parlé ne sont qu'un exemple de ce qui risque d'arriver quand un développement a sous-évalué la volumétrie (cas fréquent). On apprécie que le serveur "tienne la charge" mais ce n'est certainement pas un exemple à suivre pour autant. Bien sûr qu'il aurait mieux valu faire en sorte que la table n'atteigne jamais ce nombre mais à l'époque du développement, cela n'avait pas été anticipé. On ne pouvait pas prévoir cette évolution.

Maintenant, s'il n'y a pas d'autre moyen, il faudra développer une solution alternative. Mais si votre SGBD a doublé son prix entretemps, vous n'êtes pas très chaud pour accroître votre dépendance à son égard.

Ce n'est pas le nombre millisecondes ou de lignes que je retiens de votre échange. C'est plutôt l'arrogance avec laquelle vous assénez un test tellement complexe que personne ne va le reproduire (sans compter tous ceux qui ne le comprennent pas).

Je suis un projet pour un très grand compte qui ne relève pas du back-office mais plutôt d'un process industriel où on stocke des valeurs et des mesures (floats) et où le volume dépasse souvent le milliard de lignes.
Un concurrent propose une solution basée sur le SGBD que vous défendez et perd régulièrement tous les appels d'offre. Je sais pourquoi je remporte à chaque fois. Le client est très regardant sur la dépendance aux éditeurs. C'est même une partie importante de son métier. C'est pourquoi je me suis permis d'intervenir sur ce thread. En termes de perfs, je n'obtiens jamais vos chiffres mais je me débrouille pas mal avec des tables temporaires. C'est pourquoi j'ai cité le problème des indexes partiels.

En tous cas. Je n'ai pas changé d'appréciation sur SQL Server suite à cette discussion. Il est sans doute le plus rapide mais... comme avec les autres grands éditeurs, vous l'adoptez comme une religion et ne pouvez plus rien faire d'autre que de défendre votre choix par la suite. Dommage pour les développements qui ne correspondront jamais à ce profil.
12/11/2018, 13h16
Stan Adkens

2 pièce(s) jointe(s)

Le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle

Le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle
Dans des efforts de la société de se séparer des produits Oracle

Amazon, leader du commerce électronique à l’échelle mondiale et l’un des géants de l’acronyme GAFAM (Google, Apple, Facebook, Amazon et Microsoft), qui au départ était spécialisé dans la distribution des produits divers en ligne, est aujourd’hui l’un des leaders du marché du cloud computing, à cause de ses prouesses en la matière. Depuis quelques années, la société a fait savoir que d’ici 2020, elle se séparerait des produits Oracle pour faire migrer ses bases de données Oracle vers sa propre technologie de bases de données.

Ce processus de migration des données d’Amazon vers sa technologie en nuage est en très bonne voie, c’est ce que nous apprend un article de Bloomberg publié le vendredi dernier selon lequel Amazon aurait franchi une nouvelle étape dans l'élimination des logiciels d'Oracle qui ont longtemps aidé le géant du commerce électronique à gérer ses activités de vente au détail. En effet, le secteur de consommation de la société a désactivé son entrepôt de données Oracle après avoir migré les données du secteur vers son infrastructure en nuage.

Pièce jointe 426328

En effet, Amazon est devenu un concurrent de taille de son fournisseur Oracle depuis que la société s’est lancée dans le développement de nombreux produits concurrents tels que Redshift, Aurora et DynamoDB.

Cependant, les raisons d’abandon des produits d’Oracle par Amazon qui s’était toujours satisfait dans l’utilisation des produits Oracle sont de deux ordres. La première raison, Amazon considère que la technologie de base de données de son fournisseur n’est plus capable d’évoluer pour suivre l’élargissement des produits et services que la société offre à sa clientèle. La seconde raison s’explique par les frais de licence exorbitants qu’impose Oracle à ses clients et la technique de vente agressive adoptée par le spécialiste en base de données sur site.

L’annonce des nouveaux progrès d’Amazon dans ses efforts d’abandonner définitivement l’utilisation des SGBD et des services d’Oracle a été faite, vendredi dernier, par Andy Jassy, directeur général d'Amazon Web Services, selon Bloomberg. Il a, par ailleurs, profiter de l’occasion pour répondre à la moquerie du président exécutif et directeur de la technologie d’Oracle Corporation, Larry Ellison, qui avait, le mois dernier, ridiculisé le géant du commerce électronique d’utiliser les bases de données Oracle pour suivre les transactions et stocker des informations, alors qu’il vend des logiciels concurrents.

« Dans le dernier épisode de « uh huh, keep talkin’ Larry, », le secteur de consommation d'Amazon a désactivé son entrepôt de données Oracle le 1er novembre et est passé à Redshift », a écrit Jassy dans un tweet. D'ici fin 2018, Amazon cessera d'utiliser 88 % de ses bases de données Oracle, y compris 97 % de ses bases de données stratégiques, a-t-il ajouté.

Pièce jointe 426322

Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle. Cependant, le processus de migration des données vers la technologie d’Amazon lancé le mois dernier ne s’est pas déroulé de façon régulière au départ. En effet, selon un article de CNBC, publié le 23 octobre, le premier jour du démarrage du processus de migration, alors que l’entreprise rencontrait déjà des soucis majeurs liés au site web qui ralentissaient les ventes, elle a dû également faire face à un problème technique dans l’un des plus grands entrepôts de l’Ohio, qui a entrainé des milliers de retards de livraison.

Amazon n’est pas le seul client d’oracle qui a décidé d’abandonner les produits du fournisseur Oracle. SAP SE, fournisseur de bases de données et d'applications tente aussi de se séparer d'Oracle, après avoir acquis plusieurs sociétés qui utilisent des produits Oracle. SAP SE est par ailleurs en train de faire migrer ses filiales vers son propre logiciel.

La société d'exploration pétrolière et gazière Halliburton, le fabricant de jouets Mattel et le fournisseur d'électricité Edison Southern California, ont également rejeté, en mai dernier, les offres de services cloud proposées par Oracle.

Source : Bloomberg

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Oracle arrivera-t-il à récupérer les clients perdus ou à se faire de nouveaux grâce à son service cloud public ?

Voir aussi

:fleche: Amazon envisage d'abandonner complètement les SGBD et services d'Oracle d'ici 2020, Oracle serait incapable de répondre à ses besoins de performance
:fleche: Un problème technique affecte un entrepôt d'Amazon, suite à la migration de bases de données Oracle, vers sa propre technologie de base de données
:fleche: Selon Larry Ellison, les nouvelles technologies cloud d'Oracle ont vingt ans d'avance sur celles d'Amazon, partagez-vous cet avis ?
:fleche: Oracle renforce son offre Cloud avec 24 nouveaux services, pour mieux concurrencer AWS
:fleche: Les techniques de vente agressives d'Oracle s'avèrent contre-productives, elles ont tendance à chasser certains clients
12/11/2018, 15h24
darklinux

Le moment de vérité sera lors du black friday ... soit cela tient et Oracle est mort, soit ça craque et Bezos a l' air fin . C 'est quitte ou double.
12/11/2018, 16h59
Mat.M

Citation:

Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle.

étant donné qu'on n'est jamais mieux servi que par soi-même ça évite à Amazon de dépenser des milliions dans des licences Oracle :mrgreen:

Remarquez certains "gros machins" comme par exemple l'administration française ou des grosses entreprises devraient prendre l'exemple
12/11/2018, 17h23
CinePhil

Citation:

Remarquez certains "gros machins" comme par exemple l'administration française ou des grosses entreprises devraient prendre l'exemple

Il est fortement question que l'ERP dédié à l'enseignement supérieur que nous utilisons abandonne Oracle au profit de PostgreSQL... à cause du coût des licences.
La décision et le début de la migration devrait intervenir en 2019. Mais ce n'est pas un petit chantier.
15/11/2018, 15h28
escartefigue

Citation:

Envoyé par SQLpro

La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE

Pour info, DB2 for Z/OS le propose aussi.
Il me semble depuis la V11

EDIT : non c'est depuis la V10 ;)
15/11/2018, 21h42
pachot

Citation:

Envoyé par escartefigue

Pour info, DB2 for Z/OS le propose aussi.
Il me semble depuis la V11

EDIT : non c'est depuis la V10 ;)

L'important, ce n'est pas les fonctionalités implémentées, mais les solutions à des problèmes. Oracle n'a pas d'index couvrant, mais n'en a probablement pas besoin car d'autres fonctionnalités répondent au mêmes besoins (compression prefixe dans les branches, Index Only access path,...)
29/11/2018, 10h55
Stan Adkens

1 pièce(s) jointe(s)

Amazon aura supprimé toutes les bases de données Oracle d'ici la fin 2019, déclare le chef AWS

D’ici fin 2019, Amazon aura complètement abandonné les bases de données d’Oracle
Selon le PDG d’Amazon Web Services

Commencée il y a 4 à 5 ans, la migration d’Amazon vers ses propres infrastructures continue et serait en voie de se terminer. Selon CNBC, la transition serait complètement achevée d’ici fin 2019 en ce qui concerne les bases de données, d’après les déclarations du PDG d’Amazon Web Services, Andy Jassy. En août dernier, Amazon a annoncé qu’il envisageait d'abandonner complètement les SGBD et services d'Oracle d'ici 2020. En effet, l’émergence d'Amazon en tant que fournisseur majeur de technologie de centre de données a transformé un grand nombre de ses fournisseurs de longue date, y compris Oracle, en rivaux redoutables.

Certaines raisons ont emmené Amazon à vouloir abandonner les produits Oracles et à migrer vers ses propres produits concurrents. En effet, selon le géant du commerce de détail en ligne, la technologie de base de données de son fournisseur n’est plus capable d’évoluer pour suivre l’élargissement des produits et services qu’Amazon offre à sa clientèle.

Amazon doit cette performance à l'expansion d'Amazon Web Services qui lui a, par ailleurs, permis de surclasser Alphabet en début d’année pour devenir la deuxième entreprise cotée en bourse la plus importante au monde. Au second trimestre de cette année, AWS a enregistré une croissance de 49 % et en septembre dernier, Amazon a franchi le cap des 1000 milliards de dollars en capitalisation boursière, un mois après que le géant Apple ait réalisé cet exploit, alors que les résultats d’Oracle stagnent et les actions continuent de chuter.

Aussi, Amazon abandonne les produits Oracle, comme d’autres entreprises l’ont fait, à cause des frais de licence exorbitants qu’impose Oracle à ses clients et la technique de vente agressive adoptée par le fournisseur.

Pièce jointe 430896

Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle. Il a développé également des produits concurrents, notamment Redshift, Aurora et DynamoDB. En début novembre, le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle après avoir migré les données du secteur vers son infrastructure en nuage, notamment vers Redshift.

Amazon a réitéré sa volonté d’abandonner les produits Oracle, selon un article de CNBC du mercredi dernier. Selon le PDG d’Amazon Web Services, la migration se passe plutôt bien du côté des bases de données. D’ici la fin de cette année, la quasi-totalité des bases de données d'Amazon qui fonctionnaient sur Oracle seront plutôt sur une base de données Amazon, selon Jassy. « Nous avons pratiquement terminé d'abandonner Oracle du côté de la base de données », a déclaré Jassy mercredi à Jon Fortt de CNBC, lors d'une interview. « Et je pense que fin 2019 ou mi-2019, nous aurons terminé. », a-t-il ajouté.

Cette migration est à la base d’une certaine hostilité entre le géant mondial du commerce électronique de détail et le leader des bases de données sur site. La guerre des mots a commencé avec le lancement d’Aurora, le service de base de données relationnelle d’Amazon ainsi qu’un outil permettant aux entreprises de déplacer des bases de données vers le cloud qui visent le marché d’Oracle et qui attitreraient déjà certains de ses clients.

Mais cela n’empêche pas Amazon de continuer à réduire sa dépendance d’Oracle pour ses besoins en données et d’utiliser plutôt ses propres services. 88 % des bases de données Amazon qui fonctionnaient sur Oracle le seront sur Amazon DynamoDB ou Amazon Aurora d’ici janvier, a déclaré Jassy. 97 % des « bases de données stratégiques » fonctionneraient sur DynamoDB ou Aurora d'ici la fin de l'année, a-t-il ajouté.

Le mouvement d’abandon des produits et services d’Oracle s’étend à plusieurs autres entreprises. Le fournisseur de bases de données et d’applications, SAP SE, est en train de faire migrer progressivement ses données vers ses propres infrastructures.

La société d'exploration pétrolière et gazière Halliburton, le fabricant de jouets Mattel et le fournisseur d'électricité Edison Southern California, ont également rejeté, en mai dernier, les offres de services cloud proposées par Oracle.

Source : CNBC

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Pensez-vous qu’Amazon pourra tenir ce calendrier de migration ?

Voir aussi

:fleche: Un problème technique affecte un entrepôt d'Amazon, suite à la migration de bases de données Oracle, vers sa propre technologie de base de données
:fleche: MariaDB rachète la technologie de base de données distribuée Clustrix, pour concurrencer Oracle RAC
:fleche: Oracle Autonomous Transaction Processing : Oracle renforce sa base de données cloud autonome, avec un nouveau service de traitement transactionnel
:fleche: Revenus cloud : les actionnaires d'Oracle lui reprochent d'avoir livré des communiqués trompeurs, un recours collectif se prépare contre la société
:fleche: Amazon publie une préversion de Corretto, une distribution gratuite d'OpenJDK, qui devrait devenir la distribution par défaut sur Amazon Linux 2
29/11/2018, 11h19
kilroyFR

Petite guguerre d'egos entre eux, c'est de la comm legitime, ils se trouvent concurrents.
Est-ce que pour autant ca poussera un client oracle lambda a passer a dynamodb ou autre, pas certain; car les memes problemes de couts, hebergement etc restent probables (on l'a vecu sur tentative de passage vers sqlserver).
On est toujours chez oracle, ca rassure nos clients plutot que de mettre des BDD autres (mongodb ou autre).
Sur des projets a plusieurs millions, les licences sont une paille (comme pour les vendeurs de voitures ou de canapés, les reductions appliquées (80% pour nos projets)) (et la garantie de faire migrer des données 10-20 ans apres est reelle puisqu'on l'a vecu sur plusieurs dizaines de projets sans se poser de questions tout en tirant partie des nouvelles fonctionnalités/gains de perfs).
29/11/2018, 11h29
rawsrc

Citation:

Envoyé par Stan Adkens

Oracle a réitéré sa volonté d’abandonner les produits Oracle

Enfin !!! Il serait temps :ptdr:

:dehors:
29/11/2018, 11h31
pachot

Citation:

Envoyé par kilroyFR

(et la garantie de faire migrer des données 10-20 ans apres est reelle puisqu'on l'a vecu sur plusieurs dizaines de projets sans se poser de questions tout en tirant partie des nouvelles fonctionnalités/gains de perfs).

Oui. Et vers n'importe quelle platforme, Cloud ou on-premises. Passer sur des solutions propiétaires AWS impose de rester sur le cloud.
29/11/2018, 13h32
kilroyFR

Citation:

Envoyé par pachot

Passer sur des solutions propiétaires AWS impose de rester sur le cloud.

Oui (petite parenthese) vecu a titre personnel dans une association (internationale) a laquelle j'appartiens.
On est passé d'une solution avec hebergement classique (serveurs chez BigDaddy) a plusieurs centaines de $ a l'année a une solution complete toute hebergée dans AWS a 10 000 $ sur 3 ans.
Maintenant on est ferré chez eux et finalement toutes les technos et autres elements technos mis en avant sur lequel nos admins ont bavé ne sont pas exploités (faut de temps et d'investissement perso pour s'y former).
Ca nous coute un bras par an et pour le moment on est dans une fuite en avant. Une gabegie financiere tout ca pour s'etre fait berné par des potentiels besoins (qu'on n'avait pas et qu'on n'aura jamais). Tous les ans les membres de l'assoc (plusieurs 10aine de milliers de membres heureusement se cotisent pour financer le monstre).
Plus aucun autonomie; on maitrisait tout, on ne maitrise plus rien. Amazon ne vaut pas mieux que les autres.
16/10/2019, 13h41
Stéphane le calme

2 pièce(s) jointe(s)

Migration achevée : Amazon’s Consumer Business a déconnecté sa dernière base de données Oracle
Migration achevée : Amazon’s Consumer Business a déconnecté sa dernière base de données Oracle,
conformément à son calendrier

Amazon, qui au départ était spécialisé dans la distribution des produits divers en ligne, est aujourd’hui l’un des leaders du marché du cloud computing. Depuis quelques années, la société a travaillé pour préparer sa séparation des produits Oracle avec dans un premier temps une migration de ses bases de données Oracle vers sa propre technologie de bases de données. Il faut préciser qu'Amazon a développé des produits concurrents à l'instar de Redshift, Aurora et DynamoDB. En début novembre, le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle après avoir migré les données du secteur vers son infrastructure en nuage, notamment vers Redshift.

Les raisons d’abandon des produits d’Oracle par Amazon qui s’était toujours satisfait dans l’utilisation des produits Oracle sont de deux ordres. La première raison, Amazon considère que la technologie de base de données de son fournisseur n’est plus capable d’évoluer pour suivre l’élargissement des produits et services que la société offre à sa clientèle. La seconde raison s’explique par les frais de licence exorbitants qu’impose Oracle à ses clients et la technique de vente agressive adoptée par le spécialiste en base de données sur site.

Oracle a enregistré déjà des départs de clients à cause de ses tactiques de vente agressives, menaçant les clients de ses logiciels sur site avec des audits d'utilisation potentiellement coûteux et proposant fortement la migration vers sa solution cloud comme une panacée à leurs problèmes. Par ailleurs, d’après les résultats d’une étude réalisée en avril par Jefferies & Company, Oracle s’est fait surclasser sur le marché des infrastructures et plateformes en tant que services (IaaS / PaaS) par Amazon, le leader du marché du cloud, Microsoft et autres.

En réponse à la moquerie du PDG d’Oracle Corporation, Larry Ellison, qui visait ces efforts d'Amazon, Andy Jassy, directeur général d'Amazon Web Services, a déclaré en novembre : « Dans le dernier épisode de "oh oh, cause toujours Larry", le secteur de consommation d'Amazon a désactivé son entrepôt de données Oracle le 1^er novembre et est passé à Redshift. D'ici fin 2018, Amazon cessera d'utiliser 88 % de ses bases de données Oracle (y compris 97 % de ses bases de données systèmes critiques) pour se tourner vers Aurora et DynamoDB ».

Pièce jointe 510285

Calendrier respecté

Dans un entretien avec Jon Fortt de CNBC, Jassy a indiqué en novembre que « Nous avons pratiquement terminé d'abandonner Oracle du côté de la base de données ». Il a précisé qu'il pense que « fin 2019 ou mi-2019, nous aurons terminé ». Il a fallu attendre le mois d'octobre 2019 pour que Jeff Barr, Chief Evangelist for AWS, déclare : « Je suis heureux d'annoncer que cet effort de migration de base de données est maintenant terminé. L’activité grand public d’Amazon vient de désactiver sa dernière base de données Oracle (certaines applications tierces sont étroitement liées à Oracle et n’ont pas été migrées) ».

Plus de 100 équipes Amazon’s Consumer business ont participé à la migration. Cela inclut des marques et des sites réputés destinés aux clients, tels que Alexa, Amazon Prime, Amazon Prime Video, Amazon Fresh, Kindle, Amazon Music, Audible, Shopbop, Twitch et Zappos, ainsi que des équipes internes telles qu'AdTech, Amazon Fulfillment Technology, Consumer Payments, Customer Returns, Catalog Systems, Deliver Experience, Digital Devices, External Payments, Finance, InfoSec, Marketplace, Ordering, et Retail Systems.

Barr note que « Nous avons migré 75 pétaoctets de données internes stockées dans près de 7 500 bases de données Oracle vers plusieurs services de base de données AWS, notamment Amazon DynamoDB, Amazon Aurora, RDS (Amazon Relational Database Service) et Amazon Redshift. Les migrations ont été effectuées avec peu ou pas de temps d'arrêt et ont couvert 100 % de nos systèmes propriétaires. Cela inclut les charges de travail complexe d'achat, de gestion de catalogue, de traitement des commandes, de comptabilité et de diffusion vidéo en continu ».

Amazon a suivi les coûts et les performances et assure avoir obtenu les résultats suivants :
- Réduction des coûts : Amazon a réduit les coûts de ses bases de données de plus de 60 % en plus du taux fortement réduit que l'entreprise a négocié en fonction de sa taille. Les clients signalent régulièrement des économies de coûts de 90 % en passant d'Oracle à AWS.
- Amélioration des performances : la latence de ses applications destinées aux consommateurs a été réduite de 40 %.
- Frais généraux d'administration : le passage aux services gérés a réduit les frais généraux d'administration de la base de données de 70 %.
Pièce jointe 510289

« La migration a donné à chaque équipe interne la liberté de choisir le service de base de données AWS sur mesure, qui répond le mieux à ses besoins, et de mieux contrôler son budget et son modèle de coûts. Les services à faible temps de latence ont été migrés vers DynamoDB et d'autres bases de données non relationnelles hautement évolutives telles que Amazon ElastiCache. Les charges de travail relationnelles transactionnelles avec des exigences élevées en matière de cohérence des données ont été transférées vers Aurora et RDS; les charges de travail analytiques ont été migrées vers Redshift, notre entrepôt de données dans le cloud ».

Amazon a même fait une petite vidéo pour enregistrer la fermeture de la dernière base de données Oracle et a célébré le moment :

https://www.youtube.com/watch?v=9yBP...ature=youtu.be

Voici quelques exemples des migrations effectuées dans les équipes Amazon :
- Advertising : après la migration, cette équipe a été en mesure de doubler la taille de son parc de bases de données (et son débit) en quelques minutes afin de s'adapter au trafic de pointe, grâce à Amazon Relational Database Service (Amazon RDS), un effort d'intensification qui lui aurait pris des mois autrement. Amazon RDS vous permet d'installer, de gérer et de mettre à l'échelle facilement une base de données relationnelle dans le cloud. Ce service offre une capacité économique et ajustable ainsi qu'une automatisation des tâches administratives chronophages, telles que l'allocation de matériel, le paramétrage de bases de données, l'application de correctifs et les sauvegardes. Vous pouvez ainsi vous concentrer librement sur vos applications, afin de leur donner les performances rapides, la haute disponibilité, la sécurité et la compatibilité dont elles ont besoin.
- Buyer Fraud : cette équipe a déplacé 40 To de données en une heure d'indisponibilité et a obtenu des performances identiques, voire meilleures, à un coût deux fois moindre, générées par Amazon Aurora. Amazon Aurora est une base de données relationnelle compatible avec MySQL et PostgreSQL créée pour le cloud, qui associe les performances et la disponibilité des bases de données d’entreprises traditionnelles à la simplicité et à la rentabilité des bases de données open source.
- Financial Ledger : cette équipe a déplacé 120 To de données, réduit le temps de latence de 40 %, réduit les coûts de 70 % et réduit les frais généraux de 70 %, le tout alimenté par DynamoDB. Amazon DynamoDB est une base de données de clés-valeurs et de documents, offrant des performances de latence de l'ordre de quelques millisecondes, quelle que soit l'échelle. Il s'agit d'une base de données multirégion et multimaître et durable entièrement gérée avec un système intégré de sécurité, de sauvegarde, de restauration et de mise en cache en mémoire pour les applications à l'échelle d'Internet. DynamoDB peut traiter plus de 10 mille milliards de demandes par jour et prend en charge des pics de 20 millions de demandes par seconde.
- Wallet : cette équipe a migré plus de 10 milliards d'enregistrements vers DynamoDB, ce qui a permis de réduire le temps de latence de 50 % et les coûts opérationnels de 90 %.
Source : Amazon

Et vous ?

:fleche: Que pensez-vous de cette décision d'Amazon ?
:fleche: Que pensez-vous des choix techniques sur mesure pour les différents services ?

Voir aussi :

:fleche: Amazon France répercute la « taxe Gafa » sur ses tarifs aux entreprises françaises comme il l'avait annoncé il y a quelques mois
:fleche: Amazon présente Sidewalk, un nouveau protocole sans fil à longue portée pour vos appareils connectés, dans un contexte où l'entreprise a reconnu avoir collecté des données de dispositifs IdO
:fleche: Jeff Bezos : Amazon est en train de rédiger ses propres lois sur la reconnaissance faciale pour les soumettre aux législateurs fédéraux, espérant qu'ils adopteront une grande partie de son projet
:fleche: Amazon annonce sa nouvelle gamme d'appareils Echo disponible en précommande et prête la voix de l'acteur américain Samuel L. Jackson et d'autres célébrités à Alexa
16/10/2019, 15h35
SQLpro

Citation:

Envoyé par commandantFred

Ok, je viens d'apprendre des choses sur SQL Server. Oracle ne fait pas ça correctement.

Il est difficile de dire cela. Chaque SGBDR a des spécificités et fait plus ou moins biens les choses. Par exemple Oracle sait très mal gérer les collations (les fameux... fumeux ??? ... NLS) et tente enfin de respecter la norme SQL avec une solution embryonnaire à base de collation depuis peu, mais manquant singulièrement des principales "features" sur le sujet, tandis que MS SQL Server fait cela depuis la version 7 datant de plus de 20 ans et implémentant près de 4 000 collations différentes.
À contrario, MS SQL Server est incapable de concevoir des contraintes UNIQUE multi NULLs alors que l'unicité ne peut porter que sur les valeurs !

Citation:

Reste que vous présentez ça comme une évidence depuis toujours alors que NoSql s'est développé à une époque où les indexes filtrés étaient impossibles en sql.

Les index filtrés existent dans certains SGBDR depuis près de 20 ans. Le NoSQL depuis moins de 10 ans....

Citation:

Le reste des features est un peu encombrant dans cette conversation.

A eux seuls les indexes filtrés justifient les problèmes d'Oracle (sujet de l'article).
300 milliards de lignes est effectivement un volume auquel j'ai affaire sous Oracle.

EDIT
Avec le NoSQL il faut plusieurs moteurs et plusieurs bases pour gérer tout cela à la fois...

On ne développe pas en NoSQL pour cloner les features d'un SGBD concurrent ! Il ne s'agit pas de participer à la grande bataille des SGBD mais de faire tourner un SI qui a ses propres besoins. Ces tâches sont conçues spécifiquement avec une certaine créativité... Si vous me permettez, je n’achèterai sans doute jamais de SGBDR parce que je contourne les limites de ceux qui existent. Bien sûr, je peux me tromper et "tomber" pour SQL server mais je crains un peu de ne plus pouvoir travailler sans ensuite et d'être obligé de demander à mes clients d'ouvrir un compte hotmail pour activer leur SI ...

Il n'y a aucune activation pour exploiter un serveur MS SQL Server. En effet, par sécurité et en cas d'urgence, vous devez pouvoir récupérer vos données et être opérationnel sur un SGBDR sans être contraint ni par une clef de licence, ni par un processus de validation par Internet. Mais il faudra penser à régulariser cela après coup, car de mémoire, vous pouvez rester dans cet état pendant 180 jours, mais pas au dela;..

Citation:

EDIT
Finalement, les deux grands éditeurs de SGBD se ressemblent. Au début, ils sont sympas et souriants. Ensuite ils vous demandent de payer des choses, puis d'afficher leur logo sur votre porte. Enfin , ils vous expliquent que vous ne seriez rien sans eux et qu'à ce titre, votre boite leur appartient un peu. N'est-ce pas exactement ce qu'on reproche à l'un d'eux ici ?

De toute façon, avec 300 milliards de ligne, que vous soyez dans du "soit-disant" libre (et en matière de SGBD il n'y en as pas de vraiment libre à ma connaissance), ou pas, vous aurez du mal à en sortir en claquant dans les doigts.... Un peu comme si vous vouliez déménager le Louvre ou la BNI du jour au lendemain!

A +
16/10/2019, 16h21
darklinux

C ' est un vrai désaveux pour Oracle , non seulement Amazon à réussi à le faire , mais de surcroit , cela prouve que le SGBD est solide au possible
16/10/2019, 18h38
rawsrc

La vidéo est terrible en matière de pub pour Oracle. C'est carrément un enterrement en bonne et due forme.

Toute l'équipe sabre le champagne quand on voit en gros plan Oracle stopped. C'est juste énorme !

C'est dire le niveau d'exaspération auquel les équipes ont dû faire face.

La question est de savoir si les p'tits gars d'Oracle au siège ont fait eux aussi péter le ~~Champagne~~, non le Champomy (c'est plus abordable, maintenant) quand l'ultime paiement d'Amazon est tombé sur le compte.

Je me pose la question quand même, comment une société de la taille d'Oracle ne voit pas la tempête venir ? Parce que question changement de politique commerciale, c'est zéro pointé pour l'instant.
Et puis, il faudrait songer sérieusement à lui faire prendre sa retraite au vieux Larry (75 ans maintenant). Le monde bouge, et à 75 balais, on peut quand même s'imaginer que le gars est un poil rouillé, non ?
Tiens, je n'ai pas regardé le board d'Oracle, va savoir c'est peut-être un EHPAD :aie:
16/10/2019, 19h25
SQLpro

Citation:

Envoyé par rawsrc

… Je me pose la question quand même, comment une société de la taille d'Oracle ne voit pas la tempête venir ? Parce que question changement de politique commerciale, c'est zéro pointé pour l'instant.

Il faut relire l'excellent ouvrage intitulé "Quelle est la différence entre Dieu et Larry Ellison" :
https://www.amazon.com/Difference-Be.../dp/0060008768
Pour comprendre pourquoi ce mythomane a conduit sa propre boite à sa perte….
Parmi les faits incroyables et qui montre bien que depuis 2 décennies Oracle est mauvais on aura un éclairage avec ces commentaires :
https://www.scriptol.fr/logiciel/oracle-entreprise.php
L'autre coup de grâce a été donné avec le benchmark TPC- C (benchmark datant de 1992 et totalement obsolète qu'Oracle à interdit au TCP de fermer) avec le chinois Alibaba et son SGBD OceanBase, bâtant le record en doublant les performances….
http://www.tpc.org/tpcc/results/tpcc...ic_results=yes

Citation:

Et puis, il faudrait songer sérieusement à lui faire prendre sa retraite au vieux Larry (75 ans maintenant). Le monde bouge, et à 75 balais, on peut quand même s'imaginer que le gars est un poil rouillé, non ?

Ce n'est plus lui qui dirige…. depuis bien 3 ans

Citation:

Tiens, je n'ai pas regardé le board d'Oracle, va savoir c'est peut-être un EHPAD :aie:

Oracle a aussi perdu le marché du cloud de l'armée américaine au profit de Microsoft et Amazon….

Et on ne compte plus les entreprises qui se débarrassent totalement d'Oracle : l'Oréal, Servier, ...
Même le CIGREF invite ses membres à fuir Oracle….

Bref, la fin d'Oracle serait-elle proche ?

A +
18/10/2019, 06h35
CoderInTheDark

Ce qui m'ennuie c'est qui sont entrain d'entrainer Java dans leur chute.

Voir 40 message(s) de cette discussion en une page