Je suis amené à développer des applications en mode Web / intranet dans le cadre de mon travail. Le type d'application peut-être du genre : qualification de problèmes clients, gestion de contacts, outil de planification...
Après un passage PHP, je me mets depuis quelques mois à Python et il y a des chances que je m'attèle à ces nouveaux développement dans ce langage, bien que cela ne soit pas gravé dans le marbre.
Au niveau applicatif, et là aussi rien n'est complètement fixé, j'ai tendance à préférer des frameworks légers, peu contraignants de type BFG ou CherryPy.
Je suis assez libre niveau base de données et je m'intéresse au mouvement dit NoSQL, notamment pour la flexibilité apportée par le fait de ne pas s'imposer de schémas. J'ai d'ailleurs lu avec intérêt les récentes discussions qui ont eu lieu sur DLFP. Je cherche une base de données qui répondrait idéalement aux points suivants :
- Stockage d'objets sous une forme hiérarchique
- Performance correcte y compris à terme, c'est à dire une fois la base contenant plusieurs Go de données
- Si possible ACID-compliant, même si dans un premier temps l'éventuellement consistant ne pose pas de problème, il se pourrait que des transactions financières aient lieu et que celles-ci doivent être enregistrées, et il peut alors devenir gênant d'en perdre les traces
- Relativement stable, disons utilisable en production
Derrière ces quelques points, il y a des plus appréciables : mise en place aisée d'indexes, requêtage natif, réplication...
Il me semble, et arrêtez-moi si je dis des bêtises, que la plupart des bases de données XML natives, utilisées conjointement avec XQuery, ont l'inconvénient d'avoir du mal à partir de plusieurs Go de données et qu'elles ne sont en général pas particulièrement rapides face aux RDBMS traditionnelles.
Après quelques recherches, j'ai nominé, peut-être à tort, quelques solutions :
- La ZoDB, base de données objets Python, compatibles ACID, MVCC et apte à se répliquer. Le langage de requêtes est alors Python et il existe des paquets Python pour combler le manque d'indexes. La ZoDB est un produit assez ancien et matûre qui ne manquerait pas de rapidité et serait apte à tenir de gros volumes de données. Néanmoins, elle a une forte limite : n'être utilisable qu'en Python. Si le langage venait à évoluer, toute migration pourrait se faire dans la douleur.
- Parmi les ténors du NoSQL, j'ai noté MongoDB : très performante, langage de requêtes puissant, pensée pour la réplication, apte à traiter de gros volumes de données... Rien n'est parfait puisque MongoDB n'est qu'éventuellement consistante.
- Berkeley DB : (re)découverte en ce qui me concerne. Il semble que BDB réponde à l'ensemble des critères énoncés ci-dessus, du stockage hiérarchique (sous forme de b-tree), aux indexes en passant par la conformité ACID et MVCC, la réplication ou encore la fiabilité; et avec un petit plus : pouvoir être embarquée. Le fait que la BDB, dans sa licence libre, ait un copyleft fort ne me gêne pas du tout - les outils à développer sont soit internes, soit amenés à être libérés. Le défaut que je relève réside plutôt dans l'absence de langage de requête mais après tout, la ZoDB est elle-aussi dans ce cas. Je m'étonne assez d'entendre peu parler de BDB, notamment en ce moment, vu le nombre de documents tournant autour du NoSQL. Suis-je passé à côté d'une raison particulière ?
- CouchDB : peut-être la base qui fait le plus parler d'elle ces derniers temps. Elle répond semble-t-il aux prérequis : propriétés ACID, performances correctes, interface REST et donc ouverture à quasi tous les langages, requêtage puissant, map/reduce... Elle semble en revanche un peu plus compliquée à comprendre que les autres solutions citées ci-dessus et ne permet pas (je crois?) de requêter dynamiquement la base.
Bref, je vais expérimenter, mais si vous avez des idées / suggestions / conseils ou rectifications à apporter, je suis tout ouï.
Merci d'avance.
# MongoDB++
Posté par Bruno Michel (site web personnel) . Évalué à 3.
> il se pourrait que des transactions financières aient lieu et que celles-ci doivent être enregistrées, et il peut alors devenir gênant d'en perdre les traces
Tu peux partir sur MongoDB, et le jour où tu as à gérer des transactions financières, enregistrer ces transactions dans une autre base de données.
> Rien n'est parfait puisque MongoDB n'est qu'éventuellement consistante.
Le théorème CAP nous dit effectivement qu'on ne pourra jamais avoir de bases de données parfaites : entre Consistency, Availability et Network Partitions, on ne pourra jamais avoir que deux des trois propriétés en même temps.
# mouvement NoSQL
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
puis : http://stu.mp/2010/03/nosql-vs-rdbms-let-the-flames-begin.ht(...) (comme quoi, on peut toujours justifier --parfois ça le fait, parfois ça le fait pas-- de vouloir se passer du méchant --en fait plus compliqué/complexe qu'il en a l'air-- excuelle... mais soyons honnêtes et clairs : il ne faut pas espérer de l'ACID sans le relationnel --je ne parle pas du langage de requêtage qui est un autre problème-- ; on sacrifiera toujours quelque-chose...)
je confirme aussi que tu ne dis pas de bêtises : les BdD XML natives peinent avec de gros volumes mais on progresse (de plus en plus vers un mix des deux mondes ...à la Cassendra...?)
pour CouchDB, regarde bien l'aperçu fonctionnel ici : http://couchdb.apache.org/docs/overview.html ; c'est un mix entre le relationnel et l'objet et ça a été pensé d'abord pour la gestion documentaire... (tiens, comme MongoDB...)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.