[F] NoSQL %) - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, merci de cliquer sur ce lien

http://ozdc.net/dumps.php?dump=589 "oops" (gg les mails en prénom.nom@provider ^^)

erf

étrange car youporn à dégagé complètement mysql depuis qq jours, anapu possible les injections tout ca ^^

y'a d'autres failles que les injections, et MySQL n'en a pas le monopole de toutes façons ^^

loloops

c'est sur mais avec un truc nosql t'est bien plus en sécurité tout de même

ouais, faut tout gérer dans user.xml

Du strict point de vue "injection", la sécurité est uniquement liée au protocole, peu importe que ce soit du SQL, du NoSQL, ou n'importe quoi d'autre. Accessoirement tu ne peux pas arbitrairement remplacer tes bases SQL par du NoSQL, puisque comme leur nom l'indique ça n'est pas la même chose (et donc pas fait pour faire la même chose, et donc pas interchangeable).

(cela dit, mysql n'est pas vraiment du sql non plus )

lié au protocole, de mysql surtout !

ce n'est pas changeable comme ca de but en blanc, faut un peu de sueur au début mais après ca roule tout seul

on peut tout faire que se soit avec un ou l'autre, juste le principe de base diffère

une tentative d'injection dans la base nosql que j'utilise n'aura strictement aucune conséquence, tu récupère la clef nommé "truc" point barre, aucune interprétation du contenu de "truc" si tu rajoute des ', ", -- ou autre, simplement ca te jettera en disant que la clef n'existe pas, au contraire de sql qui lui t'ouvrira en grand sa porte

nosql == donne moi ca
sql == je voudrais les trucs comme ca

subtile différence, pourtant d'un coté tu est libre et de l'autre tu est asservis

après c'est comme tout faut faire gaffe, mais ici le loup n'est pas d'origine dans la bergerie

http://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983

r043v (./15977) :
on peut tout faire que se soit avec un ou l'autre, juste le principe de base diffère

Je peux planter un clou avec un stylo et écrire mon nom avec un marteau. Je vais juste vachement plus galérer.
Mais c'est vrai que j'ai moins de chances de me faire mal aux doigts avec le stylo.

Le problème à l'origine des injections SQL c'est pas que ce soit facile de récupérer des données, c'est que le SQL utilise par défaut de l'in-band signaling (pas de séparation entre les commandes et les paramètres, les deux sont mélangés au sein d'une même chaîne). Avec des requêtes paramétrées ce risque n'existe pas.

Zerosquare (./15979) :
Le problème à l'origine des injections SQL c'est pas que ce soit facile de récupérer des données, c'est que le SQL utilise par défaut de l'in-band signaling (pas de séparation entre les commandes et les paramètres, les deux sont mélangés au sein d'une même chaîne). Avec des requêtes paramétrées ce risque n'existe pas.

Mais ça fait quand même longtemps que dans la plupart des langages il existe des drivers SQL permettant de faire des requêtes paramétrées (et donc échappées correctement).

(oui ! J'aime quand, à votre insu, vous m'expliquez ce genre de chose ! )

avec un stylo plume j'écrit mon nom, avec un stylo à bille aussi

seulement le stylo plume peu baver aussi (faut pas oublier l'effaceur de "), il est plus compliqué car il faut le recharger, et écrire avec est plus long.

---

avec un vélo je peu aller au travail, avec le bus aussi

seulement avec le vélo je peu crever (à cause des " sur la route), je vais arriver en sueur, et le trajet sera plus long

---

il faut arrêter de voir le nosql comme une version allégé et sans fonctionnalité d'une base de donnée, c'est loin d'être le cas
il faut arrêter aussi de penser que c'est seulement pour des GROS truc ayant besoin d'un max de vitesse

c'est simplement une manière de stocker des données, une manière simple, rapide et très fonctionnelle, qui évite par sa simplicité pleins de choses comme justement les injections et apporte également beaucoup

pourquoi dire à ta base va me chercher l'user dont l'id est 4224 alors qu'on peu dire donne moi le contenu de "monsite:mesusers:4224" ?

c'est de la paraisse ? du masochisme ?

pourquoi galérer avec des tables prédéfinis avant de coder ou quant on doit rajouter un champs on doit reverifier l'intégralité des requêtes concernant cette table, alors que de l'autre coté on peu avoir des tableaux associatifs, de taille max 2⁶⁴, ou rien n'est obligé d’être figé ?

tu veut faire un facebook, le mec se décrit, choisi parmis une liste de 300 type de caractéristique, tu fait comment avec ton sql ? ta mis 300 champs dans la table ? non, tu va certainement creer une seconde table avec l'id de l'user, un champ caracteristique, et un champ valeur, ensuite pour recuperer ca tu va faire une requette de malade pour lier les tables entre elles

ici tu met seulement les carac que le gars remplis reelement, dans un hash tout con de ta table, pour recuperer le tout hgetall("monsite:mesusers:4224"); et tu recevra la fiche complète sans rien faire d'autre ...

pourquoi demander à ta base de recuperer la liste complete des users, select id from users where 1; quant tu as la possibilité de gérer des listes et d'en récupérer le contenu ?

pourquoi galérer à mettre en place un cron pour nettoyer ton sql des demande de récupération de password expirés alors que tu peu indiquer de l'autre coté qu'une clef va vivre n secondes et qu'ensuite elle sera détruite sans que tu ai qq chose à faire ?

ce n'est pas car l'on reviens à la simplicité que ce n'est pas fonctionnel, la voie prise étais peut 'être mauvaise depuis des années...

t'as jamais dév en sql ?
la différence entre vamechercher et donnemoi est vraiment légère... et tes données nosql, si tu ajoutes, supprimes ou modifie un champ, il se passe quoi à ton avis ? tu vas probablement être obligé de t'assurer que l'existant ne sera pas impacté...

300 champs dans la table ? déjà je suis pas sûr que ça soit nécessaire, ensuite l'idée d'avoir des tables en référence ça permet de mutualiser et d'optimiser la gestion de l'espace (parce que bon, si on continue dans ta pensée, ça veut dire qu'on va stocker 67 millions de fois "FRANCAIS" ?) la requète de malade, là encore, çe se simplifie avec les ORB ou alors plus encore en allant chercher dans les procédures stockées si c'est complexe ou dans les vues sinon...

donc si le mec il a watmille octets dans ses 300 champs mais que tu veux que son nom et son prénom tu load watmille octets ?...

les vues reprennent ta description des listes...

le coup du cron pour les password expirés là encore, y'a les procédures stockées et les triggers pour ça...

(et puis pour le "prédéfinis avant de coder" > tu ne sais pas ce qu'est l'analyse ? l'écriture de specs ? l'architecture ?)

vince (./15984) :
(parce que bon, si on continue dans ta pensée, ça veut dire qu'on va stocker 67 millions de fois "FRANCAIS" ?

45 millions, faut pas abuser

./15983 > Y'a aussi tout plein de trucs qui peuvent juste pas tenir de manière utile dans une base NoSQL, c'est aussi simple que ça.
Tu sembles réduire l'utilisation d'une base à pas grand chose. En fait, tu omets complètement la notion de structure des données, et justement, le critère relationnel. (Qui est un peu le principe d'un SGBDR)
Au final, à tout stocker dans une base NoSQL sans trop y réfléchir, tu risques aussi de te retrouver à recréer un SGBDR-like qui ne sera pas nécessairement aussi puissant qu'une vraie solution.
D'ailleurs, si stocker tout dans de bêtes HashTable était vraiment la solution à tous les problèmes, je pense qu'on aurait jamais inventé autre chose…

Au final, c'est vraiment débile. Rejetter les bases de données "traditionnelles" c'est débile. Chaque solution a ses avantages et ses inconvénients, et à chaque problème, il existe une solution plus adaptée que les autres, mais il ne faut surtout pas croire qu'il existe une réponse universelle quand il s'agit de stockage de données… (Sinon, c'est que de base tu t'étais attaqué à un ensemble de problèmes très restreint…)

(Et n'oubliez pas les métas-systèmes de gestion de données, comme X.500 ou LDAP )

Tiens je fais parti des "44% des professionnels de l'informatique qui n'ont jamais entendu parler de NoSQL". Merci pour les infos!

Rien à voir, mais c'est quoi cet énorme mytho dans les paramètres de "publicités facebook" (de mon compte):

Voici les faits :
Les publicités sociales affichent le message d’un annonceur à côté des actions que vous avez effectuées, telles qu’aimer une Page.
Vos paramètres de confidentialité s’appliquent aux publicités sociales.
Nous ne vendons pas vos informations aux annonceurs.

Nan mais y se foutent de nous!? Et y vivent de quoi alors?

Juste pour compléter le post de r043v avec qui j'ai décidément beaucoup de mal à être d'accord dès qu'il s'agit d'informatique, et si le sujet vous intéresse, le buzzword "NoSQL" désigne un concept bien plus large que les seuls moteurs de stockage "clé-valeur" (redis, memcached & co) qui ont été évoqués ici. Le premier paragraphe de l'article NoSQL sur Wikipedia résume pas mal l'idée générale.

> avec qui j'ai décidément beaucoup de mal à être d'accord dès qu'il s'agit d'informatique
mais j'avoue que j'aime débattre et me battre sur les forums

> la différence entre vamechercher et donnemoi est vraiment légère...

bien au contraire, c'est la différence fondamentale, d'un coté tu te repose sur le langage sql pour que celui ci se démerde et te récupère ce que tu veut, de l'autre coté c'est toi qui à conçus entièrement la structuration de tes données, donc tu sait exactement ou se trouve tes données et fait juste le nécessaire pour les récupérer

> et tes données nosql, si tu ajoutes, supprimes ou modifie un champ, il se passe quoi à ton avis ? tu vas probablement être obligé de t'assurer que l'existant ne sera pas impacté...

si tu change l'identifiant unique de ton user oui, forcement tu va renommer toute tes clef l'utilisant, chercher dans chaque liste l'id et devoir patcher ...
mais dans la réalité tu ne fera jamais ca, il change son nom d'utilisateur, tu va faire hset clef_user nick nouveau_nick

l'existant lui si il est bien conçu devra aller chercher le nick de l'user pour l'afficher, donc une mise à jour immédiate

et en sql tu fera exactement la même chose

sauf qu'en sql, tu va faire une requêtes compliqué pour qu'il te récupère aussi à la volé le nom d'user, ici tu le fait toi même

à noter que dans le cas de redis, tu peu lancer directement dans redis des scripts en lua pour éviter de multiplier les requêtes, et sans faire de lua, tu va pipeliner tes requêtes pour avoir le max de résultats en un seul appel

> 300 champs dans la table ? déjà je suis pas sûr que ça soit nécessaire

j'ai mis 300, 3000 aurais été plus judicieux, le truc c'est que le nombre de colonne est illimité, un user peu avoir 10 colonnes un autre 100, le code lui va regarder ce qui est dispo et faire en fonction, c'est une différence énorme !
c'est pour souligner le fait qu'en sql c'est figé à la création, ici c'est tres tres souple

> ensuite l'idée d'avoir des tables en référence ça permet de mutualiser et d'optimiser la gestion de l'espace (parce que bon, si on continue dans ta pensée, ça veut dire qu'on va stocker 67 millions de fois "FRANCAIS" ? )

non, ici en l'occurrence dans le cas d'un système avec plusieurs millions d'inscription comme tu le suggère je ferais une liste avec le nom des caractéristiques, et une liste par caractéristique pour contenir les résultats, histoire d'éviter les redondances

ensuite en réalité les carac de chaque users serais dans un hash dédié "monsite:mesusers:4224:carac" le nom de chaque valeur serais l'id de la carac, la valeur en elle même, l'id de la réponse

(pour pousser encore utiliser un phonème comme id des carac serais pertinent ici)

> donc si le mec il a watmille octets dans ses 300 champs mais que tu veux que son nom et son prénom tu load watmille octets ?...

non, je loade seulement les champs qui m’intéresse

redis> HMGET myhash field1 field2 nofield
1) "Hello"
2) "World"
3) (nil)

hmget est O(N) ou N est le nombre de champs à récupérer

pour avoir ses carac complètes sur sa fiche :

// je prend toute les carac
$res = $redis->hgetall("monsite:mesusers:4224:carac");

redis->multi() // pipeline start
foreach($res as $caracid => $value)
{
$redis->hget('monsite:mescarac',$caracid); // nom de la carac
$redis->hget('monsite:mescarac:'.$caracid,$value); // valeur de l'user pour cette carac
}
$carac = $redis->exec(); // je récupère tout

print('vos caractéristiques ...<br>');
$nbcarac = count($res)*2;
for($n=0;$n<$nbres;$n+=2) print 'carac : '.$carac[$n].', valeur : '.$carac[$n+1].'<br>';

voila, deux appels à redis, ou un seul en passant par du lua mais c'est encore différent

montre moi l’équivalent sql pour voir ?

ici je montre que c'est simple, pas de prise de tête avec des heures à debuguer, et surtout, ce n'est pas nécessaire d’apprendre le langage sql

> les vues reprennent ta description des listes...

j'en sais rien, c'est possible, mais il existe plusieurs type de liste ici

* les listes, pop/push droite gauche, insert, récupération de range depuis n'importe ou etc ...

* les sets, contenant des valeurs uniques, tu met 20 fois "hello" il n'est présent qu'une fois, c'est super utile, aucune vérification préalable à faire, pas de doublons, possibilité de croiser des set entre eux etc ...

* les zset, des set ou chaque entrée possède un "score" associé, genre pour les phonèmes entre français et francais à chaque fois qu'un user s'ajoute j'incrémente le score de son orthographe, le score le plus haut est considéré comme étant la bonne => le con qui à mis "francais" aura marqué dans sa fiche "français"
ici aussi on peu croiser les zset entres eux

donc, tu as des choses (encore une fois) simple, puissante, et aussi rapides

> le coup du cron pour les password expirés là encore, y'a les procédures stockées et les triggers pour ça...

et galère 100 ans pour mettre en place tout ça
ici $redis->expire("maclef",100); et dans 100 seconde elle n'existera plus, bien sur on peu aussi spécifier un timestamp unix de fin

> (et puis pour le "prédéfinis avant de coder" > tu ne sais pas ce qu'est l'analyse ? l'écriture de specs ? l'architecture ?)

bien sur que si, ici aussi je le fait hein, mais la souplesse que ca procure permet de modifier ensuite de manière bien plus simple qu'avec sql



je n'ai pas non plus dis que c'est la manière ultime de stocker ses info (et surtout chercher dedans)
mais, ce n'est pas diabolique


> Au final, à tout stocker dans une base NoSQL sans trop y réfléchir, tu risques aussi de te retrouver à recréer un SGBDR-like qui ne sera pas nécessairement aussi puissant qu'une vraie solution.

chercher qq chose est très simple en sql, like %truc% c'est pawa à mort, et ici c'est impossible !

par exemple j'avais fait ca : http://procvor.free.fr/postal/
pas prise de tête en sql, une table avec toute les villes, et je laisse le soin à mysql de chercher dans les 36000 communes mon code postal ou ma ville ...

ici j'ai du faire la même chose, mais ce n’étais pas réglé en deux lignes de sql
j'ai implémenté cette méthode, http://antirez.com/post/autocomplete-with-redis.html

et au final c'est ultra rapide, mais ca ma demandé bien plus de temps de dev :- )

après rien n’empêche d'utiliser les deux type de base suivant les besoin ...

> Sinon, c'est que de base tu t'étais attaqué à un ensemble de problèmes très restreint…

je crée des sites pas le système de gestion de la secu, d'origine mes blèmes sont restreints, le max à faire actuellement c'est une gestion de clients/produits/variantes/stock/commandes/promotions
bref, refaire plus ou moins prestashop et pour tout ça c'est très adapté

r043v (./15992) :
je crée des sites pas le système de gestion de la secu, d'origine mes blèmes sont restreints, le max à faire actuellement c'est une gestion de clients/produits/variantes/stock/commandes/promotions bref, refaire plus ou moins prestashop et pour tout ça c'est très adapté

Tant que tu passes pas les commandes avec, par exemple.
Et que t'as pas de contrainte légale sur tes données.

Accessoirement, pour l'utilisation dans le monde professionnel, il y a toute une ribambelle d'autres problèmes. Par exemple le coût est beaucoup plus élevé, les options de support sont quasi inexistantes, les admins ne connaissent pas et donc ont une chance beaucoup plus importante de faire une connerie, les mécanismes de backup/restauration sont pas encore secs, les interfaces non plus d'ailleurs ce qui dans un environnement de production est rédhibitoire. C'est supporté par un nombre de middlewares assez restreint...

les commandes en cours seront dedans bien sur :- )
celles archivées par contre non.
redis tourne en ram, je vais pas remplir la base avec des trucs inutiles

sur la question du support, la communauté est assez conséquente, et je peu facilement discuter avec le créateur de la base, et il écoute le retour des gens.
c'est tout de même un bon point, car pour un soucis mysql tu va simplement chercher sur google ..

les admins connaissent pas, ben écoute c'est pas bien compliqué, et il n'y à pratiquement, sinon rien à faire niveau maintenance, et il n'y à qu'un seul fichier de config

niveau sauvegarde, c'est simple, un seul fichier à sauvegarder, j'ai fait un .sh qui me sauve le fichier sur ftp toute les nuit à 4h du mat, j'ai en permanence le backup des 30 derniers jours.
de plus j'ai fait un utilitaire dédié au backup, rdd

la base se sauvegarde d'elle même dans ce fichier, et si le courant est coupé subitement, un fichier spécial permet de refaire une par une les commande non présente dans le dernier dump

> les interfaces non plus d'ailleurs ce qui dans un environnement de production est rédhibitoire

tu parles de quoi ?
si tu parle des clients pour se connecter il en existe un paquet
si tu parle d'un utilitaire complet en ligne de commande, il est embarqué avec la base et marche tres tres bien, redis-cli

> C'est supporté par un nombre de middlewares assez restreint...
c'est bien pour ca que mon framework web tourne exclusivement avec, et que je développe pour et avec redis au quotidien

certes, la base est jeune, mais assez mature, très stable et en développement constant

si je vous dit que je m’intéresse de plus en plus à node.js je vais me faire lyncher ? :- )

Allez, je saute dans le troll

r043v (./23) :
non, ici en l'occurrence dans le cas d'un système avec plusieurs millions d'inscription comme tu le suggère je ferais une liste avec le nom des caractéristiques, et une liste par caractéristique pour contenir les résultats, histoire d'éviter les redondances

Ho, du relationnel !

NB : tu devrais regarder du côté des BBD Objet ou dex BDD XML, je suis sûr que ça t'intéresserait...

r043v (./26) :
sur la question du support, la communauté est assez conséquente, et je peu facilement discuter avec le créateur de la base, et il écoute le retour des gens. c'est tout de même un bon point, car pour un soucis mysql tu va simplement chercher sur google ..

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.
Redis, je me tourne vers qui si j'ai un problème ? Une question ? Des obligations de temps de réponse à un problème ? J'ai un commercial disponible qui me permet de faire l'interface entre moi et les dev ? Quelle est l'assurance de qualité au niveau suivi de process derrière (type ISO, ITIL...) ?

r043v (./26) :
redis tourne en ram, je vais pas remplir la base avec des trucs inutiles

ç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à...

r043v (./26) :
niveau sauvegarde, c'est simple, un seul fichier à sauvegarder, j'ai fait un .sh qui me sauve le fichier sur ftp toute les nuit à 4h du mat, j'ai en permanence le backup des 30 derniers jours.

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 ?

r043v (./26) :
> C'est supporté par un nombre de middlewares assez restreint...

ç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.


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 ?
* 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)
Note : je ne dénigre pas la qualité de redis ou des bases nosql, c'est juste que c'est pas outillé pareil

Au risque de supporter r043v (mais comment on peut lire ton pseudo??):

spectras (./15994) :
les admins ne connaissent pas

Ca c'est absolument pas une bonne raison. L'évolution d'une manière générale, c'est savoir aller de l'avant quand des nouvelles technologies plus performantes se présentent. Et c'est particulièrement le cas dans nos domaines qui évoluent très vite. Je ne dis pas que NoSQL est plus performant, mais si je m'en tiens au simple fait que Google et Facebook l'utilisent, ça me paraît valable.
Je pense que ta phrase, elle veut simplement dire que quand on s'appelle Oracle, on a fait le choix de faire un soft qui est imbouffable à administrer sauf à passer les certifs de la maison dans le simple but de créer un parc de DBA pour faire du fric.
Et bin la 1ère occasion de s'en passer me plaît plutôt bien.

spectras (./15994) :
sont pas encore secs, les interfaces

(à remettre dans l'ordre) Et tu trouves les interfaces Oracle sympas? (pour ce qu'elles existent)

Google ou Facebook ont des contraintes très particulières que peu de structures rencontrent.

Le site des Anciens Amateurs Anonymes d'Andouille Acheminée par Avion Avant l'Aube n'a pas ces contraintes de charge exceptionnelle... ils ne doivent pas répondre à une demande atteignant le milliard de visiteurs uniques par mois (c'est le cas de google depuis 2011) ils ne disposent pas forcément d'un hébergement dernier cri...

Vouloir à tout prix comparer NoSQL et les SGBD/SGBDR n'aboutira pas, les réponses apportées par l'un ou l'autre ne répondent pas aux mêmes problématiques, un peu comme si on disait, "un vélo c'est pourri ça peut pas voler" qu'on y répondait "un avion c'est pourri ça peut pas faire des distances courtes sans infrastructure particulière"...

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é.