Caching. Teil 2: 60 Tage vor der Veröffentlichung

Hallo! Ich habe Ihnen bereits geschrieben, wie Sie Initiativen in einem Unternehmen fördern können. Genauer gesagt, wie (manchmal) dies gelingt und welche Schwierigkeiten auftreten können: Eine Rake-Retrospektive. Wie sich herausstellte, dass eine selbst erstellte Lösung cooler ist als eine bezahlte und wie wir uns für ein Caching-System entschieden haben. Teil 1 .

Heute möchte ich fortfahren und über den psychisch stressigsten Moment in diesem Projekt sprechen, über den die ersten beiden Artikel - als das Ergebnis des Projekts weniger von den technischen Fähigkeiten des Teams als vielmehr vom Vertrauen in ihre Berechnungen und der Bereitschaft, bis zum Ende zu gehen - bestimmt wurden.

Ich muss sagen - ich denke , dass das Projekt zu einem solchen intensiven Moment zu bringen - es ist ein Fehler weit verwendet etwa lshaya als jeder Heroismus durch das Projekt ausstreckt dieses Problem ....
Aber ich verstecke diese Erfahrung nicht und teile sie gerne - weil ich überlege:

  • Gerade Problembereiche sind Wachstumspunkte
  • Die größten Probleme "kommen" genau dort an, wo Sie es nicht erwarten

Die Kombination dieser Punkte verpflichtet Sie lediglich dazu, die wunderbare Erfahrung zu teilen, "wie man aus heiterem Himmel eine Dachrinne verdient". Es ist jedoch anzumerken, dass eine ähnliche Situation bei der Firma Sportmaster außergewöhnlich ist. Das heißt, es ist möglich, dass diese Situation erneut auftritt - Planung und Definition der Verantwortung jetzt - auf einer völlig anderen Ebene.

Es scheint also, dass die Einführung ausreicht, wenn Sie bereit sind - willkommen bei cat.



Juni 2017 Wir ändern das Admin-Panel. Das Admin-Panel besteht nicht nur aus einer Reihe von Formularen und Tabellen in der Weboberfläche. Die eingegebenen Werte müssen mit Dutzenden anderer Daten verknüpft werden, die wir von Systemen von Drittanbietern erhalten. Verwandeln Sie es außerdem irgendwie und senden Sie es letztendlich an die Verbraucher (die wichtigste davon ist die ElasticSearch-Website von Sportmaster).

Die Hauptschwierigkeit besteht darin, nur zu konvertieren und zu senden. Nämlich:

  1. Sie müssen Daten in Form von json mit einem Gewicht von jeweils 100 KB bereitstellen und einige werden für 10 MB angezeigt (scannen Sie nach Verfügbarkeit und Kriterien für die Lieferung von Waren an Geschäfte).
  2. Es gibt JSON mit einer Struktur, die rekursive Anhänge jeder Verschachtelungsebene enthält (z. B. ein Menü innerhalb eines Menüelements, in dem sich wieder Menüelemente befinden usw.).
  3. Die endgültige Aussage wird nicht genehmigt und ändert sich ständig (z. B. wird die Arbeit mit Waren nach Modellen durch einen Ansatz ersetzt, wenn wir nach Farbmodellen arbeiten). Ständig - dies ist mehrmals pro Woche, mit einer Spitzenrate von 2 mal pro Tag für eine Woche.

Wenn die ersten beiden Punkte rein technisch sind und von der Aufgabe selbst vorgegeben werden, müssen Sie sich beim dritten Punkt natürlich organisatorisch damit befassen. Aber die reale Welt ist alles andere als ideal, also arbeiten wir mit dem, was wir haben.

Sie haben nämlich herausgefunden, wie Webformulare und ihre Objekte auf der Serverseite schnell vernietet werden können.

Eine Person aus dem Team wurde in die Rolle eines professionellen „Form Slap“ berufen und führte mithilfe vorbereiteter Webkomponenten eine Demo für die Benutzeroberfläche schneller ein, als die Analysten die Zeichnungen dieser Benutzeroberfläche korrigierten.

Um jedoch das Transformationsschema zu ändern, entstand hier Komplexität.

Zuerst gingen wir den üblichen Weg - um die Transformation in der SQL-Abfrage zu Oracle durchzuführen. Es gab einen DB-Spezialisten im Team. Es dauerte bis zu dem Moment, als die Anfrage 2 Seiten fortlaufenden SQL-Text umfasste. Ich könnte weiter und weiter machen, aber als die Änderungen von den Analysten kamen - objektiv gesehen war es am schwierigsten, den Ort zu finden, an dem die Änderungen vorgenommen werden konnten.

Analysten ausgedrückt Regel in den Systemen, die, obwohl sie in etwas von dem Code (etwas von einem visio / draw.io / Gliffy) abgelöst gemalt wurden, aber es gab soähnlich wie Quadrate und Pfeile in ETL-Systemen (zum Beispiel Pentaho Kettle, der zu dieser Zeit zur Bereitstellung von Daten für die Sportmaster-Website verwendet wurde). Wenn wir keine SQL-Abfrage hätten, sondern ein ETL-Schema! Dann würden die Anweisung und die Lösung topologisch identisch ausgedrückt, was bedeutet, dass das Bearbeiten des Codes genauso lange dauern kann wie das Bearbeiten der Anweisung!

Bei ETL-Systemen gibt es jedoch eine andere Schwierigkeit. Der gleiche Pentaho-Wasserkocher - eignet sich hervorragend, wenn Sie in ElasticSearch einen neuen Index erstellen müssen, in den alle aus mehreren Quellen geklebten Daten geschrieben werden können (Anmerkung: Tatsächlich funktioniert der Pentaho-Wasserkocher nicht sehr gut, da er bei Transformationen kein Javascript verwendet in Verbindung mit Java-Klassen, über die der Verbraucher auf Daten zugreift. Aus diesem Grund können Sie etwas schreiben, das Sie später nicht in die erforderlichen Pojo-Objekte umwandeln können. Dies ist jedoch ein separates Thema, das vom Hauptgang des Artikels abweicht.

Aber was tun, wenn der Benutzer im Admin-Bereich ein Feld in einem Dokument korrigiert hat? Um diese Änderung auf die ElasticSearch-Website von Sportmaster zu übertragen, erstellen Sie keinen neuen Index, in den alle Dokumente dieses Typs, einschließlich eines aktualisierten, eingetragen werden können.

Ich wollte, dass, wenn sich ein Objekt in den Eingabedaten ändert, ein Update nur für das entsprechende Ausgabedokument an ElasticSearch der Site gesendet wird .

Okay, das Eingabedokument selbst, aber schließlich könnte es gemäß dem Transformationsschema durch Join an Dokumente eines anderen Typs angehängt werden! Sie müssen also das Transformationsschema analysieren und berechnen, welche Ausgabedokumente von der Änderung der Daten in den Quellen betroffen sind.

Die Suche nach verpackten Produkten zur Lösung dieses Problems führte zu nichts. Nicht gefunden.
Und als sie verzweifelt waren, fanden sie es heraus, aber wie sollte es im Inneren funktionieren und wie kann dies getan werden?

Die Idee entstand sofort.

Wenn die endgültige ETL in ihre Bestandteile zerlegt werden kann, von denen jeder einen bestimmten Typ aus einer endlichen Menge (z. B. Filter, Join usw.) hat, ist es möglich, dieselbe endliche Menge spezieller Knoten zu erstellen, die den ursprünglichen Knoten entsprechen mit dem Unterschied, dass sie nicht mit den Daten selbst arbeiten, sondern mit ihrer Veränderung?

Im Detail, mit Beispielen und Schlüsselpunkten in der Implementierung, unsere Lösung - ich möchte in einem separaten Artikel behandeln. Um mit unterstützenden Positionen fertig zu werden, ist ein ernsthaftes Eintauchen erforderlich, die Fähigkeit, abstrakt zu denken und sich auf das zu verlassen, was noch nicht manifestiert wurde. In der Tat wird es gerade aus mathematischer Sicht interessant sein und ist nur für diejenigen Habroviten interessant, die an technischen Details interessiert sind .
Hier kann ich nur sagen, dass wir ein mathematisches Modell erstellt haben, in dem wir 7 Knotentypen beschrieben und gezeigt haben, dass dieses System vollständig ist - dh unter Verwendung dieser 7 Knotentypen und der Verbindungen zwischen ihnen -, dass jedes Datentransformationsschema ausgedrückt werden kann. Die Implementierung basiert auf der aktiven Nutzung des Erhaltens und Aufzeichnens von Daten nach Schlüssel (nämlich nach Schlüssel ohne zusätzliche Bedingungen).

Daher hatte unsere Lösung eine Stärke in Bezug auf alle Einführungsschwierigkeiten:

  1. Die Daten müssen in Form von JSON geliefert werden -> Wir arbeiten mit Pojo-Objekten (einfaches altes Java-Objekt, wenn jemand die Zeiten, in denen eine solche Bezeichnung verwendet wurde, nicht gefunden hat), die in JSON leicht zu überholen sind
  2. Es gibt JSON mit einer Struktur, die rekursive Einbettungen jeder Verschachtelungsebene enthält -> wieder Pojo (Hauptsache, es gibt keine Schleifen, aber wie viele Verschachtelungsebenen nicht wichtig sind, ist in Java durch Rekursion einfach zu verarbeiten.)
  3. Die endgültige Aussage ändert sich ständig -> ausgezeichnet, da wir das Transformationsschema schneller ändern, als Analysten (in den Diagrammen) Wünsche für Experimente formulieren

Von den riskanten Momenten nur einer - wir schreiben die Lösung von Grund auf selbst.

Eigentlich ließen die Fallen nicht lange auf sich warten.

Besonderer Moment N1. Falle. "Gut extrapoliert"


Eine weitere organisatorische Überraschung war, dass gleichzeitig mit unserer Entwicklung das Haupt-Master-Repository auf eine neue Version umgestellt wurde und sich das Format, in dem dieses Repository Daten bereitstellt, änderte. Und es wäre schön, wenn unser System sofort mit dem neuen Speicher und nicht mit dem alten arbeiten würde. Der neue Speicher ist jedoch noch nicht fertig. Aber dann sind die Datenstrukturen bekannt und sie können uns einen Demo-Stand geben, auf den eine kleine Menge verwandter Daten gegossen wird. Geht?

Hier im Produktansatz wird bei der Arbeit mit dem Wertschöpfungsstrom eindeutig eine Warnung an alle Optimisten gehämmert: Es gibt einen Blocker -> die Aufgabe funktioniert nicht, Punkt.

Aber eine solche Abhängigkeit erregte nicht einmal Verdacht. In der Tat waren wir vom Erfolg mit dem Delta-Prozessor-Prototyp - einem System zur Verarbeitung von Daten auf Deltas (Implementierung eines mathematischen Modells, wenn Änderungen der Ausgabedaten unter Verwendung des Transformationsschemas als Reaktion auf eine Änderung der Eingabedaten berechnet werden) euphorisch.

Unter allen Transformationsschemata war eines das wichtigste. Zusätzlich zu der Tatsache, dass die Schaltung selbst die größte und komplexeste war, bestand auch eine strikte Anforderung, dass die Transformation gemäß dieser Schaltung durchgeführt werden musste - eine zeitliche Begrenzung für die Ausführung der gesamten Datenmenge.

Die Transformation sollte also 15 Minuten und keine Sekunde länger durchgeführt werden. Die Haupteingabe ist eine Tabelle mit 5,5 Millionen Datensätzen. In der Entwicklungsphase ist die Tabelle noch nicht gefüllt. Genauer gesagt ist es mit einem kleinen Testdatensatz in Höhe von 10.000 Zeilen gefüllt.

Nun, fangen wir an. In der ersten Implementierung arbeitete der Delta-Prozessor an der HashMap als Schlüsselwertspeicher (ich möchte Sie daran erinnern, dass wir Objekte viel nach Schlüssel lesen und schreiben müssen). Natürlich passen auf Produktionsvolumina im Speicher nicht alle Zwischenobjekte - daher wechseln wir anstelle von HashMap zu Hazelcast.

Warum genau Hazelcast - also weil dieses Produkt bekannt war, wurde es im Backend zur Site des Sportmasters verwendet. Außerdem ist dies ein verteiltes System, und wie es uns schien - wenn ein Freund etwas mit der Leistung falsch macht - fügen wir einigen Computern weitere Instanzen hinzu, und das Problem ist behoben. Im Extremfall - ein Dutzend Autos. Horizontale Skalierung und alles.

Deshalb starten wir unseren Delta-Prozessor für eine gezielte Transformation. Es funktioniert fast sofort. Das ist verständlich - die Daten sind nur 10 Tausend statt 5,5 Millionen. Daher multiplizieren wir die gemessene Zeit mit 550 und erhalten das Ergebnis: etwa 2 Minuten. Fein! In der Tat - ein Sieg!

Dies war ganz am Anfang der Projektarbeit - genau dann, wenn Sie sich für die Architektur entscheiden müssen, die Hypothesen bestätigen (Tests durchführen, die sie bestätigen), die Pilotlösung vertikal integrieren.

Da die Tests ein hervorragendes Ergebnis zeigten - das heißt, wir haben alle Hypothesen bestätigt und den Piloten schnell umgedreht -, haben wir ein vertikal integriertes „Skelett“ für ein kleines Stück Funktionalität zusammengestellt. Und sie begannen mit der Hauptcodierung - das "Skelett mit Fleisch füllen".

Was erfolgreich und energisch engagiert. Bis zu diesem schönen Tag, an dem ein vollständiger Datensatz in den Master Store hochgeladen wurde .

Führen Sie den Test für dieses Set aus.

Nach 2 Minuten hat nicht funktioniert. Ich habe auch nach 5, 10, 15 Minuten nicht gearbeitet. Das heißt, sie passten nicht in den notwendigen Rahmen. Aber mit wem es nicht passiert, wird es notwendig sein, etwas im Detail zu optimieren und zu passen.

Aber der Test funktionierte eine Stunde später nicht. Und selbst nach 2 Stunden gab es Hoffnung, dass er arbeiten würde, und wir werden suchen, was wir festziehen können. Hoffnungsreste waren auch nach 5 Stunden noch vorhanden. Aber nach 10 Stunden, als sie nach Hause gingen, funktionierte der Test immer noch nicht - es gab keine Hoffnung mehr.

Das Problem war, dass der Test am nächsten Tag, als sie ins Büro kamen, immer noch fleißig weiter funktionierte. Infolgedessen wurde 30 Stunden lang gescrollt, nicht gewartet, ausgeschaltet.
Katastrophe!

Das Problem wurde schnell genug lokalisiert.

Hazelcast hat - wenn er an einer kleinen Datenmenge arbeitet - tatsächlich alles im Speicher gescrollt. Wenn jedoch Daten auf einer Festplatte gespeichert werden mussten, sank die Leistung tausende Male.

Das Programmieren wäre langweilig und geschmacklos, wenn nicht die Behörden und die Verpflichtung, das fertige Produkt zu liefern. Wir müssen also buchstäblich einen Tag später, nachdem wir einen vollständigen Datensatz erhalten haben, mit einem Bericht an die Behörden gehen, wie der Test des Produktionsvolumens bestanden hat.

Dies ist eine sehr ernste und schwierige Wahl:

  1. Sagen Sie "wie es ist" = geben Sie das Projekt auf
  2. sagen Sie "wie ich möchte" = zu riskieren, vielleicht ist nicht bekannt, ob wir das Problem beheben können

Um zu verstehen, welche Gefühle in diesem Fall entstehen, ist es nur möglich, vollständig in die Idee zu investieren, den Plan für ein halbes Jahr umzusetzen und ein Produkt zu entwickeln, das Kollegen bei der Lösung einer großen Schicht von Problemen hilft.

Und so ist es sehr schwierig, deine geliebte Schöpfung aufzugeben.
Dies ist charakteristisch für alle Menschen - wir lieben das, in das wir uns viel Mühe gegeben haben. Daher ist Kritik schwer zu hören - Sie müssen sich bewusst bemühen, Feedback angemessen wahrzunehmen.

Im Allgemeinen haben wir festgestellt, dass es immer noch sehr, sehr viele verschiedene Systeme gibt, die als Schlüsselwertspeicher verwendet werden können. Wenn Hazelcast nicht passt, funktioniert definitiv etwas. Das heißt, sie beschlossen, ein Risiko einzugehen. Zu unserer Rechtfertigung können wir sagen, dass es noch keine „blutige Frist“ war - im Allgemeinen gab es noch eine gewisse Zeitspanne, um zu einer Backup-Lösung zu „wechseln“.

Bei diesem Treffen mit den Vorgesetzten gab unser Manager an, dass „der Test gezeigt hat, dass das System bei Produktionsmengen stabil funktioniert und nicht abstürzt“. In der Tat funktionierte das System stabil. 60 Tage

bis zur Veröffentlichung .

Besonderer Moment N2. Keine Falle, aber keine Entdeckung. "Weniger ist mehr"


Um einen Ersatz für Hazelcast mit der Key-Value-Data-Warehouse-Rolle zu finden, haben wir eine Liste aller Kandidaten zusammengestellt - wir haben eine Liste mit 31 Produkten. Das ist alles, was ich geschafft habe, zu googeln und von meinen Freunden herauszufinden. Darüber hinaus gab Google einige absolut obszöne Optionen heraus, beispielsweise die Hausarbeit eines Studenten.

Um die Kandidaten schneller zu testen, haben wir einen kleinen Test vorbereitet, der in wenigen Minuten nach dem Start die Leistung auf den richtigen Volumes zeigte. Und sie haben die Arbeit parallelisiert - jeder hat das nächste System von der Liste genommen, konfiguriert, den Test ausgeführt und das nächste genommen.
Sie arbeiteten schnell und schnappten mehrere Systeme pro Tag.

Beim 18. System wurde klar, dass dies sinnlos war. Unter unserem Lastprofil ist keines dieser Systeme geschärft. Sie haben viele Rüschen und Knicks, um die Verwendung zu vereinfachen, viele schöne Ansätze zur horizontalen Skalierung - aber das bringt uns keinen Gewinn.

Wir brauchen ein System, das den Schlüssel schnell auf einem Objekt auf der Festplatte speichert und den Schlüssel schnell liest.

In diesem Fall skizzieren wir den Algorithmus, wie dies implementiert werden kann. Im Allgemeinen scheint dies durchaus machbar zu sein - wenn gleichzeitig: a) die Datenmenge geopfert wird, die die Festplatte belegt, b) ungefähr Schätzungen der Menge und der charakteristischen Größe der Daten in jeder Tabelle vorliegen.
Weisen Sie etwas mit Stil Speicher (auf der Festplatte) für Objekte mit einem Rand zu, Teile eines festen maximalen Volumens. Dann mit den Indextabellen ... und so weiter ...
Es war ein Glück, dass es nicht dazu kam.

Die Erlösung erfolgte in Form von RocksDB.
Dies ist ein Produkt von Facebook, das zum schnellen Lesen und Speichern einer Reihe von Bytes auf der Festplatte entwickelt wurde. Gleichzeitig wird der Zugriff auf Dateien über eine Schnittstelle bereitgestellt, die dem Schlüsselwertspeicher ähnelt. Tatsächlich ist der Schlüssel ein Array von Bytes, der Wert ist ein Array von Bytes. Optimiert, um diese Aufgabe schnell und zuverlässig zu erledigen. Alle. Wenn Sie etwas Schöneres und Hochwertigeres brauchen, schrauben Sie es selbst auf.
Genau das, was wir brauchen!

RocksDB, in der Rolle des Schlüsselwertspeichers verankert, brachte den Zieltestindikator auf das Niveau von 5 Stunden. Es war weit von 15 Minuten entfernt, aber die Hauptsache war erledigt. Die Hauptsache war zu verstehen, was geschah, zu verstehen, dass das Schreiben auf die Festplatte so schnell wie möglich, schneller als unmöglich war. Auf SSD drückte RocksDB in verfeinerten Tests 400 MBit / s, und das war genug für unsere Aufgabe. Verzögerungen - irgendwo in unserem, in einem verbindlichen Code.

In unserem Code bedeutet dies, dass wir damit umgehen können. Nehmen wir es auseinander, aber wir können damit umgehen.

Besonderer Moment N3. Unterstützung. "Theoretische Berechnung"


Wir haben einen Algorithmus und eine Eingabe. Wir nehmen den Bereich der Eingabedaten, berechnen, wie viele Aktionen das System ausführen soll, wie diese Aktionen in den JVM-Laufzeitkosten ausgedrückt werden (einer Variablen einen Wert zuweisen, eine Methode eingeben, ein Objekt erstellen, ein Array von Bytes kopieren usw.) sowie wie viele Aufrufe an RocksDB sollte gehalten werden.

Berechnungen zufolge sollten sie 2 Minuten dauern (ungefähr, wie der Test für HashMap am Anfang gezeigt hat, aber dies ist nur ein Zufall - der Algorithmus hat sich seitdem geändert).

Und doch läuft der Test 5 Stunden.

Und jetzt vor der Veröffentlichung von 30 Tagen.

Dies ist ein besonderes Datum - jetzt kann es nicht mehr zusammenbrechen - wir haben keine Zeit mehr, zur Sicherungsoption zu wechseln.
Natürlich wird an diesem Tag der Projektmanager zu den Behörden gerufen. Die Frage ist die gleiche - Zeit haben, ist alles in Ordnung?



Hier ist der beste Weg, um diese Situation zu beschreiben - ein erweitertes Titelbild für diesen Artikel. Das heißt, den Chefs wird der Teil des Bildes angezeigt, der im Titel gerendert wird. Aber in Wirklichkeit - so.

Obwohl in Wirklichkeit natürlich - wir waren überhaupt nicht lustig. Und sagen Sie: "Alles ist cool!" - Dies ist nur für eine Person mit einer sehr starken Fähigkeit zur Selbstbeherrschung möglich.
Großer, großer Respekt für den Manager, für das Vertrauen in die Entwickler.

Wirklich, wirklich verfügbarer Code - zeigt 5 Stunden. Eine theoretische Berechnung - zeigt 2 Minuten. Wie kann man das glauben?

Es ist jedoch möglich, wenn: das Modell klar formuliert ist, wie zu zählen verständlich ist und welche zu ersetzenden Werte ebenfalls verständlich sind. Das heißt, die Tatsache, dass die Ausführung in der Realität mehr Zeit in Anspruch nimmt, bedeutet, dass in der Realität nicht genau der Code ausgeführt wird, den wir dort ausführen möchten.

Die zentrale Aufgabe besteht darin, "Ballast" im Code zu finden. Das heißt, einige Aktionen werden zusätzlich zum Hauptstrom zum Erstellen der endgültigen Daten ausgeführt.

Eilte davon. Unit-Tests, funktionale Zusammensetzungen, Fragmentierung von Funktionen und Lokalisierung von Orten mit unverhältnismäßig viel Zeitaufwand für die Ausführung. Es wurden viele Dinge getan.
Unterwegs haben wir solche Stellen formuliert, an denen Sie sich ernsthaft verschärfen können.

Zum Beispiel Serialisierung. Zuerst wurde der Standard java.io verwendet. Wenn wir Cryo jedoch befestigen, erhalten wir in unserem Fall eine 2,5-fache Erhöhung der Serialisierungsgeschwindigkeit und eine 3-fache Verringerung der Menge serialisierter Daten (was bedeutet, dass IO dreimal kleiner ist, was nur die Hauptressourcen verschlingt). Im Detail ist dies jedoch ein Thema für einen separaten technischen Artikel.

Aber der entscheidende Punkt oder „wo sich der Elefant versteckt hat“ - ich werde versuchen, ihn in einem Absatz zu beschreiben.

Besonderer Punkt 4. Empfang zur Lösungsfindung. "Problem = Lösung"


Wenn wir nach Schlüssel abrufen / setzen - in den Berechnungen ging es um 1 Operation, wirkt sich auf die E / A in dem Volumen aus, das Schlüssel + Objektwert entspricht (natürlich in serialisierter Form).
Was aber, wenn das Objekt selbst, auf dem wir get / set aufrufen, eine Map ist, die wir auch durch get / set von der Festplatte erhalten. Wie viel wird das IO in diesem Fall tun?

In unseren Berechnungen wurde diese Funktion nicht berücksichtigt. Das heißt, es wurde als 1 E / A für Schlüssel + Objektwert betrachtet. Aber in der Tat?

Beispielsweise gibt es im Schlüsselwertspeicher nach Schlüssel 1 ein Objekt obj-1 vom Typ Map, in dem ein bestimmtes Objekt obj-2 unter dem Schlüssel Schlüssel-2 gespeichert werden muss. Hier dachten wir, dass die Operation eine E / A für Schlüssel-2 + obj-2 erfordern würde. In Wirklichkeit müssen Sie jedoch obj-1 in Betracht ziehen, manipulieren und an IO senden: key-1 + obj-1. Und wenn es sich um eine Karte handelt, auf der sich 1000 Objekte befinden, ist der E / A-Verbrauch etwa 1000-mal höher. Und wenn 10.000 Objekte, dann ... so haben sie den "Ballast" bekommen.

Wenn ein Problem identifiziert wird, ist die Lösung normalerweise offensichtlich.

In unserem Fall ist dies eine spezielle Struktur für Manipulationen in verschachtelten Karten geworden. Das heißt, ein solcher Schlüsselwert, der für get / set zwei Schlüssel gleichzeitig benötigt, die nacheinander angewendet werden sollten: Schlüssel-1, Schlüssel-2 - das heißt, für die erste Ebene und für die verschachtelte. Wie man eine solche Struktur implementiert - ich werde es Ihnen gerne ausführlich erläutern, aber auch hier in einem separaten technischen Artikel.
Hier aus dieser Episode betone und bewerbe ich eine solche Funktion: Ein äußerst detailliertes Problem ist eine gute Lösung.

Fertigstellung


In diesem Artikel habe ich versucht, die organisatorischen Punkte und Fallen aufzuzeigen, die auftreten können. Solche Fallen sind „von der Seite“ oder im Laufe der Zeit sehr gut sichtbar, aber es ist sehr einfach, in sie hineinzukommen, wenn Sie sich zum ersten Mal neben ihnen befinden. Ich hoffe, jemand wird sich an eine solche Beschreibung erinnern und im richtigen Moment wird die Erinnerung funktionieren: "Ich habe so etwas schon einmal gehört."

Und vor allem - jetzt, wo alles über den Prozess erzählt wird, über psychologische Momente, über organisatorische. Jetzt haben wir eine Vorstellung davon, welche Aufgaben und unter welchen Bedingungen das System erstellt wurde. Nun - Sie können und sollten von der technischen Seite über das System erzählen - was für ein mathematisches Modell dies ist, welche Tricks im Code wir verwendet haben und an welche innovativen Lösungen wir gedacht haben.

Darüber im nächsten Artikel.

In der Zwischenzeit Happy New Code!

All Articles