Real-Time Analytik mit Apache Ignite
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 49 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/51740 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 2020 Cloud-Edition40 / 49
1
2
5
8
9
10
13
19
20
21
22
23
25
26
27
29
31
32
33
34
35
42
44
46
48
00:00
Point cloudApache <Programm>SQLSoftwareOpen sourceEXTRACTApache <Programm>Systems <München>IndividualsoftwareTape driveComputing platformData conversionWeb-AnwendungInstanz <Informatik>Set (mathematics)DatabaseSoftwareLink (knot theory)Open sourceMachine learningDatabaseStructural loadDatabaseBusiness reportingPatch (Unix)Multitier architectureStandard deviationQubitFRAMEWORK <Programm>Physical quantityMultivariate AnalyseCasting (performing arts)LogicTOUR <Programm>Division (mathematics)Computer animation
08:39
OLAPMultivariate AnalyseVolumetric flow rateData streamReal-time operating systemScalabilitySQLOpen sourceJASPER <Programm>PentahoApache <Programm>Version <Informatik>Computing platformCW-KomplexInternetdienstStreaming mediaFault-tolerant systemProcessing <Programmiersprache>Menu (computing)Tape driveJava Message ServiceCache (computing)High availabilityJDBCODBCTwitterWeightPHPDesign by contractPostgreSQLOracle <Marke>Client (computing)Apache <Programm>PredictionCubeData streamCommunications protocolReal-time operating systemSubsetSet (mathematics)Interface (computing)ZahlLastteilungRoute of administrationContent (media)Lösung <Mathematik>Device driverFault-tolerant systemComputing platformEchtzeitverarbeitungSystems <München>Semaphore lineRow (database)MassScalabilityVersion <Informatik>Structural loadTragfähigkeitDirection (geometry)Data structureDatabaseData modelBounded setQuery languageProduct (category theory)Relational databaseQubitZugriffNoten <Programm>Game theoryDatabaseStreaming mediaWeb serviceSpeciesFunction (mathematics)
17:11
TwitterHigh availabilityInternetdienstJava Message ServiceCache (computing)JDBCODBCPHPPostgreSQLSQLOracle <Marke>Cluster analysisClient (computing)Apache <Programm>SpeicherkapazitätImplementationAPITimestampDatabaseScalabilityBackupCodePartition (number theory)Partition (number theory)BackupClient (computing)AlgorithmData modelCluster analysisZahlComputing platformCodeImplementationProgramming languageProduct (category theory)Vertex (graph theory)Row (database)Query languageSubsetAtomic nucleusSeries (mathematics)Cache (computing)Social classTape driveRoute of administrationClefRelationales DatenmodellStructural loadLevel (video gaming)Relational databaseAPISystems <München>CASHECluster samplingComputer animation
25:44
Partition (number theory)CodeApache <Programm>SQLRAMOracle <Marke>Cache (computing)Data integrityTuningHauptspeicherError detection and correctionData modelHauptspeicherDefault (computer science)Partition (number theory)CASHEStructural loadDatabaseRelationales DatenmodellVersion <Informatik>Error detection and correctionAnbindung <Informatik>CodeMassTable (information)Best, worst and average caseClefMoment (mathematics)Route of administrationCache (computing)Fixpunkt <Datensicherung>Eigenvalues and eigenvectorsInsertion lossComputer hardwareSocial classDatabaseProfessional network serviceCluster samplingDiallyl disulfideComputer animation
34:16
ParsingSQLOutline of industrial organizationVersion <Informatik>Table (information)Inverter (logic gate)IndexInformationZahlData modelComputer programmingImplementationUser-defined functionIndexAttribute grammarTexture mappingQuery languageStrich <Typographie>Version <Informatik>Constraint (mathematics)String (computer science)Set (mathematics)SpeciesData modelSystems <München>Computer programmingQuery languageMach's principleListe <Informatik>Data analysisFunction (mathematics)CodeSQLLevel (video gaming)Chain ruleDevice driverNoten <Programm>Relational databaseVerteiltes SystemComputer animation
41:12
SQLJDBCCache (computing)Raw image formatComputer hardwareConfiguration spaceOpen sourceBASICSpring (hydrology)Apache <Programm>ComputerClient (computing)Network topologyAnbindung <Informatik>Streaming mediaInternetdienstImplementationMilitary operationInternetObject (grammar)Cluster samplingClient (computing)CASHEImplementationRaw image formatComponent-based software engineeringVideo game consoleCache (computing)Server (computing)Data modelDownloadData storage deviceSeries (mathematics)Business reportingCodeRoute of administrationDatabaseSocial classOutline of industrial organizationConstraint (mathematics)Direction (geometry)Web serviceVerteiltes SystemTable (information)CubeTape driveWEBComputer animation
47:04
InternetdienstImplementationSQLScalabilityOpen sourceComputer hardwareEchtzeitverarbeitungComputer hardwareSpring (hydrology)Hard disk driveSet (mathematics)Open sourceMachine learningProduct (category theory)Partition (number theory)SPARK <Programmiersprache>ImplementationSystems <München>Version <Informatik>CASHEConstraint (mathematics)DatabaseZugriffForm (programming)Software testingComputer animation
52:56
ScalabilityComputer hardwareEchtzeitverarbeitungOpen sourcePoint cloudAPPLE IIcComputer animationJSONXMLUML
Transcript: German(auto-generated)
00:07
Guten Morgen und Willkommen im HS3. Das ist der erste Vortrag vom Hendrik Weber zum Thema Realtime Analytik mit Apache Ignite. So und bevor es jetzt losgeht, Hendrik, lass mich mal eben den Stream anschalten.
00:21
Es dauert jetzt ein paar Minuten. So und jetzt ist er auch schon enabled und jetzt reden wir noch ein bisschen und dann, weil das Ding ungefähr so 30 bis 35 Sekunden Delay hat. So, jetzt müsste es das aber auch schon ganz genau
00:41
funktionieren. Stream startet, alles gut. Bestens und Hendrik, leg los. Dankeschön. Ja, ein bisschen seltsam so vorzutragen. Ja, guten Morgen. Ich hab heute
01:00
für euch ein Thema mitgebracht, das uns ja 2017 bei unserer Arbeit auf den Tisch gefallen ist und es geht um das Open Source Projekt Apache Ignite, ein In-Memory-Framework
01:22
wo man uns, als wir dann bei der Firma angefragt haben, die das ursprünglich mal rausgebracht hat, erfahren haben, dass wir die ersten, die ersten in Deutschland waren, die dieses Ding tatsächlich einsetzen oder zumindest die ersten, die sich aus Deutschland dort gemeldet haben und
01:41
die Erlebnisse, die wir mit Apache Ignite hatten, die, davon möchte ich euch ein bisschen erzählen und vielleicht das Interesse wecken für für die Plattform auch und vielleicht finden sich auf dem Wege auch noch ein paar andere Nutzer, die auch ihre ersten Erfahrungen damit gerade sammeln.
02:02
Kurz zum Kontext, mein Name ist Henrik Weber, ich arbeite bei der Firma Capgemini. Ich bin im Custom Solution Development auf Deutsch übersetzt, ist das die Individual-Software-Entwicklung, das heißt wir entwickeln für unsere Kunden maßgeschneiderte Software für deren
02:23
spezielle Anforderungen und so im Laufe meines Berufslebens gab es so einige verschiedene Kunden mit mit unterschiedlichen Geschäften, das allererste war eine Erzeugergemeinschaft für Hühnereier,
02:42
danach dann Schienenlogistiker, sprich die Bahn, dann eine große deutsche Krankenversicherung, ein großer deutscher Mobilfunkanbieter und in letzter Zeit diverse deutsche Behörden. Über die Jahre weg ging es also von der Legehenne über verschiedenen Bahnhöfe,
03:02
über Abrechnung von Krankenversicherungen bis zur Flüchtlingskrise und das ist so eigentlich das, was für mich so spannend ist, dass man von verschiedenen Kunden auch die
03:24
die Spezialitäten kennenlernt und ganz ganz Einblicke in Organisationen bekommt, die man sonst eigentlich nur von außen sieht und es gibt so einen so einen Bereich von typischen Aufgabenstellungen, die wir normalerweise haben in dieser
03:42
Individual-Software-Entwicklung. Wir haben Kunden, die haben vielleicht so etwas kleinere Probleme, so hier die Katze und die wollen dafür ein Katzenkörbchen, das geht dann hin bis zu Kunden, die haben etwas größere Probleme, die wollen ein größeres Katzenkörbchen.
04:04
Von der technischen Umsetzung her ist das, was wir da bauen, aber irgendwie alles doch ähnlich, also von der Architektur, die wir da verbauen, eine klassische Dreischichtenarchitektur, das ist das ja so das Brot- und Buttergeschäft und dafür haben wir auch eine Standardarchitektur, die ist tatsächlich auch open source, wer sich dafür interessiert,
04:27
findet sie unter dem Link. Ein Kollege hat vor zwei Jahren auf der Frostcrans schon mal einen Vortrag darüber gehalten, das will ich heute nicht wiederholen, aber wer mal relativ schnell
04:43
ordentlich strukturierte Dreischichtenanwendung für eine Web-Anwendung hochziehen möchte, der kann sich das mal ansehen. Und dann gibt es Kunden, die haben irgendwie noch so ein bisschen andere, nicht so Standardprobleme, die haben dann irgendwie sowas vielleicht, keine Katze, sondern ein Drachen
05:03
und die wollen auch was Besonderes, die wollen kein Drachenkörbchen, die wollen irgendwie eine Rüstung für ihren Drachen haben. Das fällt dann auch so in den Bereich der Individualsoftware-Entwicklung, aber da sind wir dann ein bisschen aus unserem gewohnten Geschäft raus, da wird es dann interessant. Das sind so die Sahnehäubchen, die wir dann hin und wieder mal haben.
05:24
Und das, wo uns heute geht, ja, das ist einer von diesen Drachen. Und relativ häufig fängt das irgendwie so ein bisschen wenig vielversprechend an, das sind meistens Themen, wo eigentlich keiner so richtig dran will
05:41
und jetzt gerade bei einem, mit einem Team, das Individualsoftware entwickelt, ist so die Aufgabenstellung, wir möchten ein Supporting- und Analyticsystem jetzt nicht so die die reizvollste Aufgabe. Dafür haben wir eigentlich Spezialisten, Data Scientists, die sich um sowas kümmern. Aber irgendwie war es die Aufgabe, die in dem Projekt übrig geblieben ist und dann haben wir sie halt bekommen.
06:08
Normalerweise ist das, was man da baut, sowas. Man hat hier links so dieser grüne Bereich, das sind nur die operativen Systeme. Das ist praktisch das, was das Tagesgeschäft erledigt.
06:22
Und klassischerweise liegt da so für die Datenhaltung ein relationales Datenbank-Management-System drunter. Und das ist in aller Regel für diese Art von von Last optimiert, also viele kleine Transaktionen. Und
06:41
es ist schwierig, eine Datenbank gleichzeitig für diese Aufgabenlast und für für Analytik zu konfigurieren. Deshalb macht man das gerne auf zwei verschiedenen Instanzen von Datenbanken und hat dann hier so einen ETL-Prozess, der also die Daten aus den operativen Systemen abzieht, sie aufbereitet für die
07:01
für die Analytik und sie dann in das andere System reinlädt und das läuft dann auf eine eigene Datenbank, die für Analytik optimiert ist. Und dann macht man da halt seine Berichte drauf, also so Monatsberichte, Jahresberichte, irgendwelche Dashboards vielleicht, die das ganze grafisch aufbereiten
07:24
und mehrdimensionale Analyse, diese sogenannten Cubes, wo man dann die Daten in mehreren Dimensionen schneiden kann und aggregieren kann. Und jetzt seit einigen Jahren kommt noch das ganze Thema Machine Learning dazu, was da auch noch mit reingehört.
07:45
Wir hatten jetzt bei unserem Kunden und ich darf, weil das Projekt vertraulich war, jetzt nicht wirklich erzählen, was wir gemacht haben. Ich mache aber mal, damit sich so vielleicht ein kleines kleines Bild vor den Augen bildet, mal ein abstraktes Beispiel.
08:03
Wir hatten also einen Kunden, der ja, man könnte sagen im weitesten Sinne Sensoren hatte, viele Sensoren und die haben eine große Menge von Daten produziert. Und der Kunde hatte den Anspruch auf diese Daten
08:24
mit relativ wenig Zeitverzug reagieren zu können. Auch mal so als Bild vor dem geistigen Auge, wenn man sich vorstellt, man möchte irgendwie vielleicht nicht Katastrophen verhindern, aber vielleicht, wenn sich eine Katastrophe anbahnt, schon mal die
08:46
die Feuerwehr, das Technische Hilfswerk oder die Polizei vor Ort haben, damit sie gleich aktiv werden können, wenn irgendwas passiert. Und man möchte dafür vielleicht irgendwie so ein Vorhersagesystem haben und die Vorhersage
09:03
Frist, die man hat, ist halt relativ kurz, weil zum Beispiel besondere, besondere Wetterereignisse eben sich häufig erst sehr kurzfristig ankündigen. Deshalb soll das System, das die Messdaten liefert und hinterher auswertet, das mehr oder weniger in Echtzeit tun und
09:27
eben auch in Echtzeit analysieren. Und wenn man das jetzt mit einer ausreichend großen Zahl von Sensoren macht und die jetzt auch oft genug Daten schicken,
09:44
dann bekommt man irgendwann einen Mengengerüst, bei dem man feststellt, dass das von der von der Tragfähigkeit so herkömmlicher Relationale Datenbankmanagement-System ein bisschen schwierig wird. Und das war die Situation, von der wir bei unserem Projekt entstanden.
10:05
Wir haben das ausgerechnet, haben festgestellt, also wenn das System irgendwann voll ausgebaut ist und wirklich den vollen Datenstrom liefert, rund um die Uhr, sieben Tage die Woche, dann müssen wir eine dauerhafte Last von etwa 40.000 Datenbank-Zugriffen pro Sekunde stemmen können. Das haben wir
10:26
den klassischen Datenbank-Produkten nicht mehr so richtig zugetraut oder es wäre halt sehr sehr teuer geworden, auch von den Lizenzkosten, die man hätte investieren müssen, um da ein entsprechendes System aufzusetzen.
10:45
Und dazukam einmal, wir mussten die Daten halt verarbeiten in Echtzeit und das klassische, was man macht, eigentlich bei solchen Systemen, ist, dass dieser ETL-Prozess nachts läuft, weil da die operativen Systeme
11:02
nicht so stark belastet sind und man die Daten dann halt am nächsten Tag analysiert. Das war jetzt hier keine Option. Wir sollten es in Echtzeit tun. Das zweite, was auch klassisch ist, dass man diese Cubes, dass man die Aggregationen, die es ergibt, vorberechnet, damit die
11:20
Performance besser wird, weil der Auswertung von einem Cube, wo halt viele Millionen Datensätze aggregiert werden müssen in Echtzeit, ist auf einem herkömmlichen relationalen Datenmarktenmanagementsystem halt auch eine Sache, wo der Anwender dann irgendwo draufklickt und dann Minuten davor sitzt, bis er ein Ergebnis bekommt und
11:42
damit das einigermaßen erträglich wird, berechnet man bestimmte Aggregate vor. Allerdings laufen diese Voraggregationen halt auch im Minuten- bis Stundenbereich und auch das war jetzt keine Option. Wir sollten also auf den aktuellsten Daten Performante Cubes zur Verfügung stellen.
12:02
Und wir hatten einen gewissen Rahmen, der war vorgegeben. Es gab die operativen Systeme, die haben ihre Daten über Kafka in unsere Richtung geworfen. Wir hatten die Auswahl zwischen einem schon vorhandenen relationalen Datenmarktenmanagementsystem oder Cassandra. Da durften wir uns entscheiden.
12:23
Und wir durften aber auch noch einen Vorschlag machen für das, was dazwischen sein sollte. Und wir haben gesagt, okay, wir brauchen irgendwie mehr Performance. Das relationale Datenmarktenmanagementsystem ist wegen der Skalierbarkeit und der Performance wahrscheinlich nicht unsere Wahl. Cassandra versprach gute Performance, auch gute Skalierbarkeit,
12:45
hat aber ein relativ beschränktes Abfrage-Modell durch sein Key-Value-Daten-Modell. Und das, was man bei diesen Cube-Auswertungen macht, sind eigentlich Ad-hoc-Abfragen. Das heißt, man weiß vorher nicht so genau, was man abfragt und das passt eigentlich nicht gut zu Cassandra.
13:02
Da haben wir gesagt, wir brauchen irgendwie noch irgendwas dazwischen. Und wir brauchen auch etwas, das insgesamt sowohl bei beim Reinladen der Daten in diesem dauernden ETL-Prozess als auch dann bei der analytischen Auswertung
13:22
genug Performance bietet, ohne dass wir dauernd Daten zwischen verschiedenen Systemen hin- und herschaufeln müssen. Und dann haben wir dem Kunden ein paar Vorschläge gemacht und am Ende hat sich der Kunde dafür entschieden. Und damit sind wir jetzt bei Apache Ignite angekommen.
13:42
Apache Ignite ist eine In-Memory-Plattform und die hat für uns jetzt praktisch die Lücke geführt zwischen Cassandra. Dafür haben wir uns dann entschieden. Und dem, was wir noch brauchten, dass wir nämlich SKL-Abfragen auf die Daten machen können, dass wir skalieren können und
14:05
die Hoffnung war damals, es ist ein In-Memory-System, da bekommen wir dann auch entsprechend die Performance her. Im Detail vielleicht ein paar Dinge zu Ignite, um das System mal vorzustellen.
14:26
Es ist ursprünglich von einer Firma namens GridGain entwickelt worden. Die haben die Plattform 2014 open source gestellt. In dem Jahr ist es dann auch in den Apache Incubator gekommen.
14:41
Und im Jahr 2015 ist das Projekt dann zu einem Apache Top-Level-Projekt gereift. Und wurde ursprünglich als In-Memory-Plattform angepriesen. Mit der Version 2.1 haben sie eine native Persistenzlösung dazu gebaut und seitdem nennen sie es Memory-Centric-Plattform.
15:10
Und das Ganze ist ein sehr, sehr umfangreiches Paket. Also dieses Puzzle hier
15:20
gibt so ein bisschen wieder, was da so alles drin steckt. Ich gehe mal kurz auf die Features, die wir genutzt haben. Also wir haben das Distributed Caching verwendet, wir haben das In-Memory-SQL verwendet, das Grid Computing, die hochverfügbaren Services, das Kafka Streaming.
15:44
Die Fehlertoleranz war für uns ein Punkt, denn wir wollten ein gewisses Maß an Auswahlsicherheit haben. Wir brauchten das Messaging, Complex Event Processing, das war letztendlich das, was wir für die
16:02
ja für die Echtzeitverarbeitung benötigt haben. Und diese verteilten Datenstrukturen, verteilte Cues, verteilte Semaphoren sind einfach nochmal ein Werkzeug, mit dem man ja bestimmte Lösungen einfach dann auch auf dieser Plattform bauen kann, um zum Beispiel Load Balancing oder anderweitig
16:23
koordinative Funktionen umzusetzen. Ignite ist in Java geschrieben. Das heißt, zumindest läuft es auf der JVM und große Teile sind in Java geschrieben.
16:40
Es kommt als Spring Boot Anwendung daher und ist sehr, sehr kommunikativ. Es hat jede Menge Schnittstellen nach außen. Man kann also so einen Ignite Cluster über REST ansprechen.
17:00
Sie bieten eine Teilmenge des Redis Protokolls an. Sie bieten das Binary Memcache Protokoll an. Man kann über den JDBC oder Audibc Treiber auf die Inhalte zugreifen und SQL Abfragen auf den Daten machen. Und es gibt verschiedene Thin Clients, die man nutzen kann, um von verschiedenen Programmiersprachen auch noch drauf zuzugreifen.
17:25
Damit Ignite als In-Memory-Plattform die Daten, die man da reinsteckt, nicht vergisst, gibt es verschiedene Möglichkeiten Persistenz anzubinden. Auch wieder über JDBC an ein klassisches
17:44
Relationales Datenbank-Management-System oder auch über ein Cassandra Client eben Cassandra. Auf der anderen Seite, wie bekommt man Daten rein in das System? Es gibt eine ganze Reihe von Streamern zu verschiedenen Messaging- und Cueing-Systemen.
18:00
Kafka, Camel, alles was JMS kann und verschiedene auf bestimmte Produkte spezialisierte Clients. Sie haben so ein paar Standard, Standard-Integrationen für Standard-Anwendungen, also Level 2 Caching für Hibernet oder auch Web-Session Clustering.
18:22
Und dann gibt es eine ganze Reihe von weiteren Features, die man nutzen kann und das hier unten, das sind auch nicht alle. Im Detail kann ich da nicht alles heute darüber erzählen. Die Zeit ist begrenzt. Ein paar Aspekte würde ich mal rausgreifen.
18:43
Das eine ist Partitioning und Collocation. Das sind ganz wichtige Konzepte, wenn man mit Ignite arbeitet, die man gut verstanden haben muss. Sonst wird man mit der Plattform nicht glücklich.
19:02
Dem ganzen System zugrunde, also den Kern bildet eigentlich eine verteilte Implementierung der Java Jcache-RP. Die Daten, die man da reinpackt, werden als Key-Value-Paare abgelegt. Im Prinzip wie bei einer Java Map, aber eben verteilt in einem
19:25
Cluster, der aus mehreren Knoten besteht. Und sobald man Daten verteilt, muss man sich natürlich überlegen, wie man das macht. Und die Caches lassen sich in zwei Modi konfigurieren.
19:41
Das eine ist der Replicated-Modus. Das heißt, dass alle Daten auf jedem Knoten vorgehalten werden. Das zweite ist der Partition-Modus. Da werden die Daten verteilt. Das heißt, nicht jeder Knoten hat alle Daten.
20:01
Und das Ganze ist ein Stück weit skalierbar. Das heißt, man kann sagen, jeder Knoten bekommt eine Teilmenge der Daten und die Knoten haben alle disjunkte Daten. Das würde dann heißen, dass die, dass wenn ein Knoten ausfällt, dessen Daten halt dann nicht mehr zur Verfügung stehen.
20:21
Oder man kann auch Backups konfigurieren. Und das erlaubt es dann, dass einzelne Knoten ausfallen, ohne dass die Daten im Cluster verloren gehen. Und über die Anzahl der Backups kann man konfigurieren, wie viele Knoten man denn verlieren darf.
20:43
Im Detail, wie funktioniert das? Also zum einen über die Partitionierung, über diese Partition-Caches bekommt man dann eben auch die Skalierung. Das heißt, dadurch, dass man Knoten in den Cluster dazustellt,
21:01
bekommt der Cluster auch einfach mehr Kapazität für Daten. Und wenn man die Daten so aufgeteilt hat, wie das hier auf dem Bild ist, das wäre jetzt also der Fall, wo jeder Datensatz nur auf einem Knot
21:20
gespeichert ist und wir jetzt in diesem Fall eben einen Knoten verlieren, dann wären die Daten von diesem Knoten halt im Cluster nicht mehr verfügbar. Und wie gesagt, die Lösung ist, wir definieren Backups, sodass jetzt zum Beispiel der Knoten 1, der ist jetzt der primäre Knoten
21:43
für die Partition 1 und die Daten, der Datensatz in der ersten Zeile und der vierten Zeile, die sind jetzt dieser Partition zugeordnet. Die sind also zuerst mal hier gespeichert und dann gleichzeitig ist der Knoten 2, aber auch noch der Backup-Knoten für die Partition 1, das heißt,
22:02
der hat praktisch als Sicherheitskopie die Daten auch nochmal und wenn jetzt der Knoten 1 ausfallen würde, würde der Knoten 2 erst mal übernehmen und dann würde der Cluster anfangen, sich selber zu reparieren.
22:21
Das heißt, der Knoten 2 würde jetzt beginnen, die Daten praktisch im restlichen Knoten geschlossen ist, dieses Rebalancing, die Daten wieder gleichmäßig verteilt haben, jeweils mit einem Primärknoten und einem Backup dazu.
22:44
Man kann die Zahl der Backups auch hochdrehen, das hat aber dann natürlich immer zur Folge, einerseits bekommt man mehr Ausfallsicherheit, auf der anderen Seite kostet das natürlich auch mehr Speicherplatz. Wenn wir jetzt die Daten verteilt haben in so einem Cluster und die Knoten
23:08
wird man normalerweise natürlich auf verschiedene Maschinen verteilen, nicht alles auf eine Kiste packen, dann hat man zwischen den Knoten natürlich Netzwerkkommunikation, das ist einer der potenziellen
23:28
Netzwerklasts, so niedrig wie möglich zu halten, gibt es das Prinzip der Collocation, das muss man im Kopf behalten, wenn man seine Anwendung designt, auch wenn man seine Datenmodelle designt, das Ignite
23:45
collocated verarbeiten kann. Was heißt das? Wenn man sich jetzt vorstellt, man hat einen Cluster hier vielleicht mit 4 Knoten und der Knoten 1 hat jetzt irgendwelchen Code, den er ausführen
24:01
soll und zwar dann natürlich mit Daten, die im ganzen Cluster verteilt sind, dann schickt er die Jobs zu den verschiedenen Knoten, das heißt es wird praktisch der Code, der laufen soll, wird verteilt auf die Knoten und auf jedem Knoten läuft dann der Code mit den Daten, die sich auf diesem Knoten befinden. Ist also im Prinzip so ein MapReduce
24:26
Algorithmus. Das geht so lange gut, bis jetzt der Job, der zum Beispiel auf Knoten 2 läuft, feststellt, er braucht Daten von einer Partition, die nicht auf diesem Knoten gespeichert sind. Dann würde
24:41
dieser Job jetzt hingehen und die Daten über das Netzwerk natürlich von dem entsprechenden Knoten anfordern. Wenn das jetzt öfter passiert, bekommt man ziemlich viel Netzerkommunikation und das ist genau das, was wir vermeiden wollen. Und dazu bietet Ignite die Möglichkeit,
25:03
das nennt sich bei denen Affinity Key, man hat also die Möglichkeit, eine Annotation in seine Datenklassen zu schreiben. Die Ignite sagt, dass ein bestimmtes Attribut, ein Member der Klasse, der Wert ist,
25:31
er bestimmt, in welcher Partition die Daten landen. Und wenn man das bei
25:41
verschiedenen Klassen immer auf das gleiche Attribut packt, also wenn man sich vorstellt, wenn man es jetzt in einem relationalen Datenmodell macht, wenn man eine 1 zu N-Beziehung hat, dann würde man praktisch auf der 1-Seite den Affinity Key eben an den Primärschlüssel schreiben und auf der N-Seite den Affinity Key an den Fremdschlüssel,
26:02
der auf den Primärschlüssel der 1-Seite verweist. Das würde dazu führen, dass alle Daten in dieser 1 zu N-Beziehung eben in der gleichen Partition landen würden und wenn man dann Daten joint, dann sind alle
26:20
Daten, die zu joinen, sind immer in der gleichen Partition und damit hardwaremäßig dann auch auf dem gleichen Knoten und wir sparen uns den Netzwerkverkehr. Das ist ein wichtiges Prinzip, dass man bei seinem ganzen Anwendungsdesign im Hinterkopf verhalten möchte.
26:40
Das funktioniert so lange, wie man mit 1 zu N-Beziehungen auskommt. Das geht in dem Moment nicht mehr, wo man M zu N-Beziehungen irgendwo in seinem Datenmodell hat. Das sollte man versuchen, also tunlich zu vermeiden. Das Zweite, worum man sich kümmern muss, ist die
27:05
Persistenz. Wenn man Ignite als reines Memory-System betreibt, das geht auch, also ganz ohne Persistenz. Das kann man machen, wenn man jetzt einen Cash hat und man keinen großen Wert darauf legt, dass die Daten irgendwie erhalten bleiben, weil man sagt,
27:22
zum Beispiel eine Web-Session, wenn man Web-Session Persistenz macht, das muss nicht dauerhaft Persistenz sein, das muss ja nur so lange überleben, wie der Anwender in der Web-Session drin ist und schlimmstenfalls verliert er halt mal seine Session. Dann muss man
27:43
sich um die Persistenz nicht unbedingt Gedanken machen, aber wenn man es praktisch als Datenbank verwenden möchte, die auch dauerhaft ihre Daten behält, muss man sich Gedanken machen, wie man die Daten aus dem Hauptspeicher irgendwie in einen Persistenten-Speicher
28:01
rüberbekommt. Bis vor Version 2.1 war die einzige Option das, was heute Drittanbieter-Persistenz heißt. Das heißt, man musste sich entscheiden für entweder ein relationales Datenbank-Management-System, das man über JDBC anbinden konnte, oder Cassandra. Und Ignite hat dann
28:31
praktisch pro Cash, den man daran einlegt, hat man dann praktisch eine Tabelle unten in seinem Persistenzsystem. Und solange man reine
28:42
Cash-Operationen macht, muss man sich dann eigentlich gar nicht mehr um viel kümmern. Man kann Ignite so konfigurieren, dass die Daten direkt durchgeschrieben werden, wenn man Werte in den Cash reinlegt. Und dass sie auch wieder aus der Persistenz gelesen werden, falls sie nicht im Hauptspeicher vorhanden sind, wenn man über einen Schlüssel auf den
29:04
Cash zugreift. Das heißt, wenn die Daten nicht im Hauptspeicher sind, geht Ignite hin und schaut in der Persistenz nochmal nach, ob der Kurs da eventuell vorhanden ist. Das funktioniert allerdings nicht, wenn man mit SQL arbeitet. Da weiß Ignite nicht, was möglicherweise aus dem
29:22
Hauptspeicher mittlerweile weggerollt wurde und was nur unten in der Persistenz liegt. Mit der Version 2.1 kam dann die native Persistenz dazu. Und da speichert jeder Ignite-Knoten die Daten auf seinem lokalen File-System. Das heißt, man bekommt also auch einen
29:41
verteilten, persistenten Speicher. Und das Ganze arbeitet auch mit einem Writer-Headlock und einem sogenannten Checkpointing-Prozess, der die Daten dann hinterher konsolidiert. Und dann weiß Ignite auch, welche Daten auf jedem Knoten auch persistent sind und man kommt auch per SQL dran.
30:05
Ups, das ging zu schnell. Wir hatten noch keine Wahl, als wir gestiegen und wir mussten Drittanbieter-Persistenz machen. Und
30:20
die native Persistenz haben wir dann noch nicht umgesetzt bis jetzt. Ich habe mal ein bisschen damit rumgespielt und die Erfahrung, die ich bis jetzt damit gemacht habe, ist, man muss das gut testen und sich das gut überlegen. Die Drittanbieter-Persistenz hat einige Probleme.
30:47
Das eine ist eben, dass man, wenn man SQL verwendet, selber dafür sorgen muss, dass die Daten, die man mit seinen Queries finden möchte, auch tatsächlich in den Hauptspeicher geladen sind. Dazu gibt es dann einen
31:01
Prozess namens cache-warmup. Den muss man konfigurieren. Und wenn man den Default cache-warmup verwendet, dann ist das sehr langsam, sehr ineffizient und skaliert auch nicht wirklich gut. Man muss sich eine eviction policy überlegen. Das ist das, was bestimmt, welche Daten aus dem Hauptspeicher weggeräumt werden, wenn der Hauptspeicher
31:24
knapp wird. In aller Regel hat man im Hauptspeicher, auch wenn man viel Speicher hat, trotzdem nicht alle Daten immer liegen. Und damit man keine out of memories bekommt, muss man eben eine policy festlegen, die sagt, wann welche Daten abgeräumt werden. Man muss letztendlich eine
31:46
eigene Fehlerbehandlung für Partitionsverlust zu schreiben. Das heißt, wenn doch mal mehr ausfällt, als man durch seine Backups abgesichert hat, dann muss man selber Code schreiben, der dafür sorgt, dass die Partitionen wieder aufgebaut werden. Und man hat halt
32:01
natürlich die Persistenz auch übers Netzwerk angebunden, was das Ganze potenziell auch langsamer macht. Dafür kann man die Persistenz separat skalieren, gerade wenn man einen Cassandra-Cluster drunter hat, ist ja auch Cassandra skalierbar und man kann zum Beispiel mehr Cassandra-Knoten in den Cassandra-Cluster packen, als man Ignite-Knoten
32:21
in dem Ignite-Cluster hat. Die zweite Sache ist, wenn der Cluster rebalancen muss, dann hat man bei der Drittanbieter-Persistenz das Rebalancing nur für die Daten, die im Hauptschweicher sind. Bei der Nativen-Persistenz rebalanced er auch das, was in der Persistenz ist. Das ist potenziell sehr, sehr viel mehr. Und das kann dann eben auch das
32:44
Rebalancing eben entsprechend mühsam und aufwendig machen. Und man hat in der Zeit natürlich eine höhere Last auch auf dem Netzwerk. Dafür braucht man kein Cash-Warm-Up. Die Daten werden vollautomatisch nachgeladen, wenn sie gebraucht werden, auch wenn man SQL macht.
33:01
Man kann aber, das ist so, worauf man sich einstellen muss, dass der Cluster sich anders verhält. Der Cluster startet erst dann, wenn alle Knoten, die man mal in die sogenannte Baseland gepackt hat, auch oben sind. Sonst muss man sich darauf einstellen, dass man entweder den Cluster
33:25
neu ausbalancieren muss, was eben entsprechend lange dauern kann, oder dass der Cluster eben sich nicht aktiviert. Und die Performance, also die Checkpoint-Verarbeitung, wenn man HDDs in der Maschine hat,
33:41
wird extrem langsam nach einer Weile. Mit einer SSD habe ich es noch nicht in dem Maße gesehen, aber anscheinend ist es ein Vorgang, der eine zunehmende Zeitkomplexität hat. Und deshalb sollte man sehr gut testen
34:02
in einem realistischen Szenario, ob die Performance von seinem System mit einer tiefen Persistenz für das eigene Szenario ausreicht. SQL, wie funktioniert das? Unter der Haube, wie gesagt,
34:23
haben wir eigentlich ein Key-Value-Datenmodell und Ignite setzt da oben drauf die H2-Datenbank-Engine. Mit ein bisschen Zusatzcode, der die verteilte Query-Ausführung implementiert. Das Ergebnis ist, dass man sich halt
34:45
über einen JDBC oder AutoBC-Triver mit im Prinzip jeder Anwendung, die das Protokoll unterstützt, mit seinem Ignite-Cluster verbinden kann und SQL darauf absetzen kann. Und Ignite macht da unter der Haube
35:04
heraus eben eine MapReduce-artige Ausführung von diesen SQL-Statements und verteilt das dann eben im Cluster.
35:21
Das Ganze kann man in Java dann auch konfigurieren oder über XML. Man muss halt so ein Mapping definieren zwischen den Attributen der Java-Klassen, der POJOs und eben den Attributen, die man in SQL sehen möchte.
35:42
Was bekommt man? Man bekommt im Wesentlichen an die SQL 99. Es gibt die Möglichkeit, das Ganze mit User-Defined-Functions zu erweitern, so wie das H2 im Prinzip auch anbietet. Es gibt so ein paar Besonderheiten. Man kann Queries, man kann die Queries
36:03
in unterschiedlichen Modi ausführen. Man kann das mitgeben, wenn man die SQL-Queries ausführt, ob sie collocated sind oder nicht. Non-collocated führt auf jeden Fall zu korrekten Ergebnissen.
36:22
Collocated kann zu falschen Ergebnissen führen, wenn die Daten eben nicht entsprechend collocated sind. Das heißt, wenn das Datenmodell es nicht hergibt und man führt eine SQL-Query aus und sagt, macht das collocated, dann findet die Query gegebenenfalls nicht alle Daten.
36:41
Das heißt, da muss man aufpassen. Es gibt ein paar Einschränkungen. Sub-Queries und Where-Klauseln können nur collocated ausgeführt werden. Das heißt, sie berücksichtigen nur die Daten auf den Knoten, auf denen sie ausgeführt werden und verteilen das nicht transitiv weiter
37:00
in den Cluster. Dann gibt es eine Einschränkung bei Left-Joints und wahrscheinlich auch bei Right-Joints, wenn man bestimmte Arten von Joints macht. Und seit Version 2.7 steht das nicht in der Dokumentation.
37:22
Vielleicht haben Sie mittlerweile eine Lösung dafür gefunden. Bis dahin war es aber so, dass Inklauseln mit Wertelisten sehr, sehr langsam waren, weil sie keine Indizes verwendet haben. Und man konnte das umschreiben in eine andere Syntax,
37:41
um es wieder schneller zu bekommen. Muss man aber wissen und man hat, gerade wenn man jetzt irgendwie so ein Datenanalysewerkzeug verwendet, nicht immer die Möglichkeit, das SQL zu beeinflussen, das da unter der Haube generiert wird.
38:00
Performance und Optimierung. Query-Optimierung ist dann auch bei Ignite ein Thema, so wie bei klassischen Relational-Datenbank-Systemen auch. Es helfen häufig auch die Dinge, die man von den klassischen Systemen kennt. Also Index draufpacken. Wird immer gerne genommen.
38:22
Hilft aber nicht immer. Der Optimizer von H2 ist vergleichsweise einfach. Unter anderem nutzt er immer nur maximal einen Index. Und manchmal nutzt er den falschen. Wir hatten einen Fall, wo wir zum Beispiel sowas hatten wie hier
38:40
in diesem Beispiel, wo wir zwei Wertelisten als Parameter von außen reingegeben haben. Und der Optimizer nicht wusste, welches die längere war. Und er hat dann den Index immer bei der Kürzeren verwendet. Und es hat dazu geführt, dass wir sehr viel mehr Tablescans hatten als unbedingt nötig.
39:01
Mit Indexhins haben wir ihn dann davon überzeugen können, dann den anderen zu nehmen. Aber besser wäre es gewesen, wenn H2 in der Lage gewesen wäre, eben beide Indizes zu nutzen. Dann hätten wir die Query noch ein bisschen weiter beschleunigen können. Und dann muss man ein bisschen drauf schauen. Also unter der Haube ist halt einfach teilt das System. Und das merkt man, wenn man Queries schreibt,
39:26
dass man bestimmte Kriterien nutzen kann, die zu sehr unterschiedlicher Performance führen. Also zum Beispiel so eine Not-in-Abfrage
39:41
kann unter Umständen relativ langsam werden. Und man ist vielleicht besser bedient, wenn man es zum Beispiel mit so einem Mengenkonstrukt macht. Weil Ignite dann möglicherweise das Ganze auf mehr CPUs verteilen kann. Und man dann unter dem Strich eine deutlich schnellere Performance bekommt.
40:02
User defined functions ganz kurz. Das ist nett. Der Standard SQL99 Standard hat zum Beispiel relativ wenige Aggregatfunktionen. Und ich habe mal versucht, eine Perzentilfunktion zu bauen als User defined function.
40:22
Leider hat Ignite das ausgeklammert. Also man kann mit den Standard UDS keine Aggregatfunktion machen, obwohl H2 das eigentlich erlaubt. Und dann muss man seinen Weg so ein bisschen drum rum hacken. Das sah dann am Ende so aus,
40:42
dass ich praktisch eine Query als String dann in diese User defined function reingegeben habe. Und der dann unter der Haube eben die Aggregation gemacht hat. Sowas verteilt zu implementieren ist durchaus aber nicht trivial. Also da sitzt man eine Weile dran, bis man das stabil und performant tatsächlich hinbekommt.
41:03
Ist aber mal eine interessante Übung, dabei lernt man eine Menge. Wie war es dann in der Praxis? Also Ignite ist letztendlich ein großer Baukasten. Es gibt halt die Web Session Persistierung und den Hibernate Level 2 Cache,
41:22
den gibt es so als Standardpaket. Aber ansonsten muss man eben sehen, wie man die ganzen Elemente irgendwie zusammengebaut bekommt, für das, was man damit machen möchte. Wir haben es am Ende so gemacht, wir hatten hier vorne unseren Kafka Stream. Wir hatten unten drunter hier unsere Cassandra Persistenz.
41:41
Und dann hatten wir eine Reihe von Komponenten. Und jede Komponente hat das, was sie so getan hat, immer in einen Cache geschrieben, der dann unten in Cassandra persistiert wurde. Und wir hatten am Anfang einen Dateneingang, der eigentlich nur die Nachrichten aus Kafka abgeholt hat und erst mal persistiert hat.
42:00
Das hat auch Gründe, das hat jetzt mehr mit Kafka auch was zu tun. Man sollte keine langen Kafka Transaktionen offen halten. Auch Kafka ist ein verteiltes System und hat seine ganz eigenen Merkwürdigkeiten, die man berücksichtigen muss. Dann haben wir Interceptoren genutzt.
42:22
Das ist ein Feature von Ignite. Man kann praktisch an jede Cache-Operation sowas andocken, was dann ausgelöst wird, so ähnlich wie Trigger in einer klassischen Datenbank. Das heißt, nach jedem Cache-Put, den wir im Dateneingang gemacht haben, hat so ein Interceptor gefeiert und hat in unserer Prozesssteuerung praktisch einen Job angelegt,
42:43
der dafür gesorgt hat, dass diese Nachricht dann irgendwann verarbeitet wurde. Das Ganze ging dann in unsere Rohdatenverarbeitung. Die hat sich die Nachricht dann geholt, auseinandergedröselt. Das sind die einzelnen Werte, die drinsteckten, aufgeteilt und das Ganze dann auch wieder in einen Cache gepackt und persistiert.
43:05
Und dann auch wieder entsprechende Jobs in der Prozesssteuerung angelegt. Und danach hatten wir dann weitere Jobs, die aggregiert und aufbereitet haben. Und das waren dann die Caches, wo wir unser Analytics-Tool angeschlossen haben,
43:21
das dann eben die Dashboards, die Cubes und die Berichte für uns dann gemacht hat und praktisch den Anwendungen dann die Möglichkeit gegeben hat, auf den Daten tatsächlich was zu machen und tatsächlich auch was zu sehen. Wenn man mit Ignite anfängt, ist es eigentlich erst mal ganz einfach.
43:44
Die haben so eine Web-Konsole, die kann man sich entweder selber lokal installieren oder man kann auch eine im Internet gehostete verwenden. Und da klickt man sich seinen Cluster mehr oder weniger zusammen. Es gibt unglaublich viele Parameter, die man einstellen kann.
44:01
Die meisten davon haben aber ganz ordentliche Default-Werte. Zumindest, dass man am Anfang relativ schnell was hochgezogen bekommt. Man klickt sich das zusammen, schreibt sein Datenmodell rein, klickt auf Download und dann bekommt man, ja, ein Maven-Projekt, das lädt man runter, lädt es in seine IDE.
44:24
Kann dann, wenn man alles konfiguriert hat vorher schon da drin, kann man im Prinzip das Ding starten und hat seinen ersten Knoten laufen. Wenn man einen zweiten Knoten parallel dazu startet, muss man sich schon Mühe geben, dass die sich nicht finden.
44:40
Wenn die sich im Netzwerk sehen, dann hat man dann also schon seinen ersten Cluster mit zwei Knoten. Und dann hat man irgendwie sowas im Log stehen. Das sind dann so die Log-Meldungen immer, wenn Knoten dazukommen oder wieder rausfällt aus dem Cluster. Hier hätten wir jetzt also einen Cluster, der hat einen Server-Knoten. Server-Knoten sind welche, die Daten speichern, Kleinknoten
45:03
sind welche, die keine Daten speichern, die aber zum Beispiel Jobs im Cluster ausführen können. Und hier hätte man halt zum Beispiel, da hat man dann einen Client, der hat vielleicht jetzt gerade irgendwas gemacht, ein paar Tabellen angelegt oder einen Batch ausgeführt und ist dann hinterher wieder rausgehüpft.
45:24
Und man sollte sich aber nicht täuschen lassen nach dem einfachen Einstieg. Wenn man dann eine längere Zeit damit arbeitet und im Projekt Fortschritte macht, kommt man irgendwann an den Punkt, wo man das ganze Jahr auch Richtung ernsthaften Produktionseinsatz bringen möchte.
45:43
Und dann kommen so nach und nach eben doch die Tücken des Objekts hoch und die Lernkurve wird immer steiler, je weiter man kommt. Das heißt, die Probleme, auf die man stößt, werden immer schwieriger. Die hat man am Anfang, am Anfang sieht man die nicht so.
46:04
Worüber sind wir so gestolpert? Der Distributed Classloader, das ist ein Feature, das Sie bewerben, soll eigentlich die Möglichkeit geben, Java Code in den Cluster zu bringen, ohne jedes Mal den Cluster neu starten zu müssen.
46:21
Das heißt, irgendein Knoten bringt halt Java Code rein und über den Distributed Classloader wird das halt im laufenden Cluster verteilt. Der hat aber Einschränkungen, bestimmter Java Code muss im Class Path deployed werden. Und zwar der für Services, der für Modellklassen,
46:43
den man für die Cassandra-Persistierung braucht und der für User-Defined Functions. Und das heißt, wenn man das nutzen möchte, muss man dann doch wieder den ganzen Cluster durchstarten, wenn man neue Versionen von diesem Code in den Cluster bringen möchte. Der Cash-Warm-Up, wenn man die Drittanbieter-Persistenz verwendet,
47:03
ist extrem langsam, das hat uns in Schwierigkeiten gebracht nach einer Weile und wir haben da eine eigene Implementierung gebaut, die sehr, sehr viel schneller war und vor allem auch skalierte. Da muss man aber auch einiges an Herrn Schmalz reinstecken.
47:23
Man kann Überraschungen erleben, wenn der Cluster startet und man gleichzeitig das Cash-Warm-Up macht. Wenn der Cluster startet, macht er erst mal ein Rebalancing, bis die Partitionen alle verteilt sind zwischen den Knoten. Wenn man währenddessen Daten in den Cluster lädt,
47:40
dann muss er natürlich auch die Daten gleich mit ausbalancieren. Da haben sich bei uns die Cluster hin und wieder auch schon mal aufgehängt und wir haben dann irgendwann einen Konstrukt eingebaut, dass diese Vorgänge zeitlich hintereinander gehängt hat. SQL, immer wieder ein Quell von Freude.
48:04
Genau die Einschränkungen, die ich vorhin erwähnt habe, sind uns dann an einigen Stellen auch auf die Füße gefallen und es ist noch mal ein bisschen was anderes, eben SQL by Ignite zu optimieren und wirklich Performance zu bekommen,
48:21
als man das von herkömmlichen Datenbankmanagementsystemen kennt. Einige Features sind in der Open Source Version nicht implementiert. Security, Data Center Replication, bestimmte Monitoring Tools. Dafür muss man entweder die kommerzielle Grid Gain Lizenz sich zulegen
48:44
oder man muss es halt selber implementieren, es ist ja Open Source. Die SQL Performance ist manchmal nicht so gut, wie man es jetzt erwartet hätte, wenn man sagt, wir haben ja ein In-Memory-System. Und wir hatten tatsächlich einen Ritt auf der Rasierklinge.
49:04
Wir hatten einige Features wirklich just in time. Also wir hatten Sprints, wo wir wussten, es ist ein neues Ignite-Release geplant. Das soll zu Beginn des nächsten Sprints rauskommen und am Ende des Sprints soll es eingebaut sein.
49:20
Das war an einigen Stellen das Projekt ziemlich abenteuerlich, hat tatsächlich immer funktioniert, war aber auch ein bisschen Glückssache. Mittlerweile ist der Stand aber recht ordentlich. Vor allem der JDBC-Driver hat uns da einige Kopfschmerzen bereitet, eine Zeit lang.
49:42
Ja, cool, aber komplex. Es macht wirklich Spaß, es ist extrem spannend und sehr sehr lehrreich, damit zu arbeiten. Vor allem auch noch in Verbindung mit anderen verteilten Systemen, die man irgendwie außen angeschlossen hat, wie Cassandra und Kafka.
50:04
Wer das in dieser Konstellation mal durchgemacht hat, der weiß hinterher eine ganze Menge darüber, was bei verteilten Systemen so alles schiefgehen kann. Und verteilte Systeme werden in Zukunft wahrscheinlich auch immer häufiger zum Einsatz kommen,
50:27
weil Dinge wie IoT, Big Data, Machine Learning eben einfach kommende Trends sind und tatsächlich viele Organisationen eben auch ihre Anforderungen hochschrauben,
50:45
was den Echtzeitzugriff auf diese Daten angeht. Und Ignite ist da ein spannender Baustein, den man durchaus in Betracht ziehen kann.
51:00
Aber unter der Haube hochkomplex, das muss man wissen. Und es ist wahrscheinlich eine gute Übung, das zu lernen und zu verstehen, wenn man in Zukunft mit solchen Systemen arbeiten können möchte.
51:20
Auch in das Open Source Welt gibt es aber auch noch natürlich andere Produkte. Also wir hatten zum Beispiel Spark noch mit in der Betrachtung. Und das wäre auch eine Möglichkeit gewesen, da hat sich in unserem Fall der Kunde anders entschieden. Testen ist ganz, ganz wichtig.
51:43
Wenn man auf einer relativ schwachbrüstigen Entwicklermaschine ist, verhält sich Ignite anders, als es das auf einer Produktionsmaschine mit sehr vielen mehr Ressourcen tut. Und auf einem Knoten verhält es sich komplett anders als im Cluster mit mehreren Knoten.
52:03
Sobald man mehr als einen Knoten hat, kommen Mechanismen ins Spiel, die schlicht und einfach nicht aktiv sind, wenn man nur auf einem Knoten läuft. Das ist ganz wichtig zu wissen. Wenn man es auf schwächerer Hardware laufen lässt, findet man vielleicht schon Flaschenhälse,
52:20
die man achten sollte und die man dann später mit seiner Produktionshardware nochmal durchtesten sollte. Sonst treffen diese Flaschenhälse vielleicht erst, wenn man unter Volllast im Echtbetrieb ist. Und wenn einem dann plötzlich die Performance wegsackt, hat man halt wirklich ein Problem.
52:44
Deshalb ist es vielleicht gar nicht schlecht, wenn man mal in einem langsamen Netzwerk und langsamen Festplatten testet, damit man vorher schon weiß, wo man dann seine Lasttests ansetzen sollte. Genau. Und das ist so mein Fazit zu Apache Ignite.