CrateDB - CrateDB
 | |
| Développeur(s) | Crate.io, Inc. |
|---|---|
| Version stable | 4.5 / 31.03.2021 |
| Dépôt | https://github.com/crate/crate |
| Écrit en | Java |
| Système opérateur | Multiplateforme |
| Taper | Magasin de données |
| Licence | Licence Apache 2.0 |
| Site Internet | caisse |
CrateDB est un système de gestion de base de données SQL distribué qui intègre un magasin de données orienté document entièrement consultable . Il est open-source , écrit en Java , basé sur une architecture sans partage et conçu pour une grande évolutivité. CrateDB comprend des composants de Trino , Lucene , Elasticsearch et Netty .
Histoire
Le projet CrateDB a été lancé par Jodok Batlogg, un contributeur et créateur open source qui a contribué à l'Open Source Initiative Vorarlberg alors qu'il travaillait chez Lovely Systems à Dornbirn . Le logiciel est une base de données en cluster open source utilisée pour la recherche de texte et l'analyse rapides.
La société, maintenant appelée Crate.io, a levé son premier tour de financement en avril 2014. En juin de la même année, Crate.io a remporté le prix du choix du juge lors du concours GigaOm Structure Launchpad. En octobre, Crate.io a remporté le TechCrunch Disrupt Europe à Londres.
Crate.io a clôturé un cycle de fondation de 4 millions de dollars en mars 2016. En décembre, CrateDB 1.0 a été publié avec plus d'un million de téléchargements.
CrateDB 2.0, la première édition d'entreprise de CrateDB, a été lancée en mai 2017 après un tour de table de 2,5 millions de dollars de Dawn Capital, Draper Esprit, Speedinvest et Sunstone Capital.
CrateDB 4.0 est sorti en juin 2019.
Depuis septembre 2020, Crate.io est dirigé par Eva Schönleitner en tant que PDG.
Aperçu
Architecture
CrateDB fonctionne dans une architecture sans partage en tant que cluster de serveurs (nœuds) configurés de manière identique. Les nœuds se coordonnent pour distribuer automatiquement l'exécution des opérations d'écriture et de requête à travers le cluster.
Interrogation
La syntaxe SQL de CrateDB inclut les JOIN, les agrégations, les index, les sous-requêtes, les fonctions définies par l'utilisateur et les vues. Il prend également en charge la recherche en texte intégral, les requêtes géospatiales et les colonnes d'objets JSON imbriquées.
Pour la distribution des requêtes, CrateDB implémente des caches de champs en colonnes résidents en mémoire sur chaque partition. Les caches indiquent au moteur de requête s'il existe des lignes sur cette partition qui répondent aux critères de requête et où se trouvent les lignes. Ceci est effectué automatiquement.
Schémas
CrateDB prend en charge les schémas « stricts », « dynamiques » ou « ignorés » :
- Schéma strict : si une instruction INSERT inclut une colonne qui n'a pas été définie dans la table, CrateDB applique le schéma d'origine en rejetant l'INSERT et en lançant une erreur.
- Schéma dynamique : CrateDB met automatiquement à jour le schéma en indexant la nouvelle colonne.
- Schéma ignoré : CrateDB n'indexe pas la colonne, mais stocke la valeur JSON simple.
Cohérence
CrateDB implémente un modèle d'insertion de données non bloquant à terme cohérent . Il inclut la gestion des versions d'enregistrement, le contrôle de simultanéité optimiste et un paramètre de fréquence d'actualisation au niveau de la table, qui oblige les données CrateDB à devenir cohérentes toutes les n millisecondes.
CrateDB prend en charge la cohérence lecture après écriture : les requêtes récupérant une ligne spécifique par sa clé primaire reçoivent toujours la ligne la plus récente. Toutes les autres requêtes (opérations de recherche) renvoient des données cohérentes à terme.
Les opérations de recherche sont effectuées sur des IndexReaders partagés , qui fournissent des fonctionnalités de mise en cache et de recherche inversée pour les partitions. Un IndexReader est toujours lié au segment Lucene à partir duquel il a été démarré, ce qui signifie qu'il doit être actualisé pour voir les nouveaux changements. Par conséquent, une recherche ne voit une modification que si l'IndexReader associé a été actualisé après cette modification. Par défaut, cela se fait une fois par seconde, mais il peut être reconfiguré pour se produire plus ou moins fréquemment.
Chaque fragment de réplique est mis à jour de manière synchrone avec son fragment principal et contient toujours les mêmes informations. Par conséquent, en termes de cohérence, peu importe que l'on accède au fragment principal ou à un fragment de réplica. Dans CrateDB, seule l'actualisation de IndexReader affecte la cohérence.
Atomicité et durabilité
CrateDB implémente WAL ( écriture anticipée) :
- Les opérations sur les lignes (qui sont stockées en interne dans CrateDB en tant que documents JSON) sont atomiques.
- Les opérations sur les lignes sont conservées sur le disque sans avoir à émettre de validation Lucene pour chaque opération d'écriture. Lorsque le translog est vidé, toutes les données sont écrites dans le stockage d'index persistant de Lucene et le translog est effacé.
- Dans le cas d'un arrêt incorrect d'un fragment, les transactions dans le translog sont rejouées au démarrage, pour garantir que toutes les opérations exécutées sont permanentes.
- Le translog est également directement transféré lorsqu'un réplica nouvellement alloué s'initialise à partir du fragment primaire.
