Die Versorgung einer großen Benutzerbasis mit zuverlässigen, konsistenten Daten mit geringer Latenz ist für jedes Backend-Team eine große Herausforderung. Bei Ledger haben wir die strategische Entscheidung getroffen, unsere eigenen Blockchain-Kerndatendienste zu hosten. Da wir uns nicht auf Dritte verlassen, können wir die Daten unserer Kunden selbst verwalten und so sicherstellen, dass die zugrunde liegenden Prozesse unseren Sicherheitsrichtlinien und leistungsorientierten Service Level Objectives (SLO) entsprechen.
Aber diese Strategie bringt auch ihre eigenen Herausforderungen mit sich.
Unsere erste Herausforderung besteht darin, diese zentralen Datenbereitstellungsdienste von den coolen und glänzenden NoSQL-Tools zu migrieren. In diesem Artikel werde ich näher darauf eingehen, warum wir diese schwierige Entscheidung getroffen haben, auf welche Komplexitäten wir gestoßen sind und welche Vorteile wir daraus gezogen haben.
Ziel dieses Artikels ist es, die technischen Aspekte aufzuzeigen, die uns dazu veranlasst haben, PostgreSQL als unsere neue Basisspeicherschicht für Blockchain-Daten zu wählen.
Tauchen Sie tief in Blockchain-Daten ein
Blockchain-Daten weisen mehrere Schlüsselfunktionen auf.
Erstens wächst es ständig und nichts wird jemals daraus gelöscht. Obwohl der größte Teil einer Blockchain in der Praxis unveränderlich ist, kann sich der jüngste Teil der Blockchain aufgrund von Konflikten, die gelöst werden müssen, ändern. Da es sich bei der Kette tatsächlich um ein Peer-to-Peer-Netzwerk handelt, können vorübergehend mehrere legitime Blöcke nebeneinander existieren. Normalerweise wird das Ältere gelöscht, was zu einer sogenannten Reorganisation führt. Um es kurz zu machen: Die Daten sind zwischen einem unveränderlichen kalten Schwanz und einem sich selten ändernden Kopfzustand aufgeteilt.
Das Problem, das wir zu lösen versuchen, besteht darin, dass Blockchains sich zwar hervorragend für die Bereitstellung byzantinischer fehlertoleranter Daten eignen, für die Zerlegung über viele Achsen jedoch weniger effektiv sind. Es ist nämlich sehr schwierig, eine Liste der Vorgänge zu erhalten, die ein Konto betroffen haben. Selbst den Kontostand auf einer Blockchain wie Bitcoin zu ermitteln, ist eine Herausforderung, wenn man nicht bereits über die Liste der Transaktionen verfügt.
Um diese Herausforderungen zu meistern, indizieren die Ledger Explorer Services die gesamte Blockchain. Es handelt sich um einen großen, kritischen und leistungsempfindlichen Dienst, der vollständig in Scala geschrieben ist und das verwendet Katzeneffekt Hochleistungslaufzeit. Wir haben eine Geschwindigkeit von über 10 U/s bei Bitcoin und behalten gleichzeitig eine Tail-P95-Latenz von unter 100 ms bei. Wir rekrutieren auch .
Ein bisschen Geschichte
Zu Beginn unserer Geschichte, lange bevor ich zum Unternehmen kam, wurde die Ledger-Datendienstschicht von einer eingebetteten Neo4j-Datenbank verwaltet. Jede Bereitstellungsbox indizierte ihre eigenen Daten und stellte sie lokal bereit, was viele Probleme verursachte.
Die Datenkonsistenz zwischen den Instanzen war nicht garantiert und die schiere Größe des zu indizierenden Zustands, kombiniert mit der neo4j-Festplatten- und RAM-Nutzung, war nicht skalierbar. Dieses Problem verschlimmerte sich nur mit dem Wachstum des Unternehmens, wodurch es immer schwieriger wurde, neue Instanzen zu erstellen.
Kassandra wurde dann als Haupttreiber dieses neuen Setups ausgewählt: Es handelt sich um eine geclusterte, horizontal skalierbare Datenbank, die auf der AP-Seite des CAP-Theorems steht. Es löst die Probleme im Zusammenhang mit der Datenfreigabe und ermöglicht eine klare Trennung zwischen der indizierenden, Blockchain-fähigen Komponente und den Headless-API-Servern.
Aber welchen Sinn hat es, den gesamten historischen Zustand zur Verfügung zu haben, wenn wir nie tatsächlich daraus lesen werden?
In unserem Anwendungsfall werden rohe historische Daten selten benötigt, da der Kontostatus unseres Benutzers daraus aggregiert werden kann. Dies veranlasste uns, die bestehende Datenspeicherlösung, die auf der verteilten Cassandra-Datenbank basiert, in Frage zu stellen.
Das Datenvolumen, das wir pro Blockchain speichern müssen, ist zwar im Terabyte-Bereich, aber nicht das, was man als „Big Data“ bezeichnen kann. Darüber hinaus ist der Teil, der zur Beantwortung der meisten Anfragen verwendet wird (auch bekannt als „Hot Path“), sogar noch kleiner. Heutzutage kann man problemlos handelsübliche Hardwareserver mit mehr als 16 TB NVMe-SSD-Speicher finden. Die vertikale Skalierung ist ein sehr leistungsfähiges Werkzeug, ebenso wie eine relationale Datenbank.
Schließlich war das Hauptproblem, das wir mit dem aktuellen Cassandra-Setup hatten, weder das verschwenderische Speichermodell noch der schlecht angepasste Datenanwendungsfall, sondern die mangelnde Entwicklerfreundlichkeit. Die Entwicklung einer neuen datenbasierten Funktion auf Cassandra hat sich als unnötig zeitaufwändig erwiesen. Wir haben uns bemüht, jede neue Achse zu implementieren, zu der wir Daten bereitstellen müssen.
Angesichts der Fachkenntnisse unseres Teams in den Bereichen Datenmodellierung und SQL-Kenntnisse, PostgreSQL war der perfekte Kandidat. Diese Lösung ist kampferprobt, robust und einfach zu erweitern, was sie zur idealen Wahl macht.
Warum wir SQL gegenüber NoSQL gewählt haben:
- Liest/schreibt Salden: Der Anwendungsfall für Blockchain-Daten ist stark auf Lesevorgänge und nicht auf Schreibvorgänge ausgerichtet (Blockchain schreibt nur sehr wenige Daten mit einer sehr vernünftigen Geschwindigkeit, selbst für eine Blockchain wie Polygon). Cassandra hat die Fähigkeit, eine sehr große Menge an Schreibvorgängen zu absorbieren – der Lesepfad ist es tatsächlich länger als der Schreibpfad.
- Unterstützung für die Indizierung: Indizes sind eine Schlüsselkomponente eines DBMS zur Beantwortung von Anfragen und neuen Geschäftsfällen oder -möglichkeiten. Cassandra bietet nur begrenzte Unterstützung für die Indizierung. Indizes sind nur wirksam, wenn die Abfrage bereits eine Möglichkeit angibt, die Partition, auf der die Abfrage ausgeführt wird, einzuschränken. Wir zahlen hier die Kosten für eine willkürlich verteilt Datenbank. Die PostgreSQL-Unterstützung für Indizes ist effizient, erweiterbar und am Rande.
- Aggregationsunterstützung: Gleicher Fall für Aggregation; Da Cassandra keine Multipartitionsaggregation zulässt und keine GROUP BY-Klausel in seiner Abfragesprache toleriert, ist seine Unterstützung irgendwie mangelhaft. PostgreSQL bietet eine umfassende Aggregationsunterstützung, auch für exotische Datentypen wie Bereiche und JSONB-Blobs.
- Datenmodellierung: Cassandra schränkt die Art und Weise, wie Datenmodellierung möglich ist, sehr, sehr ein. Für fast jede Anfrage, die Sie beantworten möchten, muss eine Tabelle erstellt werden, und die Daten müssen in große Zeilen denormalisiert werden (unter vollständiger Verwendung von breiter Spaltenspeicher Aspekt von C* und auch die Tatsache, dass Autoren spottbillig sind). Mit PostgreSQL können wir den relationalen Aspekt der Blockchain (Aufrufe, Transaktionen, Blöcke) nutzen und Speicherplatz sparen, wodurch die Wiederverwendung von Daten gefördert wird.
- Ad-hoc-Abfragen und Prüfungen: Durch die Möglichkeit, den gesamten SQL-Standard zu nutzen und beliebige Abfragen durchzuführen, können wir potenzielle Fehlerursachen untersuchen und suchen oder über explorative Daten für zukünftige Anwendungsfälle verfügen. Wir können die Datenbank wirklich als interaktives und intelligentes Tool und nicht als dummen Speicher nutzen. Dies geschieht auf Cassandra ohne einen umfangreichen und kostspieligen Analyse-Rechencluster wie Presto, Spark usw. (und da wir auf Bare-Metal-Servern laufen, haben wir keinen Zugriff auf leicht zu erstellende verteilte Datenanalysetools wie EMR).
- Speicherbelegung: Cassandra geht davon aus, dass Speicher sehr günstig ist und der Cluster problemlos mit neuen Maschinen erweitert werden kann. Das bedeutet, dass Alle Einschränkungen sowohl bei Indizes als auch bei Aggregationen müssen mit der Speicherung bezahlt werden. Keine global effiziente Indizes- und Join-Unterstützung bedeutet, dass wir für jede Achse, die wir abfragen möchten, eine Kopie der gesamten Tabelle denormalisieren und speichern müssen. PostgreSQL erspart uns Terabyte an Speicherplatz.
- Konsistenz: Da es sich bei Cassandra um eine verteilte, AP-orientierte Datenbank handelt (die Kommunikation erfolgt durch Klatschen zwischen Knoten), ist die Konsistenz nur bedingt in Bezug auf Schreibvorgänge gegeben. Sie können die Konsistenzrichtlinie jeder Anweisung sowohl für Lese- als auch für Schreibvorgänge optimieren, aber das Ziel dieser Datenbank bestand nie darin, eine starke Konsistenz zu erreichen. PostgreSQL wird seit langem für kritische Missionen eingesetzt und ist äußerst belastbar. Zentralisierung bedeutet auch, dass am Schreibpfad kein Netzwerk beteiligt ist.
- Transaktionen und MVCC:
- Transaktionen: Cassandra unterstützt nur leichte Transaktionen auf DML-Abfragen. Es kann eine gewisse Stapelverarbeitung angewendet werden (Dock), aber es gibt zahlreiche Einschränkungen, nämlich dass sich die Zeilen auf demselben Server (= Partition) befinden müssen, um keine horrende Leistung zu erzielen.
- MVCC: Cassandra unterstützt Zeilenzeitstempel, der vollständige MVCC ist jedoch nicht garantiert. Eine Komprimierung kann veraltete Daten löschen und es gibt keine Möglichkeit, C* mitzuteilen, dass dies nicht der Fall sein sollte (wie beispielsweise bei einer Transaktion in PG).
- PostgreSQL unterstützt ein starkes MVCC-Modell, das unseren Benutzern einen konsistenten Lesepfad gewährleistet.
- Werkzeugbau: PostgreSQL verfügt über viele weitere Tools, die häufig zum einfachen Betrieb der Datenbank verwendet werden. Darüber hinaus ein Werkzeug wie Weg fliegen stellt sicher, dass wir eine starke Versionierung des Datenbankschemas beibehalten. Wir haben es bereits erfolgreich in unsere Codebasis integriert. Für diesen Reifegrad gibt es bei Cassandra kein Äquivalent.
- Horizontale Skalierbarkeit: Dies ist das wichtigste Verkaufsargument von Cassandra. Fügen Sie einfach weitere Maschinen hinzu, wenn Ihre Daten wachsen. Für PostgreSQL gibt es kein Äquivalent, da Sharding und Partitionierung manuell vorgenommen werden müssen.
Wie wir skalieren wollen
Wie wir gesehen haben, besteht der einzige Nachteil bei der Verwendung eines Postgres-Setups in der Skalierung sowohl beim Lesen als auch beim Speichern. Was können wir tun, um diese Einschränkung zu überwinden?
Das erste wirksame Werkzeug, das uns zur Verfügung steht, besteht darin, jedes Protokoll oder jede Blockchain, die wir unterstützen, in eine eigene Datenbank zu unterteilen, damit sie je nach Volumen und Datenverkehr entsprechend skaliert werden kann. Die Segmentierung nach Geschäftsbereichen gewährleistet eine erste Skalierungsebene.
Indem wir dieses Konzept weiterentwickeln, können wir auch kalte, historische Daten in eine zeitliche Partition segmentieren. Die neuesten Versionen von Postgres haben die Benutzerfreundlichkeit partitionierter Tabellen erheblich verbessert, sodass Daten nahtlos über einen Maschinencluster hinweg verschoben werden können. Wir könnten zum Beispiel günstigere Maschinen mit weniger Rechenleistung verwenden, um den Großteil der historischen Daten zu hosten, während wir leistungsstarke, mit RAM gestapelte Giganten für den Benutzer behalten, um aggregierte Tabellen und die neuesten Vorgänge des Benutzers zu hosten.
Dieser Ansatz funktioniert in unserem Anwendungsfall sehr gut, da es im historischen Speicher keine partitionsübergreifenden Fremdschlüssel gibt (alles ist letztendlich an den Block angehängt). Aus Sicht des Hauptservers könnte mithilfe der Partitionierung und der Erweiterung postgres_fdw sogar transparent auf historische Daten zugegriffen werden.
Um all dies umzusetzen, haben wir uns auch mit der TimescaleDB-Erweiterung befasst. Diese Erweiterung fügt Basis-Postgres viele Funktionalitäten hinzu, und die meisten davon passen perfekt zu unseren Anwendungsfällen:
- Automatische Partitionierung von Tabellen basierend auf einer zeitähnlichen Spalte (in unserem Fall passen wir sie an, indem wir die Blockchain-Höhe als Referenz verwenden).
- Automatische, datentypbewusste und spaltenbasierte Komprimierung älterer Blöcke. Dies gewährleistet ein nahezu perfektes Komprimierungsverhältnis durch die Verwendung modernster Algorithmen für sehr ähnliche Daten.
- Effiziente zeitfensterbasierte Aggregation zur einfachen Berechnung historischer Salden und Marktdatendiagramme.
Wir stehen gerade am Anfang der Experimente mit der Speicherung, und dies eröffnet viele Anwendungsfälle. Proof of Concepts mit einer kleinen Datenmenge (~10 Blöcke im Ethereum-Mainnet, also etwa 2 Tage Daten) zeigte eine Reduzierung des Speicherplatzes um bis zu 40 %.
Wie wir gesehen haben, ist das Datenvolumen, sofern wir die richtige Strategie anwenden, kein Problem. Aber wie können wir mit der Größe unserer Nutzerbasis skalieren?
Hier haben wir bereits einen schönen Vorteil: Wir indizieren die gesamten Blockchain-Daten. Daher wächst der benötigte Speicher nicht mit der Anzahl der Benutzer, sondern mit der Gesamtgröße der Blockchain. Speicher- und Leseoptimierungen sind in ihrer Auflösung völlig orthogonal.
Dieses Setup, kombiniert mit dem sehr geringen Schreibbedarf im Verhältnis zum Lesevolumen, das bedient werden muss, ist das Traum-Setup für ein klassifizierendes Leader-Follower-Replikatmuster. Um die Leistung und den Durchsatz weiter zu verbessern, können wir die Postgres-Lesereplikate auch auf denselben Maschinen wie die API-Server platzieren und die UNIX-Domänen-Sockets nutzen, um die Netzwerk-Roundtrips zu überspringen.
Hier ist ein Beispiel für eine Datenreplikationsstrategie, mit der wir unsere Lesevorgänge skalieren könnten. Hellgraue Kästchen stellen einzelne Server dar. Wir können hier sehen, dass API-Pods direkt zusammen mit Replikaten der aktuellsten Daten platziert werden, um eine minimale Übertragungszeit zwischen Speicher und Benutzern zu gewährleisten. Die zuvor beschriebenen Archivinstanzen werden nicht dargestellt, um das Schema nicht zu sehr zu verkomplizieren.
Abschließende Bemerkungen
Als langjähriger Cassandra-Benutzer möchte ich betonen, dass es sich um eine großartige Datenbank handelt, die sich für eine Vielzahl von Anwendungen eignet. Leider wurde bei Ledger die Entscheidung getroffen, es aufgrund eines Datenanwendungsfalls zu verwenden, der nie zustande kam.
Die Produktivität unseres Teams wurde beeinträchtigt, und wir freuten uns auf die Herausforderungen, die wir lösen müssen, und beschlossen, in den sauren Apfel zu beißen und nicht auf den Irrtum der versunkenen Kosten hereinzufallen.
In vielen Fällen handelt es sich bei Ihren Daten nicht um Big Data. Die Verwaltung der Datenverteilung ist in den meisten Fällen keine schwierige Aufgabe, und die Kompromisse einer vollwertigen verteilten Datenbank müssen wirklich sorgfältig abgewogen werden. Der wichtigste Gesichtspunkt ist die Entwicklererfahrung, da dadurch wertvolle Zeit für die Entwicklung anderer Dinge frei wird. Dies ist der eigentliche Anwendungsfall, in den wir stark investieren müssen.
- SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
- PlatoAiStream. Web3-Datenintelligenz. Wissen verstärkt. Hier zugreifen.
- Die Zukunft prägen mit Adryenn Ashley. Hier zugreifen.
- Kaufen und verkaufen Sie Anteile an PRE-IPO-Unternehmen mit PREIPO®. Hier zugreifen.
- Quelle: https://www.ledger.com/blog/serving-web3-at-web2-scale
- :hast
- :Ist
- :nicht
- $UP
- 10
- 10k
- 20
- a
- Fähigkeit
- Fähig
- Zugang
- Zugriff
- Konto
- über
- berührt das Schneidwerkzeug
- automatisch
- hinzufügen
- Fügt
- haften
- Vorteil
- Anhäufung
- Algorithmen
- Alle
- erlauben
- erlaubt
- bereits
- ebenfalls
- Obwohl
- Betrag
- an
- Analyse
- Analytik
- und
- beantworten
- jedem
- etwas
- Bienen
- Anwendungen
- angewandt
- Ansatz
- passend
- Archiv
- SIND
- um
- Kunst
- Artikel
- AS
- Aussehen
- Aspekte
- Annahme
- At
- verfügbar
- bewusst
- ein Weg
- ACHSEN
- Achse
- Backend
- Balance
- Guthaben
- Base
- basierend
- Baseline
- BE
- weil
- war
- Bevor
- Anfang
- Ungetüme
- Sein
- Vorteile
- zwischen
- Big
- Big Data
- Bit
- Bitcoin
- Blockieren
- Blockchain
- Blockchain-Daten
- blockketten
- Blockiert
- beide
- Box
- Boxen
- Brings
- Fehler
- bauen
- Geschäft
- aber
- by
- rufen Sie uns an!
- Aufrufe
- CAN
- Kandidat
- Kappe
- vorsichtig
- Häuser
- Fälle
- Verursachen
- verursacht
- zentralisierte
- Kette
- challenges
- Herausforderungen
- herausfordernd
- Übernehmen
- Ändern
- billig
- billiger
- günstigere Maschinen
- Wahl
- Auswählen
- wählten
- gewählt
- klar
- Cluster
- Code
- Codebasis
- Kälte
- Kolonne
- kombiniert
- Ware
- Kommunikation
- Unternehmen
- Komplexität
- Komponente
- Berechnen
- konzept
- Konzepte
- Berücksichtigung
- betrachtet
- konsistent
- cool
- Kernbereich
- Kosten
- könnte
- erstellt
- kritischem
- Strom
- technische Daten
- Datenanalyse
- Datenübertragung
- Datenspeichervorrichtung
- Datenbase
- Tage
- Entscheidung
- beschrieben
- Design
- Entwickler:in / Unternehmen
- Entwicklung
- schwer
- Direkt
- Schmutz
- verteilt
- Verteilung
- geteilt
- do
- die
- Dabei
- Domain
- Nicht
- Nachteil
- Traum
- Fahrer
- zwei
- e
- jeder
- leicht
- Einfache
- Edge
- Effektiv
- effizient
- sonst
- eingebettet
- betonen
- ermöglichen
- ermutigend
- zu steigern,
- gewährleisten
- sorgt
- Gewährleistung
- Äquivalent
- etc
- Astraleum
- ETHEREUM-WARTUNGSNETZ
- Sogar
- schließlich
- ÜBERHAUPT
- Jedes
- alles
- Beispiel
- vorhandenen
- Exotisch
- dehnt sich aus
- ERFAHRUNGEN
- Expertise
- ERKUNDEN
- Forscher
- erweitern
- Erweiterung
- umfangreiche
- Tatsache
- Fallen
- Merkmal
- Eigenschaften
- wenige
- Finden Sie
- Vorname
- passen
- Aussichten für
- fremd
- vorwärts
- Freundlichkeit
- für
- voller
- vollwertig
- voll
- Funktionsumfang
- weiter
- Zukunft
- bekommen
- gegeben
- Global
- Kundenziele
- gehen
- Graphen
- grau
- groß
- Gruppe an
- Wachsen Sie über sich hinaus
- persönlichem Wachstum
- garantiert
- Richtlinien
- hätten
- hart
- Hardware
- Haben
- mit
- ganzer
- schwer
- Höhe
- Hilfe
- hier
- High
- hoch
- historisch
- Gastgeber
- HEISS
- heißesten
- Ultraschall
- Hilfe
- aber
- HTML
- HTTPS
- i
- ideal
- if
- unveränderlich
- wirkt
- Umsetzung
- verbessert
- in
- zunehmend
- Index
- Indizes
- Instanz
- integriert
- interaktive
- in
- Investieren
- beteiligt
- Problem
- Probleme
- IT
- SEINE
- join
- beigetreten
- jpg
- nur
- Aufbewahrung
- Wesentliche
- Tasten
- Art
- Mangel
- Sprache
- grosse
- Latency
- neueste
- Schicht
- geführt
- Ledger
- legitim
- weniger
- Niveau
- Hebelwirkung
- !
- leicht
- Gefällt mir
- Einschränkung
- Einschränkungen
- Limitiert
- Liste
- wenig
- örtlich
- Lang
- sah
- suchen
- Los
- Sneaker
- Maschinen
- gemacht
- Main
- Hauptnetz
- halten
- Mehrheit
- Making
- verwalten
- flächendeckende Gesundheitsprogramme
- manuell
- viele
- Markt
- Marktdaten
- Reife
- max-width
- Kann..
- Mittel
- Metall
- migriert
- minimal
- Missionen
- Modell
- Modellieren
- mehr
- Zudem zeigt
- vor allem warme
- schlauer bewegen
- viel
- sollen
- nämlich
- fast
- Need
- erforderlich
- Bedürfnisse
- Weder
- Netzwerk
- hört niemals
- Neu
- schön
- nicht
- Fiber Node
- nichts
- Anzahl
- und viele
- of
- on
- EINEM
- einzige
- betreiben
- Einkauf & Prozesse
- Entwicklungsmöglichkeiten
- or
- Auftrag
- UNSERE
- uns
- übrig
- Überwinden
- besitzen
- bezahlt
- Teil
- Parteien
- Weg
- Schnittmuster
- AUFMERKSAMKEIT
- Peer
- Peer to Peer
- perfekt
- Leistung
- Perspektive
- Ort
- Plan
- Plato
- Datenintelligenz von Plato
- PlatoData
- Schoten
- Points
- Datenschutzrichtlinien
- Vieleck
- möglich
- Postgresql
- Potenzial
- Werkzeuge
- größte treibende
- Praxis
- Aufgabenstellung:
- anpassen
- PRODUKTIVITÄT
- Beweis
- Anteil
- schlägt vor
- Protokoll
- zuverlässig
- die
- vorausgesetzt
- setzen
- Abfragen
- RAM
- Angebot
- Bewerten
- lieber
- Verhältnis
- Roh
- Lesen Sie mehr
- echt
- wirklich
- vernünftig
- Reduktion
- in Bezug auf
- bezogene
- zuverlässig
- Reorganisation
- antworten
- Replikation
- vertreten
- vertreten
- Anforderung
- federnde
- Auflösung
- entschlossen
- was zu
- Wiederverwendung
- Recht
- robust
- Wurzel
- rund
- REIHE
- Führen Sie
- Laufen
- gleich
- Scala
- skalierbaren
- Skalieren
- Skalierung
- nahtlos
- Suche
- Sicherheitdienst
- sehen
- gesehen
- Segment
- Segmentierung
- in XNUMX Minuten
- Verkaufsargument
- Leistungen
- Dienst
- kompensieren
- Setup
- mehrere
- sharding
- ,,teilen"
- Short
- erklären
- Seite
- ähnlich
- da
- Single
- Größe
- Fähigkeiten
- klein
- kleinere
- smart
- So
- Lösung
- LÖSEN
- Löst
- einige
- Raumfahrt
- Spark
- Laichen
- SQL
- Standard
- Bundesstaat
- Erklärung
- Lagerung
- speichern
- Geschichte
- Strategisch
- Strategie
- stark
- starker
- Erfolgreich
- Support
- Unterstützt
- Tabelle
- Nehmen
- Einnahme
- Aufgabe
- Team
- Technische
- erzählen
- AGB
- als
- zur Verbesserung der Gesundheitsgerechtigkeit
- Das
- Der Block
- Der Staat
- ihr
- dann
- Dort.
- Diese
- vom Nutzer definierten
- Dritte
- dritte seite
- fehlen uns die Worte.
- Durchsatz
- Zeit
- zu
- auch
- Werkzeug
- Werkzeuge
- Gesamt
- TOTAL
- der Verkehr
- Transaktion
- Transaktionen
- privaten Transfer
- transparent
- tippe
- Typen
- Letztlich
- für
- zugrunde liegen,
- Unglücklicherweise
- Unix
- entsperrt
- unnötigerweise
- us
- Nutzbarkeit
- Anwendungsbereich
- -
- Anwendungsfall
- benutzt
- Mitglied
- Nutzer
- Verwendung von
- gewöhnlich
- wertvoll
- Vielfalt
- vertikal
- sehr
- Volumen
- wollen
- wurde
- Weg..
- we
- Web2
- Web3
- GUT
- Was
- Was ist
- wann
- welche
- während
- Während der
- ganze
- warum
- breit
- weit
- werden wir
- mit
- ohne
- Werk
- schreiben
- geschrieben
- U
- Jüngste
- Ihr
- Zephyrnet