> Par curiosité (et parce que j'ai un peu la flemme de chercher :-p ), quelles sont lesdites limites ?
Je ne sais pas si on peut vraiment parler de « limites ». En pratique, les objectifs et cas d'utilisation de SQLite et de MySQL Embedded sont très différents.
SQLite s'efforce avant tout d'être une bibliothèque petite, compacte et le plus légère possible (en termes de ressources à l'execution comme en termes d'occupation disque). Richard Hipp, le développeur principal de SQLite, répète souvent que l'embarqué (le vrais, sur des machines où même la place sur disque est précieuse au KB près) est la priorité de SQLite, et qu'il est le secteur qui finance la plupart des développements. Par ailleurs SQLite est dans le domaine public, ce qui rend cette bibliothèque adaptée aux applications propriétaires et aux applications libres utilisant autre chose que la GPLv2 (licence de MySQL Embedded).
MySQL Embedded, en revanche, n'est pas réellement un système destiné à l'embarqué au sens strict (quoi que le nom laisse penser), mais plutôt une version « desktop » de MySQL. Les choix sont donc naturellement différents de ceux de SQLite ; ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture. Il offre aussi l'option de ne pas faire de fsync() après commit des données, ce qui permet de laisser à l'OS (au thread pdflush du noyau) l'opportunité d'aggréger les écritures de façon optimale, au risque de perdre 1 ou 2 secondes de données (probablement un bon compromis pour le type d'utilisation d'Amarok ; remarquez que ce fsync() obligatoire a posé de gros problèmes aux développeurs de Firefox lorsque ce dernier a adopté SQLite pour tout stocker).
En bref, MySQL Embedded cible les applications desktop, et Amarok est une application desktop, pour laquelle, en outre, la licence GPLv2 n'est pas un obstacle.
> Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
Certes non, mais les développeurs ont pourtant rapidement du faire face à des problèmes de performances insurmontables avec les grosses collections. D'après leurs dires, les performances sont devenues très correctes après qu'ils aient décidé d'adopter MySQL Embedded comme principal (et en fait, seul) moteur de stockage.
[^] # Re: Obligatoire
Posté par herodiade . En réponse au journal La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 10.
Je ne sais pas si on peut vraiment parler de « limites ». En pratique, les objectifs et cas d'utilisation de SQLite et de MySQL Embedded sont très différents.
SQLite s'efforce avant tout d'être une bibliothèque petite, compacte et le plus légère possible (en termes de ressources à l'execution comme en termes d'occupation disque). Richard Hipp, le développeur principal de SQLite, répète souvent que l'embarqué (le vrais, sur des machines où même la place sur disque est précieuse au KB près) est la priorité de SQLite, et qu'il est le secteur qui finance la plupart des développements. Par ailleurs SQLite est dans le domaine public, ce qui rend cette bibliothèque adaptée aux applications propriétaires et aux applications libres utilisant autre chose que la GPLv2 (licence de MySQL Embedded).
MySQL Embedded, en revanche, n'est pas réellement un système destiné à l'embarqué au sens strict (quoi que le nom laisse penser), mais plutôt une version « desktop » de MySQL. Les choix sont donc naturellement différents de ceux de SQLite ; ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture. Il offre aussi l'option de ne pas faire de fsync() après commit des données, ce qui permet de laisser à l'OS (au thread pdflush du noyau) l'opportunité d'aggréger les écritures de façon optimale, au risque de perdre 1 ou 2 secondes de données (probablement un bon compromis pour le type d'utilisation d'Amarok ; remarquez que ce fsync() obligatoire a posé de gros problèmes aux développeurs de Firefox lorsque ce dernier a adopté SQLite pour tout stocker).
En bref, MySQL Embedded cible les applications desktop, et Amarok est une application desktop, pour laquelle, en outre, la licence GPLv2 n'est pas un obstacle.
> Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
Certes non, mais les développeurs ont pourtant rapidement du faire face à des problèmes de performances insurmontables avec les grosses collections. D'après leurs dires, les performances sont devenues très correctes après qu'ils aient décidé d'adopter MySQL Embedded comme principal (et en fait, seul) moteur de stockage.