30

kim (./27) :
Allez, je saute dans le troll smile.gif
bisoo
kim (./27) :
Ho, du relationnel ! smile.gif

c'est donc ca du relationnel cheeky
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 ? smile.gif 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 cheeky

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 cheeky
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 smile.gif

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é.
et la le mec il le pécho par le bras et il lui dit '

31

vince (./29) :
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...


sauf qu'ici sur une seule dedibox à 15€ je cale moult et moult site d'andouillette, dans la dedibox c'est le 1go/sec de bande passante qui rulez

quant je tournerais un peu mieux je prendrais celle à 8 coeur, et 16go de ram qui coute ... 50€

j'ai un projet équivalent à e-monsite, jimdo, oneandone mywebsite (qui en fait est jimdo) etc ... de jour en jour ca avance, donc les sites eux même non c'est inutile, mais si t'en à 1000 sur un serveur sans le mettre à genoux c'est pawa
vince (./29) :
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"...


il faut jongler avec habilement, mysql est tout de même sur le serveur, pour héberger des forum fluxBB ...
le reste je développe from scratch, je me permet de prendre ce qui est le plus rapide actuellement et aussi le plus simple/efficace à mon sens
vince (./29) :
Google ou Facebook ont des contraintes très particulières que peu de structures rencontrent.


qui peu le plus peu le moins ?
est ce que c'est parseque sur un simple mac book air ca atteint les 500000op/sec en pipelinant que je ne doit pas l'utiliser ?

de nos jours les app (web ou autre) ne restent plus statiques, droite, carré, mélanger les techno est pratiquement obligatoire, c'est risqué mais c'est la direction prise actuellement, et dans le web on le fait depuis longtemps, donc pour moi c'est normal
redangel (./28) :
r043v (mais comment on peut lire ton pseudo?? confus.gif ):

grin

r zero 43 v

mon pseudo irl de toujours à été mon nom mis à la russe (en 4eme on apprenais staline tout ca happy) soit, noferov, contracté en rov (prononcé roff), ensuite sur irc vu que je développais souvent ca faisais rov|dev => r0|dev => r043v cheeky
redangel (./28) :
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.


tu peut pourtant, dans la grande majorité des cas se sera certain, ensuite c'est des question d'implémentation de chose non évidente à faire avec, genre, l'exemple de l’auto-complétion

fb et gg d'origine les ont conçus/utilisés car la "fixité" des table mysql n’était pas du tout bonne pour eux, trop de colonnes, trop d'info, et si un site prend 100 colonnes et un autre 10000 c'est inutilisable

être figé dans un seul "protocole" c'est mauvais, combien de langage existent ? combien de librairies graphiques ? d'os ? ... ??!

les bdd avais beau avoir une multitude d'implémentations, c'était encore et toujours la même structure le même langage, les même points fort et faiblesses

le nosql débarque et chamboule toute cette dictature, c'est de bonne augure bien au contraire !

voyez le comme un outil puissant en complément (ou non), prenons mirari par exemple, associer un code unique à une url c'est totalement indiqué pour utiliser du nosql, avec à coté un node.js par exemple histoire de pouvoir traiter des millions de requêtes par secondes
pour lui mysql et apache ne serait' il pas le bazooka qui tue la mouche ?
et la le mec il le pécho par le bras et il lui dit '

32

wow, un client redis en pur bash :' )

https://github.com/caquino/redis-bash
et la le mec il le pécho par le bras et il lui dit '

33

vince (./29) :
Google ou Facebook ont des contraintes très particulières que peu de structures rencontrent.
Et alors?
vince (./29) :
Vouloir à tout prix comparer NoSQL et les SGBD/SGBDR n'aboutira pas
Ca dépend; si on parle de prix, si.
J'ai eu un exemple concret dans ce genre à la banque où je travaillais avant: on allait partir sur une solution de supervision (réseaux) microsoft à tel tarif, et coup de théâtre, la direction a changé d'avis et on est partis sur de l'open-source!
r043v (./30) :
redis est single threaded
Ca par contre, ça sent moyen les perfs... nan?
r043v (./31) :
qui peu le plus peu le moins ?
Tout à fait d'accord.
vince> Si un produit est moins cher et plus puissant, je vois pas pourquoi il rentre pas en lice.
r043v (./31) :
mon pseudo irl de toujours à été mon nom mis à la russe (en 4eme on apprenais staline tout ca smile2.gif ) soit, noferov, contracté en rov (prononcé roff), ensuite sur irc vu que je développais souvent ca faisais rov|dev => r0|dev => r043v mod.gif
Mais, euh... lol grin
r043v (./31) :
r zero 43 v
ça donne "air zéro quarante-trois vé"? Vaut mieux le lire sans le lire que le prononcer tongue
avatar
Attention, nouvelle signature #eeek#
https://mastodon.ti-fr.com/@redangel

34

r043v (./30) :
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 ..

avec un cron ? tongue (je taquinne)
redangel (./33) :
vince> Si un produit est moins cher et plus puissant, je vois pas pourquoi il rentre pas en lice.

je suis tout à fait de cet avis, sauf dans le cas du stallmannite (le libre pour le libre, "pas besoin de PSP, j'ai vim" cheeky)... et surtout, le produit DOIT répondre à l'ensemble des besoins et sa mise en concurrence ne doit pas se limiter au coût d'achat (si une solution est moins chère au départ mais qu'elle demande en permanence deux fois plus de ressources "mail" private joke pour redangel alors ça doit être pris en compte...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

35

redangel (./33) :
r043v (./30) :
redis est single threaded
Ca par contre, ça sent moyen les perfs... nan?


en fait redis tourne vraiment très très vite, et tu peu très bien lancer une instance par coeur, en les mettant en maître/esclave ou vraiment en séparant les instances par données à sauver
(ou peut être peuvent t'ils partager la même ram et dump mais j'en sais rien, j'utilise qu'une instance unique)

aussi rien ne t’empêche d'utiliser plusieurs serveurs physiques et dispatcher tes requêtes entre eux

http://redis.io/topics/benchmarks

la version 2.6 va bientôt sortir, une fois releasé le dev de redis va tester un peu ce que donnerais une version multithread de redis
Hi Dvir,
I want to use threads in Redis to improve the performances for the
single instance case, but at the same time I want to have a design
that will not make it slower when using a single core.
The idea is to start with the networking layer that is where a lot of
time is lost, we could have N threads reading and parsing requests
from clients, and then serving the result back to clients. A further
step can be to also call commands in the context of different threads
with key-based locking.
After Redis 2.6 RC1 release I'll start experimenting with a few
branches to see what is the best balance to internal simplicity and
ability to use more threads, but I think it is a change we can't
avoid, the future appears to really belong to computers with many many
cores, and Redis should try to take advantage of this in the best way.
If there are 4 cores in a computer it is fine to run four instances,
but maybe in two or three years we'll start to commonly see computers
with 16, 64, 128 cores... and it starts to be not practical smile

http://groups.google.com/group/redis-db/browse_thread/thread/378a32de50a782c5
redangel (./33) :
ça donne "air zéro quarante-trois vé"? Vaut mieux le lire sans le lire que le prononcer tongue.gif

grin
et la le mec il le pécho par le bras et il lui dit '

36

vince (./34) :
avec un cron ? tongue.gif (je taquinne)

et oui, je suis allé voir comment ca marchais juste pour ca tongue
et la le mec il le pécho par le bras et il lui dit '

37

question "technique" (j'essaye de bien comprendre le procédé) : tu dis que pour se protéger des crashes, y'a un fichier qui contient les opérations depuis le dernier dump. ce fichier est "physique" j'imagine (enfin, j'ai cru comprendre qu'il est dans tmp), si le système crash, il faut donc être assuré qu'il n'est pas corrompu, c'est fait ? si oui, comment ? et dans tous les cas de figure, la vitesse ne risque-t-elle pas d'être bridée par les temps d'écriture de ce fichier tmp ?
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

38

r043v (./26) :
les commandes en cours seront dedans bien sur :- )
Comment est gérée la consistance exactement ?
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.
Une botîe se contrefout royalement de parler au mec dans son garage. Elle veut un support, des garanties, un temps de résolution en X heures, la possibilité d'ouvrir un incident, éventuellement en 24/7.
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
La encore quand tu bidouilles un truc c'est nickel. Dans un usage professionnel il te faut des admins formés. Quand le téléphone sonne à 4h du matin parce que l'appli est en carafe, avoir un admin qui connait ça fait une putain de différence.
Comment ça se comporte quand une donnée est corrompue ? Quelles sont les opérations à faire pour remonter la base après une coupure de courant ? Comment ça se passe si le filesystem passe en read-only spontanément ?
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
Le bricolage maison en environnement professionnel c'est un truc que tu évites à tout prix. Comment tu intègres ta base dans une solution de sauvegarde du marché ? Comment elle interagit si tu fais de la sauvegarde en mode bloc ? Est-ce qu'on peut faire la sauvegarde sans arrêter la base (sous entendu avec garantie à 100% de ne rien perdre ni corrompre) ? Et avec une méthode de sauvegarde qui s'appuie sur les mécanismes baie ?
> 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
Je parle des interfaces dans leur ensemble. Ca comprend les interfaces utilisateur comme tu as indiqué, mais également :
- les interfaces applicatives (protocole)
- les interfaces d'opération (alertes remontées, intégration à l'outillage d'administration d'entreprise, système de packaging)
> 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
Eh oui, mais en environnement professionnel tu essaies de limiter le nombre de solutions que tu déploies car chacune doit être gérée (montées de versions, patching, packaging), les admins doivent être formés, les développeurs aussi. Et accessoirement vu que les applications ont tendance à causer entre elles, la complexité globale croît de manière exponentielle avec le nombre de briques utilisées.
Du coup, déployer un système qui n'est pas pris en charge par les middleware ou applications existantes ça a un impact significatif.


C'est là que sont les vrais enjeux du monde professionnel. L'industrialisation.
Les performances, à part quelques rares cas extrêmes (comme google justement), on s'en bat carrément les couilles. Payer deux machines ça sera toujours moins cher que payer 2 équipes d'admins.

39

en fait, le dump se fait sur un fichier temporaire oui, si il s'est bien passé il remplace le dernier dump, si un crash à lieu pendant la save ta toujours l'anciens dump précédent
ca c'est la save en fichier rdb

il existe un second type de persistance, les fichier aof, qui eux stocke chaque commandes passés pour les refaire une par une en cas de soucis

les deux ensembles peuvent être employés

forcément écrire chaque commande dans un fichier (enfin c'est plus intelligent qu'une écriture brute en fait) doit faire baisser les perf (-je pense- visiblement un fork à lieu pour faire cette écriture faudrait voir en détail)

mais j’imagine que c'est tout de même mieux que mysql qui lui stocke tout en permanence en dur sur le disque ? comment fonctionne t'il en fait ? ça doit être similaire je pense

le tout est bien détaillé ici : http://redis.io/topics/persistence
et la le mec il le pécho par le bras et il lui dit '

40

visiblement on à pas bossé dans les même boites cheeky

une boite comme tu la décrit, elle va devenir client d'un truc d'hosting dédié à ca, genre http://redis4you.com/

vmware paye le type qui à fait redis pour justement le faire évoluer, il à pas mis en place une "équipe complète" avec toute une infrastructure en fond.

mis à part le créateur lui même, c'est fait par des gens sur leur temps libre, et les outils externes aussi

microsoft à fait un patch pour compiler redis sur windows mais la participation de grand groupes se limite actuellement à des actions du style

je pense qu'il y à un créneau à prendre sur le support auprès de grande boite, fonce !

prenons l'exemple de mon utilitaire, il marche très bien même avec une "grosse" (tout est relatif) base de 50000 clefs, mais ca reste une alpha comme je le dis moi même dans le readme "ne pas compter dessus pour des choses sensibles" (cf la maladie de l'open source :- )
par contre je l'ai mis sur githut, pour le partager déjà, mais aussi pour que d'autre que moi le fasse évoluer, ensuite c'est pas du fait que se soit open source que ca implique aussi des bugs et que se soit de la merde en barre etc ... tu tourne sous quel navigateur et os ?

bref je l'ai conçu en vu d'être générique et adapté à tous les cas, je ne me suis pas limité à mon seul usage (j'ai besoin moi même de 10% de ce que l'outil réalise) il n'est justement pas un bricolage maison comme mon sh

de même pour les clients redis, seul celui en C à été réalisé par antirez, tous les autres sont tiers
la base à très bien été accueillie par la communauté et pas mal de monde y participe (plus de 500 forks pour redis sur github)

c'est un souffle nouveau dans le stockage en ligne, certes c'est jeune mais mysql ne va plus avoir le monopole
Les performances, à part quelques rares cas extrêmes (comme google justement), on s'en bat carrément les couilles. Payer deux machines ça sera toujours moins cher que payer 2 équipes d'admins.


certes, mais ca dépend aussi des clients, personnellement je propose à mes clients du 100% custom autant niveau graphique que fonctionnel, bref je fait pas du wordpress, c'est peut être pas le même prix mais ce n'est pas non plus la même prestation :- )
et la le mec il le pécho par le bras et il lui dit '

41

[cite] r043v (./30) :
$$$ ? même si j'utilise mysql je ne dépenserais jamais un seul € dans du support.
[cite]
ça, c'est parce que tu ne travailles pas en entreprise. Comme dit Spectras : "Une botîe se contrefout royalement de parler au mec dans son garage. Elle veut un support, des garanties, un temps de résolution en X heures, la possibilité d'ouvrir un incident, éventuellement en 24/7. "
et c'est vrai pour toutes les grosses boites.
Parce que ta base de données, qu'elle soit sql ou nosql, à l'arrivée, c'est elle qui contient les données vitales à ton application, donc ton fond de commerce. Elle tombe, t'es dans la rue. Il te faut un minimum de garanties, avec une société (ou ça se fait en interne avec des devs internes) qui fera du support, sera par exemple capable de s'engager à venir sur place, prendre ton fichier backup corrompu, et en sortir des données exploitables.

[cite] r043v (./30) :
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"
[cite]
Voilà, donc pas viable en entreprise.
r043v (./30) :
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

r043v (./30) :
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.

donc le backup ne contient que les données à un instant T-xheures. Mouaif. Le delta, tu peux le récupérer ?
r043v (./30) :
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 ^^

ha mais partout, sauf que tout ça, ça part pas en production, ça reste de la veille techno, le jour où ça sera exploitable on sera prêt, mais en l'état, tout ne doit pas être exploité en production smile
r043v (./30) :
rester à sql c'est sur que c'est secure, ancienneté, robustesse etc mais ou est le plaisir dans votre quotidiens ensuite ?

le boulot c'est pas que se faire plaisir c'est faire un truc qui marche, et correctement, et qui est industrialisable, exploitable, réparable, etc.
spectras (./38) :
C'est là que sont les vrais enjeux du monde professionnel. L'industrialisation. Les performances, à part quelques rares cas extrêmes (comme google justement), on s'en bat carrément les couilles. Payer deux machines ça sera toujours moins cher que payer 2 équipes d'admins.

pencil


pour la définition de middleware, je te renvoie à la bonne page de wikipedia : http://fr.wikipedia.org/wiki/Middleware.
Et il se trouve que le middleware est parfois un moyen pour accéder aux données applicatives (issues des bases sql/nosql, justement).
avatar
Il n'a pas de mots
Décrire son mépris
Perdre les rênes
Il a perdu la foi

42

r043v (./40) :
visiblement on à pas bossé dans les même boites mod.gif
Je pense en effet cheeky

Je te dis ça sans méchanceté aucune, hein, mais tu sembles pas réaliser qu'il y a beaucoup de secteurs qui demandent un peu plus de garanties que ce que le développement-bricolage façon Web peut fournir grin

Simple exemple : si tu débarques en entreprise et que tu dis que t'as jamais entendu parler de relationnel, que le support tu t'en fous vu que tu comptes envoyer un mail directement aux dévs en cas de problème, et que tu veux déployer une BDD "toute neuve" avec un seul utilisateur et un seul thread sans aucune garantie de temps de réponse ni de fiabilité, ils vont légèrement te rire au nez hehe

NoSQL a probablement des avantages, mais avant de prétendre que ça va remplacer les BDDs classiques je pense que tu devrais te document un poil plus tongue
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

43

Bah oui, mes (ex-)clients leur IT n'est pas là pour jouer, c'est un outil de production, comme une chaîne de montage. On parle de boîtes comme des banques, de la grande distribution, des assurances.
D'ailleurs ils ne vont pas devenir client de hosting parce que aucune boîte de hosting correcte n'en a les épaules (bon c'est pas tout à fait vrai, des fois ils jouent un peu pour l'un de leurs datacenters à mettre des trucs chez IBM ou Linkbynet, mais ça reste quand même anecdotique).
De toutes façons :
Disclaimer of Warranties.The Website and hosting service is provided as is. E-NICK Ltd. and its suppliers and licensors hereby disclaim all warranties of any kind, express or implied, including, without limitation, the warranties of merchantability, fitness for a particular purpose and non-infringement. Neither E-NICK Ltd. nor its suppliers and licensors, makes any warranty that the Website will be error free or that access thereto will be continuous or uninterrupted.
Terminé.
r043v (./40) :
je pense qu'il y à un créneau à prendre sur le support auprès de grande boite, fonce !
Un jour peut-être, mais pour l'instant c'est trop tôt. C'est inutilisable dans un contexte de production, donc par les sociétés susceptibles d'acheter du support.
Pour avoir une petite idée, regarde le travail qu'il a fallu faire en terme d'image, d'industrialisation et de lobbying avant que RedHat et SUSE ne deviennent crédibles en centre de données. Les autres distributions ne le sont toujours pas. Même Oracle n'arrive pas à refourguer son Unbreakable Linux.
r043v (./40) :
bref je l'ai conçu en vu d'être générique et adapté à tous les cas, je ne me suis pas limité à mon seul usage (j'ai besoin moi même de 10% de ce que l'outil réalise) il n'est justement pas un bricolage maison comme mon sh
C'est une bonne idée, et ça va servir à plein de monde si tu le publies. happy
Mais quand on parle d'outils de production d'entreprise, tout ce qui ne peut pas afficher 5 ans d'existence sur le marché et des épaules économiquement solides rentre dans la définition de bricolage maison.
A noter que Wordpress rentre dans la catégorie bricolage maison aussi. Tu verras jamais une boîte sérieuse utiliser Wordpress pour quelque chose qui touche de près ou de loin à son business.

Sinon pour ta question, quelques exemples de services middleware : JBoss, WebSphere, BEA, webMethods, SAP, SAS, $Universe, Tomcat, Oracle.
Techniquement, les implémentations nosql sont dans cette catégorie.
r043v (./40) :
tu tourne sous quel navigateur et os ?
Tu travailles avec quel outil ? Ca depend de ce que je fais.

44

Après il ne faut pas exagérer non plus, les banques/assurances/etc. font partie des secteurs les plus conservateurs, toutes les boîtes n'ont pas besoin d'exigences aussi élevées.

Le disclaimer que tu cites il existe aussi pour les produits MS par exemple, c'est pas pour autant qu'aucune entreprise n'utilise Windows, Office, IIS, etc.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

45

spectras (./43) :
Tu verras jamais une boîte sérieuse utiliser Wordpress pour quelque chose qui touche de près ou de loin à son business.


C'est faux, et c'est un très mauvais exemple.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

46

Zerosquare (./44) :
Après il ne faut pas exagérer non plus, les banques/assurances/etc. font partie des secteurs les plus conservateurs, toutes les boîtes n'ont pas besoin d'exigences aussi élevées.

Le disclaimer que tu cites il existe aussi pour les produits MS par exemple, c'est pas pour autant qu'aucune entreprise n'utilise Windows, Office, IIS, etc.

J'aurais également tendance à dire qu'il n'y a pas que les entreprises du CAC40 qui sont des professionnels... Même si ça n'empêche pas de mettre en place des solutions fiables pour les autres, sans bricoler grin
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

47

et bien adieu les banques alors, what else ?
de toute façon la base tourne pas sous dos et win95 cheeky
c'est sur qu'attendre 5 ans pour utiliser un truc c'est cool ... pour les écran bleu des distributeurs

redis à beau être jeune il est ultra stable, ca doit faire une année que je m'en sert, je n'ai eu aucun crash ...
le temps de réponse et le nombre de requêtes/s est hyper bon, mais non, il n'y à pas eu de document de 300 pages fait par un organisme extérieur indépendant pour le certifier cheeky

bref, mis à part ca il n'y à pas que les grosses boites dans la vie, surtout vers chez moi ... c'est plutôt des petites pme qui font leurs projets custom, et pour des petites boites, innover et se différencier est important, seul les gros bien installés ont peur et sont frileux du changement

utiliser une base nosql n'est pas du bricolage, je ne comprend pas votre délire avec ca :/
kim (./41) :
donc le backup ne contient que les données à un instant T-xheures. Mouaif. Le delta, tu peux le récupérer ?

il suffit de lire les messages posté plus haut, oui, redis est sécure
la meilleure balance en terme perf/sécure te garantie un maximum d'une simple seconde de perte de donnée
le temps entre deux vrai dump est paramétrable (comme dis plus haut) avec un nombre de clefs écrit en n secondes, par default, une seule clef modifié implique une save 1/4 d'heure plus tard

sinon, des gros site l'utilise déjà hein, si c'étais vraiment si casse gueule ca ne serais pas le cas ...

The Guardian
GitHub
Stack Overflow
Craigslist
YouPorn
...
et la le mec il le pécho par le bras et il lui dit '

48

r043v (./47) :
redis à beau être jeune il est ultra stable, ca doit faire une année que je m'en sert, je n'ai eu aucun crash ...

C'est parce que je l'ai pas encore utilisé. Fais-moi confiance embarrassed

49

Redis ça trace bien quand même.

Nous on s'en sert pour mettre en cache le site. Si pas de cache, on va chercher dans mysql, qui va ensuite créer le cache dans redis. comme ça après, quand on veut l'info, ça dépote bien. Faut juste faire bien attention à vider le cache des appels lorsqu'on modifie les données ^^

50

Disons que ça dépend de la perspective en fait. En terme de pénétration de marché, les grosses entreprises sont LA cible. Déjà parce qu'elles concentrent une part très importante des systèmes, ensuite parce que justement leurs besoins font qu'elles sont prêtes à investir dans un support de qualité et des solutions robustes, industrielles. Ce qui produit un effet de levier très important en retour sur l'industrialisation des solutions.
C'est pour ça que je te dis que noSQL c'est trop tôt pour avoir une percée significative dans le marché professionnel. Je ne dis pas que ça ne se fera pas, mais que le fait que ça se fasse ou non ne dépend que de manière anecdotique des questions techniques.

Et pour revenir à la question initiale : on choisit un outil en fonction de ses besoins. Et je voulais juste te montrer que oui, il y a bien des besoins qui ne sont pas couverts pas noSQL et pour lesquels les implémentations nosql ne pourront structurellement pas répondre avant des années.

L'important au final c'est de connaître les forces et les faiblesses des outils disponibles. Pousser systématiquement du nosql c'est tout aussi stupide que pousser systématiquement du Oracle ou du mysql. Parce que ce sont trois outils différents.

Si je reviens sur ta question sur les OS, qui illustre très bien :
=> quand je travaille, j'utilise le même OS que mon client
=> sur mon laptop de voyage j'ai une kubuntu
=> si je jouais, j'aurais un windows, mais j'ai arrêté de jouer il y a quelques années.
=> sur mon serveur (dédié chez ovh) j'avais un OpenBSD avant, mais j'ai fini par changer pour une Debian quand j'ai eu le besoin régulier d'ajouter de nouveaux packages pour mes sites.
Accessoirement j'ai aussi bossé avec du HPUX, du AIX, du Solaris, de la RedHat, du NetBSD. Ce ne sont pas des religions, ce sont des outils.

51

spectras (./50) :
je voulais juste te montrer que oui, il y a bien des besoins qui ne sont pas couverts pas noSQL
Euh, j'ai lu tout le topic et je trouve que non, tu n'as pas montré de besoins non couverts par noSQL, à part
tout ce qui ne peut pas afficher 5 ans d'existence sur le marché et des épaules économiquement solides
ce qui est un argument économique; donc peut-être réel (capitaliste), mais mauvais (ici on est entre techniciens il me semble, pas entre commerciaux).
avatar
Attention, nouvelle signature #eeek#
https://mastodon.ti-fr.com/@redangel

52

histoire d'en citer au moins un : il n'existe aucune solution complète de middleware compatible avec nosql, il faut donc se le développer à la main...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

53

Ok, valide.
avatar
Attention, nouvelle signature #eeek#
https://mastodon.ti-fr.com/@redangel

54

y'a aussi eu le coup du "monothread" qui peut s'avérer être un obstacle à l'accès concurrent, ou encore les contraintes de "non déportation" (nosql doit tourner sur la même machine que le programme pour conserver les performances annoncées)...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

55

faux et faux

les bench indiquant 100.000 op/s sur une linux box classique sont effectués depuis 50 clients parallèles par default
après forcement les opérations étant atomiques il faut attendre la fin d'une opération d'écriture pour derrière lire cette info..

youporn utilise un cluster énorme de noeud redis, et il encaisse 300000 op/s

par contre comment tu fait un cluster sql de manière simple ? et la réplication des données ?

le vrai argument contre nosql c'est plutôt la recherche des données, l'exemple de l'auto-complétion le montre bien,
moi j'ai choisi redis, les recherches sont impossibles (à part avec la commande key mais elle est fortement déconseillé en production)
donc on doit réfléchir et structurer ses données en conséquence.

par contre il existe d'autre base nosql te permettant de faire tes recherches, genre mongodb

http://www.mongodb.org/display/DOCS/Querying
// retrieve ssn field for documents where last_name == 'Smith':
db.users.find({last_name: 'Smith'}, {'ssn': 1});

// retrieve all fields *except* the thumbnail field, for all documents: db.users.find({}, {thumbnail:0});
et la le mec il le pécho par le bras et il lui dit '

56

r043v (./55) :
il faut attendre la fin d'une opération d'écriture pour derrière lire cette info

donc ça peut être un obstacle (j'ai pas dit que c'était impossible non plus...)



et concernant ce que j'appelle la "non déportation", j'ai cru comprendre que le mode de fonctionnement même de nosql ne permettait pas d'envisager simplement un accès de type hote+authentification+commande...

(et la déportation n'implique pas une approche "cluster", c'est un sujet différent.)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

57

redangel (./51) :
ce qui est un argument économique; donc peut-être réel (capitaliste), mais mauvais (ici on est entre techniciens il me semble, pas entre commerciaux).
Quand on parle d'informatique professionnelle, je ne suis pas un technicien, mais un industriel.

Il ne s'agit pas d'arguments commerciaux, mais de simple bon sens. Tu n'appuies pas ton outil de production sur une technologie dont la société peut te claquer entre les doigts. Parce que le jour où il faut migrer en catastrophe toutes tes applications métier vers autre chose au pire tu mets la clef sous la porte, au mieux tu vas pointer au chomage pendant que la boite essuie ses pertes.

Si tu fais construire ta baraque un jour, tu verras si tu prends pas en compte la santé financière du constructeur ^^
Et puis tu verras que finalement, même si la startup du coin vient juste d'inventer un super matériau révolutionnaire, le bon vieux parpaing c'est quand même pas si mal.

58

spectras (./58) :
Quand on parle d'informatique professionnelle, je ne suis pas un technicien, mais un industriel.
Autant ça je suis d'accord..
spectras (./58) :
Si tu fais construire ta baraque un jour, tu verras si tu prends pas en compte la santé financière du constructeur ^^ Et puis tu verras que finalement, même si la startup du coin vient juste d'inventer un super matériau révolutionnaire, le bon vieux parpaing c'est quand même pas si mal.
..autant ça non. Je préfère la pierre au parpaing.
avatar
Attention, nouvelle signature #eeek#
https://mastodon.ti-fr.com/@redangel

59

Certes cheeky

60

tu n'est pas obligé non plus de faire construire la maison par ceux qui te fournissent le super matériaux révolutionnaire :- )
et concernant ce que j'appelle la "non déportation", j'ai cru comprendre que le mode de fonctionnement même de nosql ne permettait pas d'envisager simplement un accès de type hote+authentification+commande...
bien sur que si, redis passe soit par un socket unix, soit par le réseau, le socket est plus rapide.
ce qui limite la vitesse de redis c'est justement la couche réseau, youporn à rajouté des noeuds car les cartes réseau ne supportaient pas la charge.

je crois aussi qu'il y à un "clone" de redis dont le but est de n’être utilisable que localement, donc sans couche réseau.
Tu n'appuies pas ton outil de production sur une technologie dont la société peut te claquer entre les doigts.


redis étant un projet open source, il y aura toujours des personnes pour le reprendre, surtout vu l'engouement actuel
le dev principal meurt atrocement demain, bah c'est triste mais je ne m'en fait pas pour le projet lui même,

et quant bien même personne ne le reprendrais, cela signifie t'il que tu doivent stopper toute utilisation dans l'urgence absolue ?
je ne pense pas, au pire si t'est vraiment flippé ce jour la tu binde seulement l'écoute sur localhost et tu bosse "localement" le temps de passer tes techno sur autre chose ...
et si t'est un peu grand et à du blé, tu pose qq mec sur le dev de la solution ...

c'est "un peu" comme si linus mourais subitement demain, tu va fermer ta boite car toute tes apps tournent sous linux ? ce n'est pas la même envergure mais le principe est le même.

et c'est justement bien différent d'une boite qui à un soft closed source qui est obligatoire à ton développement à toi, si eux ferme tu est dans la merde !
et la le mec il le pécho par le bras et il lui dit '