kim (./27) :
Allez, je saute dans le troll
kim (./27) :
Ho, du relationnel !
c'est donc ca du relationnel
ca me parais incontournable, et je ne vois pas pourquoi redis ne le serais pas dans ce cas, et pourquoi mysql le serais ?
car son langage permet d'aller faire les relations plus ou moins automatiquement avec join ?
kim (./27) :
tu devrais regarder du côté des BBD Objet ou dex BDD XML, je suis sûr que ça t'intéresserait...
bdd xml ? c'est ce que je voulais faire ici ?
kim (./27) :
Une communauté c'est pas un support. MySQL, j'ai du support par Red Hat, Suse, ... ou Oracle. Si je rencontre un bug sur le produit, j'ouvre un incident chez eux.
$$$ ? même si j'utilise mysql je ne dépenserais jamais un seul € dans du support.
kim (./27) :
J'ai un commercial disponible qui me permet de faire l'interface entre moi et les dev ?
je suis septique sur le fait que se soit un bon point, la tu fait le téléphone arabe entre deux français, mais avec un chinois au milieu non ?
kim (./27) :
Quelle est l'assurance de qualité au niveau suivi de process derrière (type ISO, ITIL...) ?
développe la je ne comprend pas ^^ c'est quoi une garantie de résultat, de temps de réponse ?
si c'est ca, ici non bien sur, open source == "démerde toi, je ne suis pas responsable des éventuels dégâts tout ca"
kim (./27) :
ça tourne sur un système à répartition de charge ? c'est bien joli quand t'en as qu'un, de serveur, mais quand t'as une ferme sans persistance, ta ram, elle sert plus à grand chose, là...
oui tu peu répartir la charge, tu rajoute des "noeud" redis avec un système maître esclave, la réplication des données est automatique
la persistance est justement la, redis tourne exclusivement en ram, mais ce n'est pas memcache ! la base est sauvé comme je l'ai dit dans un fichier unique, et un second fichier reçoit les commandes réalisées entre deux dump, pour qu'en cas de crash ou autre tu retrouve ta base dans le même état
comme le dis le créateur, antirez, c'est aussi sécure q'utiliser une base classique https://twitter.com/#!/antirez/status/172779949860728832
kim (./27) :
Si tu lockes ton fichier pour backup, ça introduit une indispo de ton application. Pour un petit fichier, t'as l'impression que c'est transparent : ça ne l'est pas.
Ta seule option, c'est un snapshot au niveau FS. Et là, qu'est-ce qui me garantie que le fichier snapshoté est consistant ?
L'exemple con à pas faire, c'est le snapshot d'une base mysql, alors qu'elle est démarré : aucune garantie que tu peux redémarrer dessus. Sur ton NoSQL, qu'est-ce qui me garantie qu'on n'a pas le même problème ?
en fait le fichier n'est utilisé que quant la base démarre et quant elle est sauvé dedans, le reste du temps il n'est pas ouvert.
dans le .ini de redis tu va definir toi même quant la base doit se sauver dans le fichier,
le truc par default c'est ca :
################################ SNAPSHOTTING #################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving at all commenting all the "save" lines.
save 900 1
save 300 10
save 60 10000
quant la base se sauve, le process est forké, le dump se sauve dans un .tmp ensuite le système renomme le .tmp vers le fichier du backup
bref, moi j'ai fait mon .sh à l'arash pour l'instant :- ) oui je n'ai aucune garantie que le dump est valide, quant je le modifierais je ferais les choses bien, vérifier qu'il n'est pas ouvert, le renommer (si redis sauve ensuite aucun soucis vu qu'il ne l'utilise pas) puis le compresser et faire ma save par ftp ..
kim (./27) :
ça peut te paraitre bête, mais à partir d'une certaine taille, le middleware est essentiel. Quand tu veux faire causer les applications entre elles... Que t'as des applis qui tournent sur des OS farfelus ou du mainframe... Comment tu accèdes aux données sur ta base ? Le middleware est souvent la seule solution viable.
en fait il faudrait me définir vraiment ce qu'est un middleware ^^
car la je ne vois pas le soucis, il y à des clients pour pratiquement tous les langages, et redis-cli peut très bien être utilisé pour exécuter des commandes et recevoir les données sur la sortie standard
kim (./27) :
questions supplémentaires : * niveau sécurité, ça se gère comment ? connexion ssl à une "base" redis distante ? Les users autorisés sont gérés comment ?
niveau sécurité actuellement, un seul user, tu peu lui mettre un pass
les droits, tout ou rien, un type hier voulais pouvoir se connecter en read only, on lui à dit fait un layer pour évincer les commandes
http://groups.google.com/group/redis-db/browse_thread/thread/b7956e7985d95525 mais il y aura bientôt des esclaves en lecture seule
bon, vous aller crier au scandale, mais redis est single threaded, possède d'origine 16 bases distinctes dans chaque instance mais c'est tout, il est classique ici de lancer plusieurs instances de redis (sans partager le même dump hein)
sur sql tu donne des droits à des tables, ici tu donne actuellement les droits sur une instance complète, je suis d'accord qu'au moins faire des droits minimaux pour accéder ou non à des "sous bases" d'une instance serait appréciable.
le ssl j'en sais rien, après recherche rapide visiblement ca ne sera pas fait pour l'instant http://code.google.com/p/redis/issues/detail?id=71 il est conseillé de faire un tunnel toi même.
kim (./27) :
* y'a de la doc ? (note : http://redis.io/documentation c'est pas une doc, c'est un fourre-tout avec 2/3 trucs dedans, il manque plein de trucs de base)
la vrai doc c'est l'onglet command pas doc ^^ http://redis.io/commands
kim (./27) :
Note : je ne dénigre pas la qualité de redis ou des bases nosql, c'est juste que c'est pas outillé pareil
oui, c'est jeune, mais les possibilités augmentes de jours en jours
sinon, petite parenthèse, moi, voir de nouveaux horizons ca me plait, prendre des risques, découvrir, tester, être sur un fil c'est mon truc ^^
rester à sql c'est sur que c'est secure, ancienneté, robustesse etc mais ou est le plaisir dans votre quotidiens ensuite ?
c'est comme nginx que j'utilise en lieu et place d'apache, pas de .htaccess ou autre, on repart de 0, et je ne regrette aucunement mon choix
reste le langage de base à changer, actuellement php, j’hésite à utiliser node.js, le javascript c'est pas forcement mieux, et le full callback est tout de même assez risqué, je l'ai bien vu quant j'avais fait un gros truc en as3, des fois c'est compliqué.