Chaque jour, notre système Air Travel Shopping Engine (ATSE) effectue plusieurs millions de recherches d'itinéraires et calcule leur prix. Application la plus critique de Sabre, ATSE fonctionne 24 h/24, et cela 365 jours par an. Même lorsque nous devons effectuer des opérations de maintenance logicielle ou matérielle. Assurer la disponibilité permanente de ce système constitue une priorité.

Dans le passé, ATSE reposait entièrement sur un mainframe pour garantir une haute disponibilité. Afin de réduire nos coûts, nous avons basculer certains modules sur un frontal de serveurs HP Non-Stop Server, qui offrent une disponibilité de 99,999 %. Et pour diminuer les temps de réponse de notre système de recherche d'itinéraires, nous l'avons fait migrer vers un cluster de 45 serveurs Linux/MySQL. Avec plus de 3 milliards de combinaisons possibles, ces recherches nécessitent une puissance de calcul très importante, que les serveurs HP Non-Stop Server ne pouvaient fournir à un coût raisonnable. En effet, les recherches d'itinéraires ne nous apportant pas de revenus directs, il nous fallait trouver un système de base de données fiable, très performant et le moins cher possible.

ATSE est développé en C/C++ et utilise ESQL. Il interroge le cluster MySQL au travers des API C de la base de données. Le cluster MySQL se compose de 45 serveurs quadriprocesseurs 64 bits Itanium 2, équipés de 32 Go de mémoire vive. MySQL 4.0 s'exécute au-dessus de Red Hat Enterprise Linux AS 3.0. La charge est répartie par LVS au niveau du système d'exploitation. Les 72 Go de données du cluster sont stockées dans 267 tables transactionnelles InnoDB, autorisant un verrouillage fin sur chaque enregistrement. Le support des transactions est indispensable, car les données issues des serveurs frontaux HP Non-Stop Server sont synchronisées en permanence avec le cluster. Cela représente 1,5 million de trajets calculés chaque jour à partir de 20 millions de tarifs et règles de tarification.

Pas pour le moment. Nos serveurs HP sont disponibles à 99,999 % et garantissent déjà l'intégrité des données. De plus, MySQL Cluster travaille uniquement en mémoire, alors que nous souhaitons que les données persistent sur disque. En revanche, nous étudions l'intérêt de MySQL Cluster pour diminuer le volume des synchronisations nécessaires entre les serveurs frontaux et le cluster MySQL.

Lorsque nous avons décidé de faire évoluer ATSE vers des serveurs Unix ou Linux, nous avons évalué plusieurs bases de données. Nos tests ont montré que les performances de MySQL étaient aussi bonnes ­ voire parfois meilleures ­ que celles des produits propriétaires. Etant donné le coût de licence largement inférieur de MySQL et notre approche de type cluster, MySQL 4.0 présentait le meilleur rapport performances/fiabilité/prix.

La licence commerciale. Nous ne voulions pas reverser notre code à la communauté open source, car il expose des éléments stratégiques de notre activité. Cette licence nous protège de l'effet viral de la licence GPL et nous offre un support technique professionnel.

Oui. Le faible coût de la licence commerciale de MySQL nous a permis de générer des millions de dollars d'économies. Et vu le nombre de serveurs déployés et nos projets à cinq ans, nous pensons en réaliser d'autres sur le long terme.

Notre application ne reposant pas sur ces mécanismes, nous n'avons pas pris en compte ces critères lors de notre sélection de MySQL. Cependant, MySQL 4.1 propose déjà des sous-requêtes. Et MySQL 5.0 introduira les procédures stockées et les triggers. La couverture fonctionnelle de MySQL s'étend rapidement et permet donc d'envisager son utilisation avec de plus en plus d'applications. D'autant que ses fonctions sont parfaitement standards.

C'est une évolution que nous évaluons très sérieusement pour Sabre Holdings. A la fois pour faire migrer des applications existantes et pour utiliser MySQL sur de nouveaux projets. Nous pensons étendre notre cluster pour atteindre 100 machines ou plus d'ici à la fin de l'année.