Wiederaufnahme von InceptionDB und seinen Optimierungen

Ich nehme InceptionDB wieder in Angriff, nachdem ich die letzten zwei Monate meine verbleibende Freizeit darauf verwendet habe, flowtest.io voranzubringen (ich möchte glauben, dass dies der Dienst sein wird, der die Art und Weise, APIs zu testen, revolutionieren wird).

Trotz der vergangenen Zeit erinnere ich mich noch genau daran, dass ich an der Leistungsoptimierung gearbeitet hatte und das psychologische Ziel verfolgte, eine Million Einfügungen pro Sekunde (auf einem einzigen Knoten) zu übertreffen. Die Million zu übertreffen war nicht schwer, aber mit der KI war ich darauf erpicht, die Million locker zu schaffen. Eigentlich war ich darauf erpicht, es ein wenig über das Absurde und Notwendige hinaus zu treiben, indem ich verschiedene Alternativen erkundete und die verschiedenen Abstraktionsebenen von Inception anging.

Ich habe die letzten Tests wiederholt und das Ergebnis ist so verrückt, dass es scheint, als wäre etwas falsch. Ich wähle den ersten Benchmark: INSERT, führe ihn aus und fast gleichzeitig ist er beendet. Das muss falsch sein! Das Log ist klar: Es hat 1 Million in weniger als 200 ms eingefügt, aber ich glaube es nicht. Ich denke, ich hätte die Persistenz deaktiviert und es arbeitet nur im Speicher, oder es gibt keine Parallelitätskontrolle und die Daten überlappen sich, oder es hat die gesendeten Daten gezählt, aber der Server hat sie nach /dev/null geworfen.

Ich misstraue dem Ganzen, mir fallen tausend weitere Gründe ein, aber ich setze einen Breakpoint direkt vor dem Löschen der Datenbank und führe erneut aus. Fast identisches Ergebnis trotz Debugging, aber jetzt habe ich dies: /tmp/inceptiondb_bench_811457574/col-1779494946505865611 und es ist nicht leer, belegt aber nur 41 MiB. Ohne lange zu überlegen, verschiebe ich es in das Datenverzeichnis meiner lokalen Inception, starte sie, lade die Seite und da ist es: 1M. Und es scheint, dass die Daten sogar korrekt sind.

Ich glaube es immer noch nicht, erstelle einen Index, führe eine Abfrage mit aufsteigender Sortierung durch und finde das erste Dokument, die 0. Ich ändere die Sortierung und auch das letzte Dokument, die 999999, ist vorhanden. Scheint alles in Ordnung zu sein. Ich höre auf, auf den Bildschirm zu achten, um zu überprüfen, ob ich noch atme.

Mir kommt die Idee, einen Blog-Artikel zu schreiben, aber zuerst wiederhole ich den Test. Dieses Mal mit 10 Millionen.

Fast 10 Millionen pro Sekunde, was schätzungsweise 410 MiB entspricht. Es ist offensichtlich noch weit davon entfernt, den Platten-Engpass zu erreichen, der in realen Tests bei 9,4 GiB/s liegt, nicht einmal 5%.

Der Benchmark enthält mehrere Tests zur Messung der Leistung spezifischer Szenarien: INSERT, PATCH, REMOVE, aber es gibt auch andere, an die ich mich nicht erinnerte: INSERTPK, INSERTBTREE, RETRIEVEBTREE, RETRIEVEFS.

Ich werde alle ausführen und die Leistung jedes einzelnen festhalten.

Im Allgemeinen wird bei allen Operationen die Million pro Sekunde übertroffen. Übrigens, lass mich dich daran erinnern, dass Throughput Open die gleiche Operation ist, aber beim Starten der Datenbank. Dies ist relevant, weil Inception ausschließlich auf Journaling basiert, um Daten zu persistieren. Um den Zustand wiederherzustellen, muss daher das gesamte Journal gelesen werden, bevor es wieder betriebsbereit ist.