GridGain on Highload: où parler des SGBD distribués, en mémoire et open source

Créer de nouvelles fonctionnalités est amusant. Mais comment les tester, si votre produit est un système distribué et que le fonctionnement réel est constitué de nombreux cœurs et disques sur différents serveurs physiques, d'interaction réseau, de pannes matérielles et d'actions utilisateur imprévisibles?

Nous allons vous expliquer comment la nouvelle fonctionnalité Apache Ignite est testée, ce que nous faisons bien et pas si bien:
- pourquoi rencontrons-nous des tests d’intégration et n’aimons-nous pas vraiment unit, mock et XP?
- test d'algorithmes multithreads et distribués
- création d'un plan de test et révision du code
- où percer le plus souvent?

GridGain a autrefois fait don du produit Apache Software Foundation du même nom - maintenant il est connu comme Apache Ignite. Depuis lors, les ingénieurs de GridGain combinent deux rôles - employés d'une entreprise commerciale à but lucratif et développeurs indépendants d'un projet ouvert. Et bien sûr, entre ces rôles se trouvent des relations d'amour et de haine. Lors de la réunion, nous parlerons de la façon dont le développement en Open Source aide et entrave la résolution des problèmes commerciaux.

Nous allons commencer et vous vous joignez.
Du côté de l'open source: Dmitry Pavlov, Apache Ignite Community Manager
Côté affaires: Stanislav Lukyanov de GridGain Customer Success

Vous pouvez sans cesse ajouter des fonctionnalités et corriger des bogues dans le produit, mais tout cela n'a pas de sens si la nouvelle version n'atteint pas l'utilisateur. Et pour sortir une nouvelle version, c'est loin d'être toujours suffisant juste pour lancer l'assemblage et les tests. Et pour la sortie de la version - ce n'est pas du tout la même chose que de démarrer l'assemblage.

Que faire si vous devez prendre en charge de nombreuses versions du produit? Comment faire passer l'utilisateur d'une version à une autre sans surprise? Et qu'est-ce que l'open source a à voir avec ça?

Parlons de la façon dont les changements passent de la lettre de l'utilisateur au service client jusqu'à ce qu'ils reçoivent la version convoitée avec la correction.

Peu importe comment la technologie se développe, une sauvegarde dans les moments difficiles continue de nous sauver les nerfs et parfois de fonctionner. La plate-forme GridGain s'exécute au-dessus du système open source distribué Apache Ignite, où il n'est pas possible de sauvegarder les données. À ce jour, la quantité maximale de données dans le produit client GridGain est de 200 téraoctets à 160 nœuds. Les données sont non seulement stockées, mais également constamment modifiées pour garantir des garanties transactionnelles.

Le manque de capacité à créer des sauvegardes d'un système distribué à une telle échelle a été une pierre d'achoppement pour l'utilisation pratique de notre plate-forme par les grandes entreprises. Le rapport vous apprendra comment nous avons réussi à combler cette lacune.

Nous avons dû apprendre:
- sauvegarder les données sans arrêter l'utilisateur;
- rendre les données de la sauvegarde d'un système distribué cohérentes et transactionnelles;
- rendre les procédures de création et de récupération de sauvegarde résistantes aux changements de topologie à l'aide d'une machine à états finis distribuée;
- implémenter des sauvegardes incrémentielles, occupant un ordre de grandeur moins d'espace;
- restaurer les anciennes sauvegardes de données créées sur une topologie de cluster significativement différente.