Un très bonne comparaison entre les performances de recherches d'Elasticsearch et MongoDB et le résultat est sans appels.

Sur la recherche, Elasticsearch est jusqu'à 20x plus rapide que MongoDB.

Sur les aggrégations, Elasticsearch est jusqu'à 38x plus rapide que MongoDB.

Sur l'insertion, MongoDB est 1.20x plus rapide que Elasticsearch.

Sur le parcours des données, Elasticsearch offre des performances stables quand MongoDB passe de 5 à 60 sec pour récupérer les derniers documents d'une collection.

Sur l'espace disque, MongoDB occupait 2x plus d'espace avec les mêmes données. (sans index!)

Ces benchmarks ont été effectués sur de grosses collections (dizaines de millions) mais les différences performances se font aussi sentir sur de plus petites collections.

Les performances seules ne doivent pas guider le choix mais aussi les features, par exemple les limitations d'Elasticsearch sont les suivantes:

• Near Realtime Search: les documents ne sont pas disponible immédiatement dans le search après écriture
• Pas de modification possible du type d'un champs d'une collection (int vers string par exemple)
• Pas de transactions
• Pas de pseudo-relationnel comme en MongoDB

Utiliser correctement une base de donnée relationnelle reste un exercice compliqué car il y a beaucoup de subtilité à comprendre.

Le plus important reste le concept d'index de lecture qui sont des structures permettant de retrouver plus rapidement de la donnée en échange d'un temps d'écriture plus long.

Le plan d'exécution des requêtes est aussi très important, l'auteur présente un exemple simple:

-- compute "now() - interval 3 days" then execute a table scan
publish_date < now() - interval '3 days'

-- for each line, compute "publish_date + interval 3 days and compare to now()"

publish_date + interval '3 days' < now()

Dans le deuxième cas, on va devoir récupérer chaque ligne et faire un calcul pour executer la requête. Il ne faut pas oublier que les bases de données relationnelles sont ensemblistes et donc faites pour fonctionner sur des ensembles de lignes plutôt que sur des lignes individuelles.

On parle souvent des comparaisons entre SQL et NoSQL mais cet article va plus loin en comparant les usages des 5 grandes familles de "Data Store"

• Base de données relationnelles (e.g. PostgreSQL)
• Base de données non-relationnelles (e.g. MongoDB)
• Base de données clé/valeur (e.g. Redis)
• Moteur de recherche (e.g. Elasticsearch)
• File de messages (e.g. Kafka)

Raft est un algorithme de consensus distribué très populaire qui permet de garantir la consistence d'un état au sein d'un cluster.

Il est utilisé dans des bases de données (CockroachDB, Mongodb) et dans d'autres produits comme Etcd.

Il couvre l'élection d'un master et la réplication de l'état sur chaque noeud.

Article explicatif de l'implémentation du Write-Ahead Logging (WAL) dans SQLite.

Le WAL est le mécanisme permettant de garantir que l'on ne perd pas de données lors de la persistence de la base de données sur le disque.

Un ensemble d'outils pour PostgreSQL.

Un outil pour explorer visuellement ses bases de données SQL

Une base de donnée qui propose les feature de Git !

On peut cloner sa base de donnée, faire des changements, les commits et merge dans master.

Je sais pas ce que ça vaut mais le concept est génial