Reprise du message précédent :

 
Pas essayé, quel est le besoin ?
 
Pour le fun, je te conseillerais https://foundationdb.com/ (gratuit pour 6 processus)

Besoin : un petit portail client (suivre les abonnements, renouveler, upgrader la version de XOA, etc).

On part d'une feuille blanche justement (boulot de notre nouveau dev et premier salarié qui est arrivé ce matin \o/ )

Mon associé est tenté par Level car bien intégré dans Node (streams, serialisation JSON) et dans de plus en plus de modules NPM.

 
Je suis sceptique.
 
Pourquoi pas du Redis ?
 
https://foundationdb.com/layers/sql [...] rline.html

On utilise déjà Redis pour Xen Orchestra, et on est pas vraiment satisfait (le pourquoi du comment c'est avec mon associé qu'il faut voir )

Pour de la gestion de clients, je partirai sur un truc bien testé avec tout ce qui va bien pour de la sauvegarde / restauration

Oui, je sais, je ne suis pas fun

On stocke tout en JSON, pour le backup ya juste à désérialiser dans un fichier dump qui est backupé tous les soirs et snapshoté ensuite à 500km de là avec un ZFS qui permet de revenir J-1 jusqu'à J-7 puis M-1 jusqu'à M-12

edit : pardon, j'ai oublié les snapshots weekly aussi (4 dernières semaines )

Plutôt bizarre, mais bon, pourquoi pas, si vous êtes sûrs que vous n'aurez jamais besoin de requêtes supplémentaires (ce que j'ai du mal à imaginer, vu le type d'application).

Qu'est-ce que tu veux dire par « requêtes supplémentaires » ?

edit : ce qui te choque c'est le NoSQL ou spécifiquement cette DB là ?

Au fait les devops, vous avez de beaux exemples de dashboards pour monitorer un serveur/un ensemble de serveurs ?

Monitorer quoi comme info ?

chez geocorp, on avait juste un écran dashboard de new relic.  
ça faisait pas mal le job, rien qu'avec le trafic en temps réel, CPU et mémoire t'arrive à voir les grosses cata très vite.

Alertes : cpu/ram/espace disque
Etat de certains process  : nginx,postgres, nodejs (via pm2)  
Delai de réponse des differentes api externes utilisées  
quelques compteurs applicatifs (nombre de connecté, temps de réponse )
 
Je voudrai essayer de faire un truc un peu joli sur quelques serveurs que je connais bien, vu que cette année on doit monter quelques ecrans au mur à et ce que j'ai vu ( du nagios quasi brut) est vraiment uber moche

C'était pas payant dans le passé new relic ?

Le NoSQL. Avec une base clé-valeur, tu ne peux accéder à tes données rapidement que via la clé, c'est extrêmement limitant.

C'est payant seulement si tu veux de la rétention de données et les outils de tracing détaillés (qui sont très très cool ceci dit, c'est un peu cher mais on était bien content de pouvoir descendre immédiatement d'une requête utilisateur un peu lente au service ou à la transaction sql responsable sans trifouiller des logs).

Nagios (ou autre fork) en back-end c'est vraiment bien pour faire de la supervision (celle qui te reveille par SMS le week-end par exemple), de manière simple et poussée en même temps.

Mais c'est moche, et pas adapté pour du dashboard.

M'est d'avis, si tu veux de belles métriques, soit :
* tu passes par un truc en SAAS qui fait le café mais qui est cher et qui exporte tes datas à l'extérieur (c'est pas un jugement ! ça peut correspondre à tes usages !)
* tu utilises un backend ES avec du Kibana en front. Tu stockes ce que tu veux dedans (directement tes métriques applicatives et tes métriques systèmes via un Logstash ou collectd/graphite etc.) -> après tu affiches tes dashboards comme tu veux sur cette base. Double avantage : exploitation poussée pour toi si besoin est, bref, utilisation versatile.

Hmmm... Clef-valeur oui, mais ce n'est pas limitant au contraire je trouve (surtout si tu stockes tes objets JS directement dedans, au contraire je trouve ça souple). Avec en plus la faculté d'utiliser les streams pour lire (Level spécifiquement) c'est vachement bien. M'enfin on va regarder, c'est un premier jet

Ils ont un plan gratuit depuis presque le tout début. Au lancement (Rails-only) ils avaient un developer mode pas utilisable en production, mais 2 semaines plus tard ils l'ont remplacé par un plan lite.

'tain je suis dans une *vraie* cuisine américaine (genre années 90 méga-gadgets), je capte rien au micro-onde/hotte aspirante

Comment tu fais une requête avec condition sur les valeurs ?

Ouais on avait eu le même pb
genre tu veux faire chauffer un bol, au final bah on lançait le programme tasse 2 fois, rien capté au biniou
on avait eu la totale avec la lunette de chiotte japonaise qui chauffe (et son petit jet d'eau), la baignoire qui utilise les buses pour les bulles pour finir de sécher après usage etc
Ah et la clim en °F, on avait pas potassé avant de venir, du coup comme le µonde c'était réglage au pif

j'crois que j'ai trouvé: il faut appuyer sur "time cook", rentrer le temps (come sur une caisse enregistreuse), puis "power level" puis la puissance, puis "start".
 
parce que "defrost" ça te demande le poids du machin en LB.

j'avais un micro onde bluesky comme ça quand j'étais étudiant, souvenir...
aujourd'hui j'ai même plus de micro-onde /réac/

pareil, et j'ai l'impression que les micro-ondes sont en régression en fait.

Par exemple, tu veux pouvoir connaître les abonnements d'un client, et pour des raisons de statistiques sur ton CA ou de marketing, la liste des clients à un abonnement.
Ca fait déjà deux types de requêtes différents.

Avec un truc comme LevelDB, tu vas donc avoir:
- un document JSON pour chaque client, qui contient ses identifiants, la liste de ses abonnements, les dates de début/fin, les options, etc,
- un autre doc potentiellement bcp plus gros, par abonnement, qui va contenir la liste des clefs des clients.

Mais tu veux chaque mois avoir la liste des abonnements qui vont se terminer et/ou qu'il faut prolonger. Avec ce modèle, impossible de répondre à cette requête efficacement alors qu'en SQL, c'est trivial. Avec une base clé-valeur, il faut créer une hashtable par type de question et ton modèle de données est codé en dur dans l'application elle-même, ce qui n'est pas très bon.

Alors qu'on voit déjà qu'on a établi des relations entre les données, et une base de donnée relationnelle me paraît être l'outil adapté. Pour moi, une base clé-valeur sert uniquement d'optimisation pour certaines opérations, mais pas de base de données pérenne. Je pense que c'est une erreur de partir la-dessus pour stocker tes données. Ca peut paraitre facile au départ, mais vous allez y perdre sur le moyen/long terme.

Oui c'est ça. C'est inutilement compliqué et jamais personne ne se sert des 500 options.

de toute façon je voulait basculer mon solr vers elsatic search

ca fait chier que kibana 4 ne soit toujours pas internationalissable

edit :
psql : http://ian.delahorne.com/blog/2014 [...] s-pipeline
colectd : http://www.logstash.net/docs/1.3.3/inputs/collectd
pm2 : https://blog.devita.co/2014/09/04/m [...] ticsearch/
nginx https://www.digitalocean.com/commun [...] ed-logging

putain à chaque fois que je cuisine, je me rappelle que je déteste ça en fait
 
la pate brisée se comporte pas du tout comme en France (elle est vachement cassante), j'ai pas envie de savoir pourquoi et de geeker pendant des heures sur des forum féminins pour des questions de cuisine
 
bref, ça sera empanadas foirées ce soir

C'est vieux, mais quand même:
 
Sur 6 millions de passwords

 

https://xato.net/passwords/more-top [...] KxPySuG9DL

 
si moi

   il y a un topic cuisine sur ce forum  

 
T'es un des seuls que j'entends dire du mal de Redis

Je suis passé dans une boite où ils n'arrivaient pas à faire le liens entre ces consos théoriques et ce que consommait réellement l'immeuble (de 30 000m²), ils avaient réalisés des mesures et outre les antivirus et les super GPO qui foutaient en l'air les passages en veille ils avaient eu des surprises la conso réelle des équipements vs energystar.

prems

je pense que connaissant un peu l'associé de plam, le problème n'est pas sur les perfs, mais sur la beauté du code d'interface

 
De mémoire, par rapport à nos besoins :

• trop bas niveau
• pas de serialisation automatique des objets
• une dépendance supplémentaire à installer (contrairement à Level qui tourne dans Node et utilisable via un simple module npm)

 
Ta tous les outils

 
En fait c'est tout à fait vrai pour une BDD d'une certaine taille. À notre échelle (on parle de nos clients hein !), le noSQL nous sert « juste » à stocker nos objets. Il n'y a pas de logique de requête à l'intérieur.
 
Donc la logique est dans le JS qui filtrera sur les objets en mémoire. Donc on travaille pas sur des indices (moins performant) mais directement en RAM (vu la petite taille de la base), et sans avoir à penser à un schéma relationnel à la conception.
 
En gros, ça nous permet :

• d'aller vite (évolution des objets au fur et à mesure de nos besoins !)
• de pouvoir répliquer très simplement la base
• d'avoir juste un module NPM à installer et 0 paquet système ou autre trucs à maintenir et monitorer que le process Node

Maintenant on verra bien avec le recul si c'est une bonne idée, mais de toutes façons on a que 2 itérations avant d'avoir un résultat utilisable (fin janvier ) donc je vous dirai de quoi il retourne ici

Cette conférence de Matthew Innman (The Oatmeal) est bien marrante. La nana qui traduit en langue des signes.
 
http://theoatmeal.com/blog/jibbers_crabst

Je rajoute que je pense aussi remplacer le logger que j’utilisais pour express( morgan ) par winston : il s'interface directement avec logstash

 
Vous pourriez aussi utiliser SQLite, qui répond à vos besoins: un exécutable de 400ko et un fichier SQLite/base. Ce que vous perdez en facilié de sérialisation en JSON, vous le regagnez à coté. Mais bon, sinon à coté de LevelDB, il y a aussi RocksDB (une optimisation de Level) et MLDB.

 
- Redis trop bas niveau ? C'est à ma connaissance plus haut niveau que leveldb.
- Vous voulez un ORM en fait ? (ça s'installe mais bon)
- Trop dure la vie