Comment vendre une base de données open source

Influxdata vient de sortir la version 3 d’Influxdb sa base de données “temporelles”, avec une petite astuce sur le modèle de licence, pour continuer à faire de l’open-source sans se faire piller, comme certain de ses prédécesseurs.

Mais commençons par le commencement.

L’histoire ancienne

Postgresql

1996 MIT

Ingres, est né en 1982 comme projet universitaire à Berkley, pour travailler sur la notion de base de données relationnelle. Le leader de l’équipe Ingres va créer une entreprise, Ingres, puis finalement revenir à la fac et créer un deuxième produit, Post-Ingres, aka Postgres. Bascule vers le SQL en 1994, changement de noms en PostgreSQL en 96, début de la présence sur Internet avec la version 6, peu de temps après Mysql finalement. A part le faux départ Ingres, Postgresql a toujours été open source (MIT, donc team BSD) et maintenu par sa communauté.

Postgres a un écosystème complet, awesome comme on dit, qui va de la haute disponibilité avec Patroni de Zalando (en MIT), à de la sauvegarde continue avec Barman de 2ndquadrant (en GPL-3).

Personne n’est arrivé à accaparer Postgresql, fidèle à sa licence MIT, il permet l’apparition d’entreprise proposant des services complexes (et open source), en parallèle avec des outils communautaires.

Mysql

1995 GPL

Mysql a été crée comme un clone libre du maintenant oublié msql, par Mysql AB, comme le récite Wikipedia et toutes les pages qui le cite. Pas de trace d’une version antérieur à la version 3, il est donc facile d’imaginer qu’il y a eut deux versions privées, avant de créer l’entreprise éponyme, puis de commencer la conquête d’Internet en 1995, qui est une bonne date pour commencer un truc sur Internet : c’est l’arrivée du grand public sur le grand réseau mondial.

Mysql, est suffisamment souple pour propulser tout le web, du simple LAMP (Linux/Apache/Mysql/PHP) aux premiers GAFAs (Facebook, Flickr, Twitter, Wikipedia, Youtube, plus tard Github …).

Le bizness model ne suit pas, rachat par Sun, qui frustre le vendeur qui fork en MariaDB, et patatra, Oracle rachète un Sun moribond, et met la main sur ce qui reste moralement son concurrent.

Les gros utilisateurs bricolent de la réplication à échelle titanesque :

• Github parle de son gh-ost qui deviendra un produit (très confidentiel) sous le nom d’openark
• Twitter parle de son Gizzard qui a commencé par répliqué du Mysql avant de passer à autre chose. Mysql qui est toujours utilisé d’après leur billet récapitulatif de 2017 Scale
• Facebook parle régulièrement de Mysql et fournit myrocks, un fork de Mysql 5.6, sous licence GPL-2, qui utilise son moteur de stockage, rocksdb (successeur du leveldb de Google). Percona propose une version qui tourne comme module pour Mysql 8.0
• Vitess est le proxy utilisé par Youtube pour scaler du Mysql. Ce proxy a mis beaucoup de temps pour causer mysql avec les clients (et enfin devenir un vrai proxy).

L’entreprise Percona est la référence de fait pour Mysql, hors Oracle, et proposent des outils, de l’infogérence et surtout du consulting.

Il ne faut pas se mentir, le rachat de Mysql par Oracle en 2010 (via Sun en 2008), a cassé l’ambiance. Mariadb permet de rester droit dans ses bottes face au grand méchant Oracle, mais c’est tout, le fork d’arrière garde n’a pas les épaules pour proposer des innovations, ou même toucher quoi que ce soit.

Mysql a une chouette histoire, mais cette histoire est figé dans le marbre, et cette stabilité depuis toujours, pour toujours est ce que recherche ses utilisateurs. À part pour créer un Wordpress de plus, qui donc choisi Mysql pour un nouveau projet après 2020?

Sqlite

2000 Public Domain

Sqlite est une base de données relationnelles, avec tout ce qu’il faut de SQL, mais sans réseau, sans accès concurrents. Longtemps cantonné au rôle de base de données pour crétin qui ne savent pas installer une vraie base de données, Sqlite est maintenant la référence pour stocker des données complexes de manière pérenne, largement utilisé dans les téléphones portables.

L’ère du 2.0

Le Web a démarré en s’appuyant sur des outils existants, avant de commencer à créer des choses originales. Github devient rapidement incontournable et les utilisateurs distribuent des ⭐️ comme un gastronome de chez Michelin.

Mongodb

2007 24k⭐️ SSPL

Mongodb arrive en fanfare, pour sauver le web du méchant SQL et du modèle relationnel.

Bruyant et malhonnête (écriture sans sync pour aller plus vite, surconsommation de disques durs avant l’arrivé de Tiger…), il s’est ensuite calmé, et à forcé les autres bases de données à évoluer pour avoir du typage plus complexe (listes, tableaux…) ou plus simple (hstore, json…), plus proche des ORMs, par ce que ne nous mentons pas, de la base de données sans modèle, ça n’existe pas, le modèle est soit explicite, soit tacites. Mongo

Mongodb sera la première victime de la cloudification, et de manière prévisible, ça fera beaucoup de bruits.

Rethinkdb

2009 26k⭐️ Apache 2

En 2009, Rethinkdb trouve que Mongodb est un petit bras, et qu’il est possible d’exposer un AST dans le client pour devenir une requête dans la db. Création d’une boite avec le core dev, licence Apache 2.

Ça ne prends pas, mais 26k étoiles sur Github.

Pivot sur l’aspect temps réel (des événements pour les clients restent synchronisés), ça ne prends pas non plus.

Gros coup de frein en 2015.

Le core-dev tente un reboot base sur FondationDB, Refound, qui cartonne avec 11 étoiles sur Github.

Arangodb, ex Advocadodb

2012 13k⭐️ Apache 2

En 2012, encore dans la hype de Mongodb qui est un petit bras, Arangodb propose en plus du modèle orienté document, un modèle orienté graphe, et même du clef/valeur. En plus des requêtes en javascript comme Mongo, il y a un Query Language.

Gros coup de frein en 2017, mais un score honorable avec 13 milles étoiles Github.

Redis

2009 62k⭐️

Redis débute sa vie comme moteur de cache, du clef/valeur non relationnel avec des types complexes et les opérations adéquates pour les manipuler. Redis méprise les disques durs, tout doit tenir en RAM, mais bon, les tailles des barrettes ont grandis avec lui, et il y a quand même de la persistance (instantanés et journalisation) pour repartir directement cas de reboot. Il gère la réplication et la haute dispo.

Il n’échappera pas à la cloudification.

Elasticsearch

2010 65k⭐️

Elasticsearch commence par rendre accessible le trop théorique Lucene, outil de recherche full text, pour finalement devenir une base de données orientées colonnes, agréable à utiliser en cluster.

Elasticsearch a ensuite su pivoter, pour devenir un stockeur de logs, puis de time series, et de se diversifier avec tout un écosystème un peu confus avec des morceaux de libre mélangé avec des morceaux propriétaires, mais open-source.

Ça ne l’empêchera pas de se faire cloudifier aussi.

Clickhouse

2009 31k⭐️ Apache

Profitant de la hype des bases orientés colonnes, fort pratique pour analyser le comportement de ses clients, Yandex, le Yahoo des russes, libère son Clickhouse sous licence Apache. Yandex permet d’entasser trop de données, de jeter du SQL dessus, et d’obtenir des résultats rapidement sans passer par la case map-reduce du monde Hadoop.

ClickHouse est maintenant une boîte à San Francisco et Amsterdam, lève des fonds, et de chouettes projets commencent à l’utiliser (comme PostHog). C’est la phase “lune de miel”, tout est merveilleux, il faut devenir un standard de fait, puis on parlera bizness à ce moment là.

De manière très classique, Clickhouse se gère facilement sur une seul instance, bare metal ou conteneur, par contre, pour le cluster, il y a LE chois technique de l’équipe, avec un gros zookeeper, et comme ça piaille, ils ont fourni une API pour utiliser autre chose, mais comme ils n’utiliseront pas les alternatives en prod, bah, ce sera en l’état, à la communauté de bosser. Des outils tiers commencent à apparaitre, comme HouseWatch

Leveldb

2011 34k⭐️ New BSD

Google explique sa stratégie d’écriture sans modification (mais en consolidant périodiquement), et l’importance d’avoir des clefs ordonnées dans une base clef/valeur. Héritière de BigTable, leveldb est une réécriture complète, par ce que BigTable s’appuie sur des bibliothèques qui n’ont pas vocation à être libérées.

C’est du simple clef/valeur ordonnées, avec des itérations efficaces sur les clefs (d’où l’intérêt de les garder ordonnées), et des écritures par lot.

Pas de produit, pas de service.

Rocksdb

2012 26k⭐️ Apache 2

Facebook aime bien le concept de Leveldb et fork en Rocksdb pour d’aller plus loin sur le tuning spécifique au SSD (qui était nouveau à cette époque), d’exposer les journaux d’écritures pour avoir de la réplication, et de l’utiliser comme couche basse de persistance, un peu partout, comme Mysql par exemple avec Myrocks, ou simplement du cache.

Foundationdb

2017 13k⭐️ Apache 2

Apple reprend le concept d’une base clefs/valeurs ordonnées avec des écritures par lots, mais se focalise sur la notion de réplication cohérente au sein d’un cluster et sort discrètement Foundationdb. Comme “fondation”, elle se positionne comme outil de base niveau, sans protocole réseau spécifié, mais en fournissant le client adéquat dans différents langages (C, Ruby, Python, Java, Golang). Orienté performance, gros volume et fiabilité, Foundationdb demande à l’utilisateur de faire des efforts, en dénormalisant son modèle, en utilisant une serialisation qui ne casse pas l’ordre des clefs, et en recommandant de ne pas dépasser le ko pour les données, au pire 10k si on sait que l’on ne pas écrire/itérer trop souvent dans cette table, et la limite dure est 100ko.

Foundationdb se positionne clairement comme outil sur lequel construire des services (et potentiellement facturer), ce qu’Apple fait en interne.

Deno KV utilise Fundationdb, mais reste une arme secrète pour l’offre d’hébergement de Deno, les offres plus ou moins serverless basées sur javascript sont en pleine ébullition.

Les héritiers de Postgresql

Postgresql avec sa communauté maintient un logiciel vivant, et sa licence incite la création d’entreprise, qui en retour financeront (ou dédieront des développeurs) le projet.

Citusdb

2016 9k⭐️ AGPL

Citusdb fournit une extension, pour distribuer les données et les calculs dans un cluster, du stockage orienté colonnes (compressé).

La licence Affero brime les offres d’hébergement, et Citus réserve l’offre en Cloud à Azure dans son offre Cosmos-db

Timescaledb

2018 16k⭐️ Apache 2

TimescaleDB propose une extension, pour gérer les timeseries, avec du sharding basé sur la date de l’événement, du stockage orienté colonne (compressé). La version autohébergement est sous licence Apache, et ils gardent pour eux la version Cloud.

Neon

2021 10k⭐️ Apache 2

Neon se positionne comme un Aurora open source, en séparant le calcul du stockage. Le stockage s’appuie sur le WAL (Write Ahead Log) répliqué, pour créer des blocs immuables régulièrement consolidé (du LSM), qui seront à chaud sur un SSD, à froid sur un S3. Le sharding est une possibilité, mais pas la priorité immédiate.

L’idée étant d’avoir du serverless (du SQL over HTTP/Websocket), avec la possibilité d’éteindre les noeuds de calcul, sans remettre en cause la persistance, et de pouvoir dimensionner le calcul et le stockage indépendement. le site envoie du rêve en parlant de stockage sans fond, mais aussi de cold start qui se chronomètre en seconde, ce service n’est pas universel, ni magique.

Pour l’instant, il faut patcher les sources de Postgres (les modifications ont vocations à remonter) compiler et déployer. Neon n’a pas trop à craindre de la concurrence de son offre SAAS.

Alloydb

2022 propriétaire

Google fork Postgresql pour créer Alloydb, avec une architecture avec des nodes calcul/stockage, ressemblant à Neon, mais avec plus de violence : le stockage est orienté colonnes, la cible est donc de gros volumes de données sans modification, avec des reqêtes complexes.

Hors documentation utilisateur, Google communique peu sur les rouages de ce produit, qui doit recycler des outils existants, des éléments de Spanner, crée en 2012, avec un moteur SQL en 2017, l’année de l’offre SAAS public.

Alloydb semble être la réponse définitive à tous les utilisateurs de Spanner qui ralent sur la compatibilité Postgresql, Spanner ne gérant que le protocole.

Les héritiers de Sqlite

Rqlite

2014 14k⭐️ MIT

[Rqlite] se présente comme une base de donnée relationnelle distribuée, utilisant sqlite comme moteur de stockage. Il permet d’avoir des transactions, de la cohérence écriture puis lecture (la bagarre avec la réplication asynchrone), tout en restant simple et léger.

Projet communautaire sans offre d’une entreprise.

Litestream

2020 9k⭐️ Apache 2

En 2020, Litestream prouve qu’il est efficace de répliquer les modifications d’un sqlite vers quelque chose de pérenne, comme un S3, et de proposer des services simples.

Pas d’entreprise ni d’hébergement, c’est un projet “because we can”.

Litefs

2022 3k⭐️ Apache 2

Superfly utilise LiteFS la même réplication des journaux que Litestream, pour répliquer massivement et de manière asynchrone les écritures, suivant un motif primaire/secondaire avec un consensus Raft (du Consul). LiteFS est une couche de persistance pour l’offre serverless de Superfly, adapté pour des cas avec peu d’écriture concurrentes, et beaucoup de lecture qui bénéficieront de faible latence. Il se positionne comme plus performant que Rqlite, et plus qu’un simple backup comme Litestream.

Litefs est la vitrine technologique (en bêta) d’une offre Cloud volontairement sobre, pour se différencier des gros du Cloud.

Parquet

2012 2k⭐️ Apache 2

La fondation Apache adore rationaliser les écosystèmes éparpillés, et fournir des fondations saines sur lesquelles construire de s choses plus grande.

Inspiré par le Dremel white paper de Google, conçu pour Hadoop (et HDFS), Parquet est un format de stockage orienté colonne : les écritures se font par lot, on réécrit pour modifier, on peut lire que les colonnes de son choix. Le format est compact, compressé, optimisé pour la lecture et les performances. Imaginé pour remplir du HDFS et être lu par du java, il s’avère tout à fait apte à remplir du S3 et à être écrit/lu par tout les langages gérés par Arrow. Toutes les audaces sont permises, on peut écrire avec un logiciel, et lire avec un autre, utilisant une technologie différente, comme vous le faisiez avec du CSV ou du JSON.

Arrow

2016 12k⭐️ Apache 2 Arrow est la bibliothèque officielle pour lire et écrire du parquet, pour exposer des colonnes en RAM avec les primitives pour faire de l’IPC (discussion entre process) et du RPC (pareil, entre deux machines), avec tout ce qu’il faut de zéro copie et de binding dans moult langages (dont Numpy).

Datafusion

2016 4k⭐️ Apache 2 Datafusion est un moteur SQL utilisant Arrow, qui peut utiliser du Parquet, mais aussi du JSON, du CSV et d’autres formats. Les réponses sont du Arrow, et donc lisible en natif dans de multiples langages.

Ballista

2016 1k⭐️ Apache 2 Ballista permet de faire des requêtes avec Datafusion, mais en distribué.

Flight

2019 Apache2

Flight, basé sur grpc, implémente le début d’un protocole réseau :

• poignées de mains (handshake en VO)
• discussion direct entre noeuds avec un ticket pour amorcer une discussion authentifiée
• découverte de méta data
• authentification
• chiffrage
• middleware
• tracing (avec OpenTracing)
• du RDMA est prévu pour plus tard (les machines discutent de RAM à RAM, sans passer par le CPU)

FlightSQL

FlightSQL normalise le protocole réseau comme le faisait ODBC et JDBC, en s’appuyant sur Flight.

Il existe une extension pour causer à Postgresql en FlightSQL

Les autres bases de données

J’oublie volontairement les bases de données dédiées au big data (coucou Scylladb ou Cockroachdb), tout ce qui est orienté graphe, et les bases trop exotiques (ou qui sont passé sous mon radar).

Le projet database of databases tente l’exhaustivité, ce qui est assez fascinant.

La rationalisation par le nuage

L’innovation suit un chemin très classique : un démarrage plein de créativité, une rationalisation, et finalement une banalisation.

Les hébergeurs ont commencé par proposer la triplette machine virtuelle/stockage/réseau.

En y collant une API, c’est devenu le Cloud.

En étant suffisamment gros, vous avez du stock de machines, et donc la promesse de pouvoir ajouter rapidement de la ressource pour suivre un pic d’usage.

Ensuite, sont arrivés les offres de services, parfois des services open source existant, comme Mysql ou Postgresql, parfois des services maisons que la concurrence n’a pas.

GNU sent l’embrouille et crée en 2007 l’AGPL, comme du GPL, mais avec l’obligation de fournir les sources (sous la même licence) des patchs utilisés par un hébergeur.

S3, services spécifiques à AWS est devenu un standard de fait, cloné par tous les autres clouds.

Héberger des services open-source reste fairplay, c’est même le but de la famille BSD. Il y a juste une distorsion de concurrence avec la force de frappe commercial, les économies d’échelles. On peut ajouter à ça l’effet winner take all, le premier rafle tout, et l’assurance vie que propose ces demi dieux de l’informatique : ok, le projet n’a pas tenu la charge, mais qui aurait pu faire mieux que le glorieux Amazon/Google/Microsoft?! Fatalitas!! Ce n’est pas de ma faute.

Deuxième étape, une fois l’entreprise construite à partir de briques open-source (qui est aussi fait pour ça, pas de soucis), on peut passer à l’étape “moissonner le blé de l’open-source” : on prends un produit open-source, avec sa base utilisateur, sa réputation, ses threads de questions/réponses sur StackOverflow, et on l’intègre proprement à son offre Cloud : on peut commencer à vidanger l’offre “as a service” de l’éditeur, vers son offre Cloud.

Si on a un peu de temps, on peut créer un élément spécifique à un logiciel open-source, un élément taillé sur mesure pour son architecture logiciel, sur un thème un peu casse-gueule, comme la persistance, redondance ou performance.

Le plus connu est Aurora, un moteur de stockage distribué, sur lequel on peut poser un tout à fait classique Mysql ou un Postgresql.

Là, la cible est facile, il n’y a pas d’entreprises à piller (Oracle ne compte pas trop sur la vente de licence Mysql).

Quand AWS a proposé une offre intégré avec Mongodb, ça a un peu plus dérangé l’éditeur qui a riposté en changeant de licence pour SSPL, propriétaire. AWS a simplement crée un clone de Mongodb, Documentdb, propriétaire, avec une compatibilité sur le protocole.

AWS lance une offre intégré pour Elasticsearch, qui bascule en SSPL et une partie de son code passe en “open source lecture seule”. AWS fork pour créer OpenSearch qui reste sous Licence Apache 2.

Redis anticipe et bascule en free-core, le Redis “comme d’habitude” garde sa licence permissive, mais toutes les nouveautés, sous forme de modules, n’ont pas le droit d’être vendu par un hébergeur.

Le cas Influxdb

En 2013 le monde est prêt pour avoir une base de données temporelles open source : le Cloud permet d’avoir des services distribués, d’adapter les ressources à la charge, bref, on passe de la question binaire “le site est il disponible?” à la finesse de “quelles sont les performances pour quelle consommation”.

Tellement prêt que Soundcloud crée en 2012, Prometheus basé sur le Borgmon de Google. Ciblant le cloud, Prometheus est découpé en plusieurs services et suit le choix de Google : c’est la base de données qui va chercher les valeurs sur les services (un préfixe en HTTP) en attendant que tout le monde cause le prom, il faut déployer des sidekicks, comme blackbox, qui font les entremetteurs pour aller chercher les métriques.

Influxdb 1

Financé par Y-Combinator, Influxdb apparait en 2013, avec une approche minimaliste : un seul binaire à déployer, des agents poussent des données, avec une large compatibilité avec les agents déjà déployés.

Un faux SQL permet de faire des requêtes et des agrégations. Premier péché : personne ne doit créer un presque SQL, c’est extrêmement frustrant, autant créer un vrai DSL sans comparaison possibles, ou avoir du vrai SQL.

2015, changement de nom pour pour Influxdata, et créer une suite logicielle, avec Telegraf, un agent permettant d’envoyer des données depuis de multiples sources.

Coté interface utilisateur, Kibana, apparu en 2012 et dédié à Elasticsearch, fork en Grafana pour devenir multi bases, en 2013.

La citation d’Influxdb apparait dans un commit pour la première fois en février 2014. Prometheus est cité dans un commit pour la première fois en septembre 2015

Influxdata a donc une stack complète pour lire et écrire des métriques.

Influxdata se concentre rapidement sur son bizness model, propose un relais permettant de faire la réplication master/master (avec des données horodatées, immuables, on doit être dans le cas de réplication le plus simple), puis oups, l’interromps, ça brime son offre as a service. Des forks seront maintenus un temps.

Influxdb utilise une astuce pour avoir une base de code unique qui permet de fournir un monolithe open source, et de générer une version en microservices, spécifiques à l’offre commerciale, avec du protobuf et du raft.

La foule a choisi Prometheus qui a une communauté (bientôt cannibalisé par Grafana). Influxdb se repositionne comme timeseries pour le Edge, avec une offre on premise (les données restent chez vous), en plus du cloud, qui supporte un accès intermittent à Internet.

Influxdb 2

Il faut un second souffle.

Personne n’utilise directement l’influxql, il est tellement plus simple de cliquer partout depuis l’UI de Grafana.

Pour sa version 2, Influxdb sort un vrai DSL : Flux, et tord le bras de utilisateur pour qu’ils lâchent influxql, qui n’est plus géré dans la version libre, il faut une licence pour ça. Flux a une syntaxe élégante, basé sur la notion de pipe, les |> que l’on voit apparaitre dans les langages récents pour chainer les fonctions, sans avoir des tempêtes de parenthèses.

Le machine learning, qui deviendra l’intelligence artificiel, commence à se généraliser, Numpy a envie de manger de la métrique, pour faire de la prévision, ou même la très casse gueule recherche d’incohérences.

Le protocole réseau des requêtes réponds en JSON, comme tout bon REST, mais c’est loin d’être optimal pour envoyer des myriades de float.

Flux ne remplacera jamais Numpy ou même R, faire des requêtes dans deux langages en même temps est une punition, avec le risque de filtrer les données coté client (et non du coté de la base de données, ajoutant la latence de la connexion) et d’autre sous optimisation.

Influxdb 3

Nouveau pivot, Influxdb conserve Golang pour les couches hautes, mais bascule sur Rust pour la couche de persistance/requêtes, et crée IOx, prononcez eye-ox, oeil de boeuf. IOx s’appuie sur Parquet, qui fait sauter les contraintes de cardinalité qui peuvent mordre très fort et Datafusion qui permet d’avoir du vrai SQL avec des possibilité de jointures sur des bases de données relationnel externes.

influxql et Flux sont dépréciés, on peut parler de faux départ pour cette technologie pourtant élégante.

Avec le stockage en Parquet, techniquement, si vous avez envie de lire les données avec Clickhouse ou n’importe quel OLAP sympathique qui cause le Parquet, faites vous plaisir.

IOx est déployé dans Influxdb 3.0 annoncé la semaine dernière.

En normalisant(sous traitant?) les couches basses, Influxdb supprime deux drames, et se concentre sur son coeur de métier.

Nouvelle version, nouvelles licences.

Edge, un Open-core, monolithique, libre, sans compactage.

Community, gratuit, comme Edge, mais permet des requêtes sur des temps long, et du compactage.

Influxdata se réserve la partie cluster :

• Serverless, proche du mutualisé d’antan, où l’on paye à l’usage.
• Dédié pour envoyer du gros débit de manière prévisible.

Si vous avez des besoins de edge, vous n’avez qu’à synchroniser vos fichiers Parquet sur un S3 (ou un de ses clones), qui assurera la redondance. Les fichiers sont horodaté, ce sera facile d’effacer les vieilles données, ou de faire de la consolidation, pour perdre en granularité en échange de place.

Conclusion

Construire une base de données à partir de rien, tout seul est utopiste. Il faut mutualiser l’effort de développement et la construction de la base utilisateur, et sans se faire piller tout de suite. La couche de persistance, et donc le risque de perdre des données, est terrifiante. Pas mal de base de données innovantes (Mongodb, Influxdb, Prometheus…) ont débuté sur un moteur de stockage bricolé sur un coin de table avant de pivoter (ou racheter) sur quelques choses de plus crédibles.

Les efforts pour mutualiser les couches basses (stockage, requête, réplication…) du Big Data sont resté dans l’écosystème Java, avec un ticket d’entrée trop haut, golang s’est coincé tout seul avec un cout trop élevé pour faire des aller-retours avec du C qui le force à paraphraser en pure Go. Cockroach l’explique dans son billet expliquant la bascule de Rocksb vers Pebble.

Les tentatives de recycler le Innodb de Mysql n’ont pas abouti, mais on a vu apparaître des simples base de données clef/valeur (local comme Rocksdb, distribué comme Fundationdb) qui sont des bases saines pour construire une application.

Rust est la bonne réponse à Java pour fournir des outils juste au dessus de la couche de persistance, sans tirer tout un écosystème (et ses guerres de communauté).

Postgres, avec sa licence permissive et sa modularité reste incontournable pour ajouter des approches différentes (colonnes, géographie, graphes, vecteurs…) mais en gardant tout le reste (SQL, protocole réseau, client, réplication…). Pas mal de base de données récentes causent le dialecte Postgres pour profiter des clients (et UI) existants.

Distribuer une base de données sur plusieurs machines est compliqué, mais profiter d’une reprise sur l’incident qui arrive au milieu de la nuit est quand même chouette.

Les white papers sont disponibles, les briques logicielles libres existent, mais le travail pour fournir un service distribué est difficilement mutualisable et monétisable, surtout quand on se fait piller.

Utiliser des chouettes jouets sans pouvoir ouvrir le capot est frustrant, en plus d’être moins efficace et moins pérenne. Les gros du Cloud, comme tout le monde, ont besoin d’utiliser et produire de l’open source : Nanos gigantum umeris insidentes