ArangoDB est une base de données hybride (document et graphique). Ses aspects positifs comprennent:
- langage de requête puissant et pratique AQL
- JOIN (encore plus puissant que les bases de données relationnelles)
- réplication et partitionnement
- ACID (fonctionne dans le cluster uniquement dans la version payante)
Des fonctionnalités moins essentielles, mais non moins pratiques:
- recherche floue
- Moteur de microservices Foxx intégré à la base de données
- travailler en mode abonnement pour les modifications de la base de données
En toute honnêteté, je noterai également les inconvénients:
- pas d'ODM
- faible popularité (par rapport à MongoDB, par exemple)
Après avoir analysé les capacités d'ArangoDB et, surtout, après avoir surmonté les lacunes des dernières versions (comme une forte baisse des performances lorsque la taille de la collection de RAM disponible est dépassée) et l'apparition de nouvelles fonctionnalités (comme la recherche floue) , il est temps de le tester dans une application réelle.
Capacités AQL (ArangoDB Query Language)
L'une des principales questions qui m'inquiétait était de savoir si l'expressivité d'AQL serait suffisante pour exécuter l'ensemble des requêtes dans une application réelle. Et fonctionnera sans ORM / ODM être suffisamment confortable.
Il existe plusieurs façons dans ArangoDB d'interroger des données. Il existe une API orientée objet qui est familière à ceux qui travaillent avec MongoDB, mais cette méthode est considérée comme obsolète dans ArangoDB et l'accent principal est mis sur les requêtes AQL.
La requête la plus simple pour une collection ressemble à ceci:
db.query({
query: `for doc in managers
filter doc.role == @role
sort doc.@field @order
limit @page * @perPage, @perPage
return doc`,
bindVars: { role, page, perPage, field, order },
});
, FOR, , , , role .
, . mongoose (MongoDB) populate(). ArangoDB AQL:
db.query({
query: `
for mall in malls
for city in cities
filter mall.cityId == city._key
return merge(mall, { city })
`,
bindVars: { },
});
INNER JOIN. , city , , SQL.
LEFT JOIN — LET:
db.query({
query: `
for city in cities
let malls=(
for mall in malls
filter mall.cityId==city._key
return mall
)
return merge(city, {malls})`,
bindVars: { },
});
malls array null. , LEFT JOIN SQL — , city, mall. mall . , . "" , SQL, , .
, . , , , , , SQL. - NoSQL , .
- ArangoDB . : _from _to. , . .
- . , update . . , .
: , . , Elacticsearch. . -, Elasticsearch. , , . , -, Elasticsearch , .
ArangoDB SEARCH VIEW :
await db.createAnalyzer('fuzzy_brand_search_bigram', {
type: 'ngram',
properties: { min: 2, max: 2, preserveOriginal: true },
features: ['position', 'frequency', 'norm'],
});
await db.createView('brandSearch', {
links: {
brands: {
includeAllFields: true,
analyzers: ['fuzzy_brand_search_bigram'],
},
},
});
:
db.query({
query: `
for brand in brandSearch
search NGRAM_MATCH(
brand.name,
@brandName,
0.4,
'fuzzy_brand_search_bigram'
)
filter brand.mallId == @mallId
return brand `,
bindVars: { mallId, brandName },
});
ODM?
, , , AQL, . , Sequelize (ORM ), - RAW .
, , , ODM. , ODM ArangoDB. ODM . , ODM , . , , , .
, , . . - PATCH , , , . . , -, . issue . , , . , . .
Dans mon article, j'ai décrit et implémenté ma bibliothèque. Je l'ai utilisé dans un vrai projet. Bien sûr, il y a eu des moments de stress lorsqu'il s'est avéré que les capacités de cette bibliothèque n'étaient pas suffisantes. Mais ils ont été pour la plupart résolus. J'invite donc toujours ceux qui souhaitent promouvoir la technologie ArangoDB à la coopération.
apapacy@gmail.com
15 mars 2021