ArangoDB-Anwendungsfall

Einführung

Als Softwareentwicklungsunternehmen arbeiten wir sehr oft an komplexe Anwendungen die mit vielen Daten umgehen müssen. Vor Kurzem standen wir bei einem unserer Projekte vor einer Herausforderung: Wir hatten viele Daten auf vielen Ebenen und wir mussten in der Lage sein, direkt mit diesen Dokumenten zu arbeiten.

Möchten Sie wissen, wie wir unser Problem gelöst haben?

Begleiten Sie uns auf unserer Reise, um es herauszufinden.

Aber lassen Sie mich zunächst unseren Hintergrund vorstellen.

Unsere Technologien

Bei Brainhub sind wir auf die Entwicklung von Apps mit JavaScript spezialisiert und verwenden dabei die folgenden Technologien:

• Im Backend:
• NodeJS als Plattform
• Express oder Koa als HTTP-Bibliothek/Framework
• Verschiedene DBMS, die einem bestimmten Bedarf entsprechen, hauptsächlich MongoDB und Redis
• RabbitMQ zum Anstehen
• Konsul für die Registrierung von Microservices
• GitLab CI oder Circle CI als Tool zur kontinuierlichen Integration
• Google App Engine, Bluemix oder eigene Server für den Einsatz

‍

• Im Web-Frontend:
• Reagieren
• Redux
• Redux-Saga
• Sscss
• Auf dem mobilen Frontend:
• Reagieren Sie nativ
• Auf dem Desktop-Frontend:
• Elektron

Was für ein Problem haben wir

Wir haben viele Daten über viele Stufen, was in einem Dokumentmodell viele Ebenen verschachtelter Dokumente bedeutet. Darüber hinaus müssen wir in der Lage sein direkt operieren auf diesen verschachtelten Dokumenten (Kinder, Enkelkinder, Urenkel usw.).

Wir müssen eine API erstellen nicht nur für unser Frontend, sondern auch für externe Integrationen. Der Benutzer sollte in der Lage sein, eine zu senden JSON-Schema, das später zur Validierung der bereitgestellten Daten beim Erstellen oder Aktualisieren verwendet wird, und es wird auch verwendet, um Dokumente aus verschiedenen Sammlungen zu verbinden.

Ein Beispiel für ein einfaches JSON-Schema:

{
„$schema“: "http://json-schema.org/draft-04/schema #“,
„title“: „Profile“,
„description“: „Profilschema“,
„type“: „Objekt“,
„Eigenschaften“: {
„ID“: {
„Typ“: „Zeichenfolge“,
„Beschreibung“: „ID“
},
„Adresse“: {
„Typ“: „Zeichenfolge“,
„description“: „Adresse“
},
„E-Mail“: {
„Typ“: „Zeichenfolge“,
„description“: „E-Mail-Adresse“
},
„Vorname“: {
„Typ“: „Zeichenfolge“,
„description“: „Vorname“
},
„Nachname“: {
„Typ“: „Zeichenfolge“,
„description“: „Nachname“
},
„Transaktionen“: {
„Typ“: „Array“,
„description“: „Liste der mit dem Profil verbundenen Transaktionen“,
„Artikel“: {
„title“: „Transaktionen“,
„type“: „Objekt“,
„Eigenschaften“: {
„ID“: {
„Typ“: „Zeichenfolge“,
„Beschreibung“: „ID“
},
„Gesamtbestellmenge“: {
„Typ“: „Zeichenfolge“,
„description“: „Gesamtwert der Transaktion“
},
„Rechnungen“: {
„Typ“: „Array“,
„description“: „Liste der Rechnungen im Zusammenhang mit der Transaktion“,
„Artikel“: {
„title“: „Rechnungen“,
„type“: „Objekt“,
„Eigenschaften“: {
„ID“: {
„Typ“: „Zeichenfolge“,
„Beschreibung“: „ID“
},
„Rabattprozent“: {
„Typ“: „Zeichenfolge“,
„description“: „Rabatt in Prozent“
},
„Artikelnr.“: {
„Typ“: „Zeichenfolge“,
„description“: „Artikel-ID“
}
}
}
}
}
}
}
}
}

 
Es gibt also die folgenden Lösungen:

• Dokumenten-Datenbank mit Fremdschlüsseln in den Dokumenten:
• Bearbeitung von Daten mit vielen Abfragen
• Betrieb mit einer einzigen Abfrage, wenn ein DBMS dies zulässt
• Relationale Datenbank:
• Manuelle Serialisierung/Deserialisierung
• FORM
• Graph-Datenbank
• Dokument-Graph-Datenbank mit mehreren Modellen

Welche Art von DBMS erwarten wir

Wir hätten gerne ein DBMS, das erfüllt:

• Open Source
• Hohe Leistung
• Gute Unterstützung für JavaScript/NodeJS
• Gute Gemeinschaft
• Unterstützung von ACID (Atomarität, Konsistenz, Isolationsfähigkeit, Haltbarkeit)

Andere nützliche Eigenschaften sind:

• Mehrere Modelle
• Leistungsstarke Abfragesprache

Potenzielles DBMS zur Auswahl

Wir lieben Open-Source-Lösungen, deshalb haben wir DBMS wie Oracle, SQL Server, DB2 und bei Lizenzproblemen MySQL eliminiert.

Wir haben eine gemacht Vergleich vieler No-SQL-DBMS (nicht nur für dieses Projekt, sondern auch um einen Überblick über andere Projekte zu haben, sind die Daten vom 18. Februar 2018):

Wir haben einige DBMS von der Spitze oben übernommen, aber eliminiert:

• Stufe DB — ist ein großartiges DBMS, aber für die Textspeicherung konzipiert, keine Dokumentenablage, die wir benötigen
• Beutel DB — obwohl es in diesem Rang höher ist als CouchDB, haben wir uns entschieden, stattdessen CouchDB in Betracht zu ziehen, da PouchDB im Allgemeinen für die Backend-Frontend-Synchronisation konzipiert ist, die wir in unserer App nicht benötigen, aber CouchDB ist ein DBMS, das typischerweise auf der Backend-Seite verwendet wird
• Memcached — ermöglicht das Zwischenspeichern von Daten wie Redis, aber nach genaueren Recherchen sieht es so aus, als ob Redis der unangefochtene Gewinner gegenüber Memcached ist. Darüber hinaus suchen wir nach einem dokumentbasierten DBMS, weshalb wir nicht mehr Schlüsselwert-DBMS als Redis in Betracht ziehen wollen
• Firebase-Echtzeitdatenbank — kein Open Source und scheint generell nicht gut genug zu sein, um das Risiko einzugehen, einige Fehler zu haben, die wir nicht beheben können
• Neo 4J — speziell für Java, aber nicht für NodeJS entwickelt und ist nicht dokumentbasiert

Darüber hinaus haben wir beschlossen, unter den SQL-DBMS nur PostgreSQL in unsere Forschung einzubeziehen, da es die Speicherung von JSON-ähnlichen Daten ermöglicht, die wir benötigen.

Basierend auf der obigen Tabelle und anderen Untersuchungen scheinen folgende DBMS unseren Bedürfnissen am besten zu entsprechen:

• MongoDB — das beliebteste Dokument-DBMS:
• Vorteile:
• NodeJS-Entwickler haben das größte Wissen über dieses DBMS
• Tolle Clustering-Optionen
• Nachteile:
• Fehlende Verknüpfungen — sehr wichtig für unsere Daten; das MongoDB Aggregation Framework ist sehr begrenzt und schwer zu debuggen
• Fehlende Transaktionen — wir brauchen ACID (obwohl in MongoDB 4.0 geplant)
• Fehlende ausdrucksstarke, dedizierte Abfragesprache — Abfragen nur in JSON
• Probleme können nur gemeldet werden in Jira aber nicht GitHub, das für die Open-Source-Community weniger benutzerfreundlich ist
• Couch DB:
• Vorteile:
• RESTful-API
• Nachteile:
• Fehlende Transaktionen — wir brauchen ACID
• DB neu denken:
• Vorteile:
• ReQL
• Verteilt
• Nachteile:
• Relativ langsame Leistung
• ArangoDB:
• Vorteile:
• Tolle Community — sehr hilfreiches Team am Slack
• Mehrere Modelle
• AQL
• Transaktionen
• Sharding und Replikation
• Nachteile:
• Immer noch nicht sehr beliebt, daher ist es praktisch unmöglich, Entwickler zu finden, die Erfahrung mit ArangoDB haben
• Relativ langsame Schreibvorgänge
• Redis:
• Vorteile:
• Super schnell
• Beliebt — unter den nichtrelationalen Datenbanken — nur MongoDB ist beliebter
• Das die meisten Sterne auf GitHub unter allen DBMS
• Nachteile:
• Nicht für dauerhafte Persistenz konzipiert (standardmäßig wird alles im RAM gespeichert)
• Keine Abfragesprache
• Sehr begrenzte Abfragen (nur sehr grundlegende Operatoren wie erhalten oder incr`)
• PostgreSQL:
• Vorteile:
• Sehr beliebt
• Unterstützt SQL
• Unterstützt viele Arten von Daten wie mehrdimensionale Arrays und benutzerdefinierte Typen
• Hat sich in der Produktion als sehr ausgereift erwiesen
• Nachteile:
• Das Ausführen von JavaScript auf PostgreSQL ist nicht sofort einsatzbereit (erfordert eine Erweiterung) und JavaScript ist niemals die Hauptsprache, die auf dem PostgreSQL-Server verwendet wird, da es immer in die SQL-Syntax eingebettet sein muss
• Obwohl benutzerdefinierte Funktionen und Datentypen sehr nützlich sind, scheint ihre Syntax aus einer alten Epoche wie Fortran oder Pascal zu stammen
• Die PostgreSQL-Json- und JSONB-Typen weisen im Vergleich zu Dokumentdatenbanken eine geringe Leistung auf
• Sharding in PostgreSQL ist nicht so einfach — es erfordert entweder die Verwendung eines Forks der offiziellen Datenbank-Engine oder eine Implementierung in der Anwendungsebene.
• Wie bei anderen relationalen DBMS ist ein Schema erforderlich, das die Erstellung eines einfachen MVP-Microservices verlangsamt.

Warum wir uns für ArangoDB entschieden haben

ArangoDB scheint so etwas wie MongoDB zu sein (wir haben die meiste Erfahrung mit MongoDB) mit einigen zusätzlichen Funktionen. Natürlich fehlen einige MongoDB-Funktionen wie das Aggregation Framework, aber in Wirklichkeit fehlt dieses nicht, sondern wurde durch etwas Benutzerfreundlicheres ersetzt — AQL + tritt bei.

ArangoDB bietet wie MongoDB Clustering, obwohl sich das ArangoDB-Clustering in der Produktion nicht als stabil erwiesen hat. Einer der Schlüsselfaktoren war ein sehr aktive Community. Es hat ein sehr niedriges Verhältnis von offenen Fragen zur Gesamtzahl der Probleme. Darüber hinaus kann jeder problemlos auf ArangoDB Slack zugreifen, wo das Support-Team sehr hilfreich ist. Auch in Stackoverflow geben sie angemessene Antworten.

Ein weiterer Grund war, dass ArangoDB ein mehrere Modelle DBMS, was nützlich ist, da wir planten, unsere Dokumente um die Verwendung von Grafiken zu erweitern.

Wie wir ArangoDB verwendet haben

Wir haben gebraucht die folgenden ArangoDB-Funktionen:

• AQL
• Transaktionen
• Admin-UI (nur für einige Debugging-Zwecke)

Wir sind potenziell beabsichtige Nutzung in der Zukunft:

• Graphen

In der ArangoDB-Shell haben wir eine sehr nützliche Funktion gefunden, die es in MongoDB nicht gibt. Um AQL zu lernen, wurden keine Daten in den Sammlungen benötigt, da es möglich ist, etwas wie das Folgende einzugeben:

db. _query ('für i in [1,2,3] gib i * i')

 
Da eine der Anforderungen darin bestand, die Daten aus vielen Sammlungen mithilfe des bereitgestellten JSON-Schemas zu erstellen, suchten wir nach einem ArangoDB-Abfrage-Builder.

Wir haben etwas gefunden, das ziemlich unbeliebt war und dem viele Funktionen fehlten, also haben wir unseren eigenen ArangoDB-Abfrage-Builder erstellt.

Wir haben eine abstrakte Schnittstelle erstellt, sodass beim Ersetzen von ArangoDB durch ein anderes DBMS nur die innere Implementierung geändert wurde.

Ein Beispielcode unseres Query Builders:

const QueryBuilder = () => {
const priv = {
//private Felder und Methoden
};

const pub = {
getQueryTree () {
gib priv.queryTree zurück;
},

fromSchema (Schema) {
priv.mainCollectionName = schema.title;
priv.queryTree.loop = `FÜR $ {schema.title} Artikel in $ {schema.title} `;
priv.queryTree.Sorting = `SORTIEREN $ {schema.title} item.id`;
//etwas mehr Code

Kneipe zurückgeben;
},

withLimit (Offset, Anzahl) {
//etwas Code
},

von Id (id) {
//etwas Code
},

byIdentifiers (Bezeichner) {
//etwas Code
},

byParentId (Sammlungsname, ID) {
//etwas Code
},

zu Aql () {
zurückkehren [
priv.toString (),
priv.bindungen,
];
},
};

Kneipe zurückgeben;
};

exportiere den Standard-QueryBuilder;

 
Wir haben JavaScript-Code erstellt, der auf dem ArangoDB-Server läuft, und wir verwenden diesen Code für die meisten Transaktionen.

//Diese Funktion wird auf dem ArangoDB-Server ausgeführt und kann daher nicht alle es6-Funktionen nutzen
const DbProcedure = (Parameter) => {
const db = require ('intern') .db;

const updateProperObject = () => {
const-Sammlung = db. _collection (params.myCollectionName);

gibt collection.updateByExample zurück ({id: params.newObject.id}, params.newObject);
};

const removeObjects = (Sammlungsname) => {
params.childrenIdsToBeRemove [Sammlungsname] .forEach ((id) => {
db. _Sammlung (Sammlungsname). removeByExample ({id});
});
};

/*
* Die verbleibenden öffentlichen und privaten Methoden
*/

const aktionen = {
erstellen,
aktualisieren,
entfernen,
überschreiben,
};

Aktionen zurückgeben [params.action] ();
};

exportiert Standard-DbProcedure;

 
Es war ziemlich cool, dass wir einige beliebte Bibliotheken wie Lodash sogar auf dem Datenbankserver verwenden konnten.

ArangoDB bietet ein HTTP-Framework namens Foxx was die Erstellung von Microservices vereinfacht, die eine Verbindung zu ArangoDB herstellen.

Wir haben uns jedoch entschieden Foxx nicht zu benutzen weil wir nicht wollten, dass unsere Microservices von einer Datenbank abhängig sind (wie es bei der Verwendung von MongoDB + Mongoose oder der direkten Verbindung zwischen Frontend und CouchDB-REST-API der Fall ist). Stattdessen haben wir erstellt abstrakte Modelle die intern ArangoDB verwenden.

Dieser Ansatz erwies sich als gute Wahl, da wir später an einigen kritischen Stellen des Systems ArangoDB durch Redis ersetzen mussten, um Engpässe zu beseitigen, die die Gesamtleistung beeinträchtigten.

Unsere Vorteile durch den Einsatz von ArangoDB

Dank AQL schreiben und debuggen Anfragen war viel einfacher als bei der Verwendung des MongoDB Aggregation Framework. Außerdem die Transaktionen waren sehr hilfreich. Sogar beim Laufen Javascript Code auf dem Datenbankserver war einfacher als in MongoDB, weil es möglich war, einige Bibliotheken wie Lodash zu verwenden.

Unsere Nachteile bei der Verwendung von ArangoDB

Leider war ArangoDB nicht schnell genug um eine sehr große Anzahl von Schreib-/Lesevorgängen in kurzer Zeit abzuwickeln (aber selbst mit anderen DBMS, z. B. MongoDB oder MySQL, wäre das Schreiben von Daten auf die Festplatte zu langsam). Deshalb haben wir uns bei einigen Microservices dafür entschieden ersetzen ArangoDB in Redis, das im Speicher arbeitet.

Aber selbst in dieser Situation war die Verwendung von ArangoDB eine bessere Wahl als MongoDB + Mongoose weil Mongoose-Modelle normalerweise die gesamte Architektur von DBMS abhängig machen.

Andererseits haben wir mit ArangoDB ein abstraktes Modell erstellt, sodass es relativ einfach war, ein DBMS durch ein anderes zu ersetzen.

Beachten Sie, dass MongoDB auch mit einem solchen abstrakten Modell verwendet werden kann — also sage ich nur, dass ArangoDB + unsere abstrakten Modelle viel besser sein können als MongoDB + Mongoose.

Bedeutung der wichtigsten Eigenschaften von ArangoDB