Hoewel dit onoverkomelijk en dramatisch lijkt, kan men dit euvel in praktijk vaak verhelpen op voorwaarde dat men hier reeds tijdens de requirements analyse rekening mee houdt. De levensduur en vluchtigheid van de gegevens moet in kaart gebracht worden evenals de eisen op vlak van beschikbaarheid voor elke use-case, in plaats van voor het volledige systeem.

Als dit proces rigoureus uitgevoerd wordt, kan tijdens de architectuurfase de beschikbaarheid aanzienlijk verhoogd worden met een factor 40x (van 90 tot 99.75%). De uiteindelijke beschikbaarheid wordt bepaald door de kans op falen (menselijk, configuratie, hardware, software), maar ook door de tijd die nodig is voor de detectie en het herstellen van het incident. Om deze reden is een goed geoliede organisatie essentieel.

In deze nota worden aanbevelingen geformuleerd ter verhoging van de beschikbaarheid tijdens requirements analyse, wanneer de architectuur wordt uitgetekend, tijdens development, op infrastructuurvlak. Ook wordt het belang van transparantie, governance en automatisering aangetoond. Gezien de breedte van het onderwerp, zal de bespreking beperkt blijven tot een high-level overzicht.

Presentation

Hoewel dit onoverkomelijk en dramatisch lijkt, kan men dit euvel in praktijk vaak verhelpen op voorwaarde dat men hier reeds tijdens de requirements analyse rekening mee houdt. De levensduur en vluchtigheid van de gegevens moet in kaart gebracht worden evenals de eisen op vlak van beschikbaarheid voor elke use-case, in plaats van voor het volledige systeem.

Als dit proces rigoureus uitgevoerd wordt, kan tijdens de architectuurfase de beschikbaarheid aanzienlijk verhoogd worden met een factor 40x (van 90 tot 99.75%). De uiteindelijke beschikbaarheid wordt bepaald door de kans op falen (menselijk, configuratie, hardware, software), maar ook door de tijd die nodig is voor de detectie en het herstellen van het incident. Om deze reden is een goed geoliede organisatie essentieel.

In deze nota worden aanbevelingen geformuleerd ter verhoging van de beschikbaarheid tijdens requirements analyse, wanneer de architectuur wordt uitgetekend, tijdens development, op infrastructuurvlak. Ook wordt het belang van transparantie, governance en automatisering aangetoond. Gezien de breedte van het onderwerp, zal de bespreking beperkt blijven tot een high-level overzicht.

Achter de term NoSQL schuilen database engines met andere doelstellingen dan de relationele database-managementsystemen (RDBMS). Bij NoSQL-oplossingen zullen schaalbaarheid en performantie heel vaak voorrang krijgen op de consistentie van de gegevens. Een andere grote verandering is het formaat van de gegevens zelf: in de relationele databases worden de gegevens voorgesteld in de vorm van grote tabellen maar hier is dat niet langer het geval. Het is soms mogelijk gegevens op te slaan in de vorm van complexe documenten zonder vooraf vastgelegde structuur. Deze ongebondenheid qua gegevensformaat kan, als zij correct gebruikt wordt, een grote soepelheid bieden aan de ontwikkelaars en kan de toepassingen die deze databases zullen manipuleren zeer flexibel maken.

Op papier lijken bepaalde concepten van de NoSQL-databases zeer aanlokkelijk maar hoe zit het nu in de praktijk? Bereiken deze databases hun vooropgestelde doelstellingen? Wanneer kan het gebruik van een NoSQL-database overwogen worden en wanneer is dit geen optie?

Gezien de grote verschillen tussen de RDBMS’en en de NoSQL-databases zal de sessie niet alleen de principes van deze databases toelichten: ook talrijke demonstraties en concrete gebruiksvoorbeelden zijn voorzien. Deze sessie is het tweede deel in een reeks van drie sessies rond de thema’s hoge beschikbaarheid, schaalbaarheid en performantie. De reeks wordt afgesloten in december met de sessie over XTP-platformen (eXtreme Transaction Processing).

Depuis plusieurs décennies, le modèle relationnel règne en maître dans le monde des bases de données. Cependant, avec la montée en puissance du Web 2.0, les bases de données relationnelles, pourtant très bien maîtrisées par les informaticiens, ont commencé à montrer leurs limites et se sont parfois même révélées inefficaces pour certaines tâches, poussant des géants du Web tels que Amazon, Facebook ou Google à développer des alternatives permettant de répondre à ces nouvelles contraintes. Le mouvement NoSQL (Not only SQL) a alors été lancé.

Derrière le terme NoSQL se cachent des moteurs de bases de données aux objectifs différents de ceux visés par les systèmes de gestion de bases de données relationnelles (SGBDR). Avec les solutions NoSQL, la scalabilité et les performances seront bien souvent privilégiées par rapport à la consistance des données. Un autre grand changement est le format des données lui-même : alors que dans les bases de données relationnelles, les données se présentent sous forme de grands tableaux, ici, ce n’est plus le cas. Il est parfois possible de stocker des données sous forme de documents complexes dont la structure n’est pas prédéfinie. Cette malléabilité du format des données peut, si elle est correctement exploitée, offrir une grande souplesse aux développeurs et apporter une grande flexibilité aux applications qui vont manipuler ces bases de données.

Sur le papier, certains concepts des bases de données NoSQL semblent très alléchants, mais qu’en est-il en pratique ? Les objectifs fixés par ces bases de données sont-ils atteints ? Quand doit-on et ne doit-on pas envisager l’utilisation d’une base de données NoSQL ? Etant donné les grandes différences entre les SGBDR et les bases de données NoSQL, la session ne se contentera pas d’expliquer les principes de ces bases de données : de nombreuses démonstrations sont prévues ainsi que des exemples concrets d’utilisation. Cette session est le second volet d’une série de trois sessions sur les thématiques de la haute disponibilité, scalabilité et performances. La série sera clôturée en décembre avec la session sur les plateformes XTP (eXtreme Transaction Processing).

Presentation