Discussion :

[Waldar]

Je crains que la citation de noms de sociétés sur ce forum ne soit pas dans les règles.

Tant qu'il n'y a pas diffamation ça ne pose aucun problème.

Un extrait des règles du forum :

Les insultes et la diffamation envers des individus et sociétés sont sévèrement punies par la loi, y compris sur les forums, et par conséquent interdites et supprimées à vue.

Peu d'entre nous savent en quoi consiste la diffamation. Un rappel :

Il n'est pas besoin que les affirmations soient fausses pour qu'il y ait diffamation. Le seul fait de citer une marque, une société, un individu et de tenir à son égard des propos qui peuvent lui porter préjudice constitue une diffamation, ce qui tombe sous le coup de la loi.

[IndianaAngus]

Si vous prenez RAC, je peux vous conseiller de le prendre en standard ou l'option RAC est offerte alors qu'elle est payante sur une EE (et c'est pas donné). Cela sera bien moins cher mais limité à 4 socket.
On peut faire aussi des snapshots avec ASM indépendamment du matériel ou même des images copy avec RMAN pour switcher très rapidement sur les datafiles en cas de problème + recover des dits datafiles mais ca va doubler votre espace disque utilisé.

Nous avons implémenter une db standy avec une standard edition (le dataguard du pauvre en quelque sorte :-) ), c'est très simple à mettre en place et ca fonctionne très bien. Le seul risque est de perdre les dernières transactions non archivé et non transférer sur le serveur standby, tout dépend de ce que vous êtes prêt à perdre.

[Chris Mad]

Voici ce qu'on peut dire de l'opération Oracle RAC dans la boutique:
- durée de mise en œuvre : 6 mois
- coût de l'opération : 200000€
- coût d'exploitation mensuel : 4000€ chez les remote DBA, sans compter les frais d'hébergement dans le data center
Résultat: les finances sont dans le rouge, on ne peux pas embaucher le/les développeurs dont on aurait VRAIMENT besoin.
Conclusion personnelle : Oracle RAC, c'est fait pour des boites à la santé financière solide , qui n'ont pas besoin d'agilité.
On a foutu de l'argent par les fenêtres.Et en plus pour une boite qui se dit start-up, on passe pour des guignols dans le milieu (pourquoi vous utilise ça? mysql est bien largement suffisant si vous avez besoin de relationnel!!! Si vous avez vraiment besoin de ça c'est que votre design pose problème).
Pour les 4000€ par mois, on a la plus grosse instance Oracle RDS chez AWS : les nerfs!
Entre temps, on a expérimenté MongoDB, le DDD. C'est vers ça qu'on va aller. Ça a beaucoup plus de valeur.
Si c'était à refaire, on ne le ferait pas point barre
Bref profondément dégoûtés

[pachot]

Bonjour Chris Mad,

Ce n'est pas le sujet initial de ce post, mais ce serait intéressant d'en savoir plus sur ce projet. RAC amène plus de complexité (même si en ODA l'installation est beaucoup plus simple) mais on fait ce choix pour répondre à des besoins très pointus: pas d'arrêt de service lors de panne/arrêt de serveur, ajout de nouveau serveur pour suivre l'augmentation de charge, consolidation de plusieurs bases sur plusieurs serveurs.
Ceci n'est pas comparable avec MySQL. Et la protection des transactions offert par Oracle (RAC ou non) n'est pas non plus comparable avec MySQL ni MongoDB.

Bref, difficile de comparer. En relationnel, avec Oracle en cluster (RAC) on répond à des besoins de fiabilité, de disponibillité, de performance, d'exploitation. Evidemment on a des solutions chère et complexe. On ne peut pas comparer le coût d'exploitation avec des approches qui justement s'affranchissent de toutes ces contraintes d'exploitation, sans structurer les données, sans protéger les transactions, etc.

Il est important par contre que les architectes considèrent tout le cycle de vie de l'application lors de leurs choix. Les solutions non structurées apportent beaucoup d'agilité en développement. Mais une fois en production on peut regretter le relationnel qui sécurise les données lors des passages de versions, qui permettent de garder de bonnes performances lorsqu'on interroge les données avec un autre point de vue, etc.

Cordialement,
Franck.

[kangs]

Voici ce qu'on peut dire de l'opération Oracle RAC dans la boutique:
- durée de mise en œuvre : 6 mois
- coût de l'opération : 200000€
- coût d'exploitation mensuel : 4000€ chez les remote DBA, sans compter les frais d'hébergement dans le data center
Résultat: les finances sont dans le rouge, on ne peux pas embaucher le/les développeurs dont on aurait VRAIMENT besoin.
Conclusion personnelle : Oracle RAC, c'est fait pour des boites à la santé financière solide , qui n'ont pas besoin d'agilité.
On a foutu de l'argent par les fenêtres.Et en plus pour une boite qui se dit start-up, on passe pour des guignols dans le milieu (pourquoi vous utilise ça? mysql est bien largement suffisant si vous avez besoin de relationnel!!! Si vous avez vraiment besoin de ça c'est que votre design pose problème).
Pour les 4000€ par mois, on a la plus grosse instance Oracle RDS chez AWS : les nerfs!
Entre temps, on a expérimenté MongoDB, le DDD. C'est vers ça qu'on va aller. Ça a beaucoup plus de valeur.
Si c'était à refaire, on ne le ferait pas point barre
Bref profondément dégoûtés

Une fois les précos nécessaires bien comprises par le système & réseaux, l'installation du grid infra c'est 1h, l'installation du noyau Oracle 1h aussi.
Dans de très gros compte un RAC (partie DBA) ne prend pas plus de 4h en incluant les tests élémentaires.

La durée de mise en oeuvre et son coût sont prohibitifs et plus que anormales, les licences RAC sont plus élevées que les licences single mais c'est normal.

Votre problème n'est pas le RAC, mais votre prestataire !

La mise en oeuvre d'un RAC est simple ! Mais quand il y a un problème il faut vraiment de l'expertise et là je veux bien croire que la résolution puisse être longue.

Ce que vous croyez pouvoir en attendre c'est autre chose, beaucoup inventes ou prennent leur désirs pour des réalités. Dans la mise en oeuvre d'un RAC il est nécessaire que les dev soient impliqués sinon vous risquez fortement d'être déçus lors des incidents (et là pour vous je crains le pire)

[Chris Mad]

Bonjour et merci pour cette réponse. Ci après quelques commentaires.

pas d'arrêt de service lors de panne/arrêt de serveur,

D'un point de vue business, nous estimons et sommes structurés pour "survivre" à un arrêt total de la base pendant 20 minutes (à condition que ça reparte correctement bien sûr)

ajout de nouveau serveur pour suivre l'augmentation de charge

Vu le prix qu'ils nous ont couté, ça ne risque pas de se faire demain ;-)

Et la protection des transactions offert par Oracle

Nous nous sommes penchés sur la question des transactions, mais d'un point de vue conception, notamment avec l'éclairage du Domain Driven Design. Il en ressort que
la notion de transaction découle d'un besoin métier et est très bien modélisée par les notions d'agrégat et de "frontière de transactionnalité". Sans rentrer dans les détails, n'importe quelle base apportant une cohérence transactionnelle permet de soutenir ce genre de design. Les contraintes s'en trouvent le plus souvent grandement relachées, et en conséquence les exigences techniques sont moindres.

sans structurer les données

Pour être plus précis, dans le cas MongoDB, il y a structuration des données, cependant, différentes structurations peuvent exister en même temps.

sans protéger les transactions

La transaction au niveau document est implémentée, et est dans le cas d'un modèle DDD suffisante dans la très grande majorité des cas que nous envisageons.

Il est important par contre que les architectes considèrent tout le cycle de vie de l'application lors de leurs choix. Les solutions non structurées apportent beaucoup d'agilité en développement. Mais une fois en production on peut regretter le relationnel qui sécurise les données lors des passages de versions, qui permettent de garder de bonnes performances lorsqu'on interroge les données avec un autre point de vue, etc.

Justement, en tant que startup, nous avons besoin l'agilité. Les aspects de migration de schéma sont en ce sens un frein. Sur l'aspect performances, c'est justement sur ce point que nous avons mis en place MongoDB à coté d'Oracle, car le modèle de données n'était pas adapté à un autre "regard", ce qui nous a poussé à mettre en place une architecture CQRS pour répondre à nos besoins. Nous avons compris qu'un modèle de donné unique n'était pas satisfaisant.

Cordialement

[Chris Mad]

La durée de mise en oeuvre et son coût sont prohibitifs et plus que anormales

.
Précision : les coûts annoncés tiennent compte du matériel.