Reprise du message précédent :

 
Pour des trucs basiques, j'ai dit...

Dernier jour au boulot

et après ?

Je reprends début Janvier

 
Merci

Je ne transfère plus, la plupart des softs que j'utilsie je les utilise dans leur conf à eux, et installer un mac me prends 1h chrono, après j'installe les softs avec homebrew ou à la main quand je peux pas (cas rare).
Le seul soft pour lequel je garde la conf c'est Google chrome via mon compte google (rien à foutre si google sait tout, mais au moins j'ai mes extensions et leurs paramètres), et VS Code

Qui est obligé de foutre une glibc tierce sur son image docker Alpine parce que mongodb tourne pas sinon ? C'est bibi.

Quel est l'intérêt de conserver ton image de base Alpine dans ce cas?

 
Vscode a un plugin pour save toute ta conf si jamais.

 
Dans l'absolu, j'ai déjà la liste des 29 programmes que j'utilise, dont 28 sont installable très rapidement via Homebrew.
 
Pour les config, celles de iTerm2 et Alfred sont stockées sur le cloud. Celle de Chrome est stockée via compte Google.
 
J'ai mis environ 1h30 a tout réinstaller sur le nouveau Mac, je n'avais pas envie de tenter le transfert depuis l'ancien car je voulais un truc tout propre.
 
Par contre l'install & lancement de ma stack Docker prend presque 2h la première fois.
 
Et comme Apple vient de sortir le 16", que je l'ai un peu en travers, et que je suis encore dans le délai pour me rétracter... Je vais prendre le 16" et renvoyer le 15"... Mais comme je viens de me faire chier à tout réinstaller... je suis pas très chaud pour recommencer

Des news de mon amende espagnole :
 
Alors c'est bon, c'est reçu un recommendé, avec des codes pour aller sur un site des années 90 (limite y'avait un gif "en construction" ), qui permet de payer par CB (ou sinon un bon vieil IBAN des familles).
 
Bilan : 50€ si je renonce au recours et tout est fini, ou 100€ si j'avais envie de contester. Je vais pas contester (en plus y'a la photo fournie avec, c'était bien ma voiture )
 
 

 
J'ai tenté avec une Ubuntu, même s'ils ont réduit la taille du bordel je m'en tire avec 1.33Go pour tout ce dont j'ai besoin.
Je suis en dessous de 500Mo avec une Alpine.

Les images Mongo officielles à base d'Ubuntu font <150Mo, je sais pas comment tu te débrouilles mais ça me semble monstrueux.

Où as-tu prévu tes vacances ?

 
Chez moi
Période d'adaptation à la creche pour le second.
Je vais surtout en profiter pour ranger l'appart et avancer qqs projets open source / robotique    

Le second ? Woot, j'étais resté au premier moi, faut vraiment qu'on boive un verre à l'occasion

hum, je crois que tu peux oublier...

Ma porte est ouverte !
Sinon le 'soir' à 16h30 ?

Si ça t’a pris que 1h30 pour tout remettre à plomb ce serait vraiment dommage de rester sur les 15” et butterfly.  
 
Ta stack docker tu peux te demerder pour faire le premier lancement en downtime genre avant de te barrer ou  chez toi.  

 
non mais clairement. Entre le 15 et le 16, c'est quoi l'hésitation ??? Seriously ??

Hello,
 
Ca vous parle une lib pour générer une BDD en RAM clef valeur à partir de données  
statiques en visant une faible empreinte mémoire et de bon temps d'accès?
 
1. Vous en connaissez ?
2. Ca vous parait utile ?

Donc ... une HashMap dans ta bibliothèque standard?  
Ou tu veux un truc comme LevelDB / RocksDB?

 
Ah non mais la demande retour du 15" chez Amazon est déjà enregistrée hein, j'ai pas hésite
 
Je verrai déjà comment se passe le transfert, peut-être que tout Docker fera parti du lot et que ça fonctionnera OOTB.
 
Et quand je parle de "premier lancement", c'est pas juste "une commande et zou, attendre 2h".
 
Ça installe whatmille micro-services, en posant des questions... et une fois les services installés y'a des modifs à faire sur certains fichiers, puis lancer plusieurs commandes... avec le tout qui marche une fois sur 3... bref, cette stack est moisie mais bon, pas le choix.
 
Donc si je pouvais juste faire un copier/coller que ça marche, je serai content

 
J'utilise pas une image mongo. Notre build java utilise un plugin embedded-mongo pour exécuter des tests, mon seul prérequis est de fournir une image docker sur laquelle embedded-mongo peut s'exécuter.
J'avais besoin en gros d'une image qui contient : docker, jdk8, maven, git, bash, curl, ansible, ce sont les outils qui nous permettent de builder l'application et de la déployer.
 
J'ai installé ça avec apt, en gros Java contribue pour 350Mo, Docker pour 386Mo, le reste des outils pour environ 300Mo. Pas génial.
A partir d'une image Ubuntu qui devrait être light d'ailleurs.
 
Même chose en Alpine sauf que je pars d'une image de base docker + git (docker:19-git), j'arrive à 500Mo tout mouillé
 
Pas compris où ça avait merdé.
 
Au passage j'ai découvert https://www.fromlatest.io/ et c'est pas mal.

je vois pas de use case. Genre t'as un gros tas de données, il change jamais et la BDD sert juste à faire des query pas trop lentes dessus ? elle servirait que pour ses indexes ?
 

putain la bande annonce d'Age of Empire 4  

 
Ta question n'est pas claire. Tu cherches un petit truc pour un truc limité ? Ou une vrai in-memory database ? Utiliser du in-memory implique certaines choses. Tu as bcp de solutions différentes: https://en.wikipedia.org/wiki/List_ [...] _databases

C’est ptet l’occasion de fixer ça pour les prochains?
 
Genre au moins un script expect qui répond au questions à la con et orchestre le process, truc du style?

 
Redis ?

Memcache aussi

Du C#, un Dictionary et du LINQ

 
Le use case que j'avais c'est 3 Gigas de données (peu) avec 182 844 272 entrées (Nombre pouvant augmenter) le but étant de savoir si une entrée est stockée dedans le plus rapide possible (accès //isé) et de pouvoir reload la DB très rapidement quand MAJ.
 
Si on arrive à tuner le truc on obtient des gains en RAM assez intéressant (avec un tel nombre d'entrées et des pointeurs 64 bits la taille des données d'indexation peut très rapidement dépasser la taille des données. 2 pointeurs par données => 3 gigas de données d'indexation). Si on fait une table de hash on peut la générer en préprocessing et tuner le nombre d'entrées/la fonction de hash de telle sorte à obtenir le meilleurs ratio nombre d'entrée/nombre de collision. On peut utiliser des "pointeurs" sur 5 bytes pour gagner en ram. On peut stocker les chaines d'une même entrée de manière contiguës et triée pour ne pas avoir de pointeurs pour chaîner les éléments. On peut préprocesser le truc pour reload la DB en RAM par un simple mmap.
 
Le fait d'utiliser des BDD génériques => des baisses de perfs :
 
- Memcache vire des données à la demande et à des coups d'indexation long + le temps de redeployer les données.
- Redis est mono threadé et quid du temps de reload (Je connais peu redis)
 
J'avais vu https://www.gnu.org/software/gperf/manual/gperf.html dans l'idée mais le projet est vieux et ne passe pas avec un grand nombre d'entrées.

Du coup, tes données sont statiques hors reload lors de mise à jour ?
Je seconde la question qui a été posée plus haut : pourquoi utiliser une base de données et pas une structure plus basique ?
Tu vises quelle vitesse pour la recherche dans ce volume de données ? Sous la seconde ? quelques millisecondes ? quelques microsecondes ?
 
Sinon, le hashing, c'est cool, mais peut-être que tu as des moyens de partitionner tes données plus intelligemment en fonction de la distribution des entrées ?
 
 

 
http://cmph.sourceforge.net dit qu’il gère des centaines de millions d’entrées, et selon l’algo tu descends juste au dessus de 2 bits / clé.

T'imagines pas comme j'ai déjà amélioré le truc C'était 10 fois pire avant.

J'ai quelques idées pour améliorer le truc oui, mais manque de temps pour tout mettre en place.

Mais il faudrait notamment que j'injecte l'auth BitBucket dans chaque microservice, parce qu'à chaque composer install dans chacun des services ça demande les tokens.

Et plein de petits trucs comme ça. Sauf que le DevOps j'en ai un peu marre d'en bouffer

BDD c'est un terme générique. En fait il me faut un truc key valeur.
 

 
quelques Nanosecondes.  
 
J'ai déjà codé un truc en recherche dichotomique çà devrait faire le job et la compacité mémoire est maximale (300 ns).
 
Avec du hash on divise le temps par 4 (~= 100 ns).
 
Mais j'ai l'impression que le problème revient régulièrement. Je me demandais juste si il n'y avait que moi qu'il l'avait et si il y avait des solutions déjà toutes faite plutôt que de recoder un truc à chaque fois.
 

 
Intéressant. Merci je vais check

Redis supportera ca sans trop de problème pouvu.
=> par contre pense a monter un cluster master + X slaves... Que tu sois justement pas limité par le mono thread.
 
Mysql a de quoi faire un storage in memory: https://dev.mysql.com/doc/refman/8. [...] ngine.html
 
Postgresql (ou n'importe quel autre SQL) => créer un ramdisk et tout mettre dedans ca devrait le faire (mais c'est même pas vraiment si nécessaire que ca).
En NVMe + extension PLSQL classique, on est sous la barre des 0.03ms car le cache fonctionne particulièrement bien (mesuré en interne, -en gros- entre le firewall et l'input/output de postgres)... Donc en SQL "classique" ca n'est même pas forcément mauvais comme choix pour un jeu de donnée comme ca...
 
Perso je commencerai pas écouler tout ce qui est déjà fait, la perte de perf entre un SGBD et ton app par exemple peut descendre facilement sous la ms si bien configuré donc bon je pense pas que internaliser le storage soit aujourd'hui une si bonne idée...

T'avais pas pris un X1 ?

Je viens de voir sur le topic dédié

Après avoir tenté d'extorquer les membres de l'OTAN, Trump fait la même chose avec la Corée du Sud et le Japon.

Il les menace de retirer les troupes américaines si ces pays ne payent pas respectivement 5 milliards et 8 milliards de $. Un chef de Mafia.