Reprise du message précédent :

Dans quel sens ? Le côté propriétaire ? Ou le peu d'adoptions ?
D'ailleurs en parlant de Java, j'utilise quelques softs qui sont basés dessus, et bien je les trouvent assez patauds. Ca marche bien, mais ça ne m'a pas l'air beaucoup plus réactif que Atom qui est basé sur Electron.
 

 
C'est exactement ce que je suis dit vis à vis des connaissances web    
J'ai toutefois dans l'idée de commercialiser le truc si j'arrive à faire ce que je veux. Ca reste cependant un objectif à l'horizon de quelques années.
 
Je pense démarrer quelques tutos Qt pour voir car ça me tente bien de faire ça en en python, le code est très propre
 
EDIT : __alt a poster entre-temps, je vois qu'il est du même avis

 
Clairement vaut mieux une app Electron bien codée qu'un app Java mal branlée.

 
   
 
Je sais pas si ce soft est pas bien codé ou pas mais par ex PDFstudio viewer de chez qoppa, qui par ailleurs est absolument EXCELLENT avec plein de features (c'est ptet le probleme ), est assez lent.
Bon après j'ai un PC vraiment tout pourri pour l'instant donc c'est probablement un peu biaisé.
 
Bon aller, je tente des tutos sur Qt... Ptet aussi des bouquins s'il y a quelque chose de sympa.

+1000
 
Go Electron, spa mal, et surtout largement moins relous que les autres cités.
 
JavaFX tout le monde s'en branle donc passe ton chemin.

Naïvement je prendrai n queue et tu décides dans quelle queue tu mets la demande à base de tes id de périmètre modulo le nombre de queue. Après ça devient un peu technique si tu dois splitter une queue alors qu'elle n'est pas vide.
Ou alors tu prends une technologie qui gère le sharding nativement, mais je sais pas si ça existe en open source.

 
soit je suis pas bien réveillé, soit c'est le genre de problèmes auxquels kafka est censé répondre, non?

 
Réponse groupée :
 
 
 
La problématique :
 

• J'ai des opérations à traiter sur des "points", qui se basent sur la situation du point => je dois proscrire l'exécution simultanée de 2 opérations sur le même point.
• Je voudrais la plus grande souplesse possible sur la capacité de traitement : on a une charge qui n'est pas lisse du tout (sur ~400 k appels / jour, j'en ai souvenr 380k sur 2h, et le reste étalé dans la journée)
• Je ne veux pas que ça constitue du stock : les opérations de la nuit (on est en bout de chaîne, entre 5h30 et 7h à la louche) doivent être traitées le matin 8h si possible.

Aujourd'hui, j'ai 6 pods (on est sur Openshift) qui traitent les appels, et ça tient. Mais ils se branlent la nouille pendant les 3/4 du temps.
 
Si je mets un seul pod de traitement, j'ai peur qu'il faille le dimensionner énorme pour encaisser la charge de la nuit, et qu'il ne foute rien le reste du temps. Et puis ça correspond pas à l'idée de scaler intelligemment, quoi.
 
Donc, je voudrais pouvoir ajouter des pods en fonction de la charge... Sauf que tous les pods ont la même config, si je ne me trompe pas.  
 
Au départ on avait imaginé une solution à base de "mono pod" :  
 
On décidait le nombre de threads de traitement, et chaque thread prenait les opérations pour les points dont HASH(id, Nombre_de_thread) = une valeur
 
Mais ça marche pas avec plusieurs pods, ça
 
Donc l'idée est d'avoir 2 tables :
 
* OPERATION : les opérations,
* POINTS : les ID de points en traitement
 
Côté services :
 

• on ajoute l'ID de point dans POINTS avec un merge, s'il n'y est pas.
• on ajoute l'opération

Côté démon de traitement :
 

• un pod fait un "select for update skip locked" dans POINTS, en chopant l'ID du point de l'opération la plus ancienne à traiter.
• Il traite les opérations du point.
• S'il y a des nouvelles opérations, il ne fait rien, sinon il supprime la ligne dans POINTS.

 
Mais d'une part onn'a pas de certitude que ça marche, et d'autre part, s'il y a déjà des trucs qui existent, pourquoi pas.
 
Kafka, je sais pas, je connais pas bien..A voir.

Avec kafka tu peux découper tes données en topics et partitions, avoir des consommateurs multiples (et groupables), que tu peux ajouter facilement pour faire de la répartition de charge...il y a probablement un certain investissement technique pour regarder ce qui correspond le mieux au besoin, mais vu d'ici ça doit répondre.

 
Un mélange python/QT ça doit en effet pas être mal niveau propreté, maturité de l'outil, etc etc. Si on ne retient pas la solution web/js je choisirai ça aussi je pense.

 
Par contre, c'est quoi le meilleur IDE en 2020 avec glisser/déposer des widgets  sur Windows ? Parce que les démos que j'ai vu, ça semble assez pénible de tout installer et de tout configurer... Ya toujours que QT designer?

Si tu n'as pas besoin d'accéder aux données de l'ordi ( accès aux fichiers en masse, accès a des capteurs, ...) tu peux aussi regarder du côté du pur web (PWA )  , et n'introduire electron que lorsque tu en as besoin

Par exemple, tu peu déjà utiliser une appli web et la publier sur le store android : https://developers.google.com/web/a [...] b-activity ou windows 10 https://docs.microsoft.com/en-us/mi [...] soft-store et elles s'exécuteront sur toutes les plateformes avec un navigateur moderne

 
QT Creator est un bon IDE mais pour C++ (une alternative à Visual Studio ou CLion). Pour le design des interfaces je ne sais pas trop, en général les gens décrivent tout en qml donc ce n'est pas visuel (pas de glisser/déposer de widget). Et pour un IDE Python aucune idée, PyCharm sans doute.

J'en ai soupé des outil de design d'interface : ça marche très bien pour les designer ( sketch par exemple), mais c'est pénible au fur et à mesure que l'appli grandi et que la logique métier se rapprooche du monde réél
 
source : xcode+storyboard, et comme beaucoup, je suis revenu à la description des apps dans le code (alors même que le langage de définition de la mise en page en UIKit est verbeux et mauvais)

 
Je suis pas sûr que ça réponde au problème de "si j'ajoute un consommateur, est-ce que je suis certain qu'il ne consommera pas de données relatives à un point dont un autre consommateur est en train de s'occuper".
 
Le coup des topics et partitions, j'ai peur que ça réponde pas au besoin de scalabilité "à conf identique"
 

Ton pod consommateur, tu peux pas lui mettre des limites basses et hautes très élastiques? Plutôt qu'en avoir plusieurs.
T'as ~50 requêtes par secondes pendant deux heures en gros?
Tu devrais pouvoir ingérer ça sans trop de problème.
 
Kafka c'est bien mais tu vas déplacer la complexité vers la manière dont tu gères les consommateurs.

Je vois quelques cas limites :  
 
Coté service, il faut créer un nouveau point si le point est déjà en court de traitement pour que le consommateur se relance avec les nouvelles données
 
Coté consommateur : il faut qu'il copie les données dont il a besoin au début, sinon il risque d'avoir des données qui bougent lorsqu'un service ajoutera un nouveau point
 
 
Moi je verrai une table  
[pointId, operation, lineCounter, state ] state ={waiting, active, done}
 
 
Les services ne modifient pas de ligne, mais ajoutent systématiquement des lignes, il n'ont pas le droit de modifier la colonne state
 
Le / Les consommateur prennent la ligne la plus ancienne qui correspond à un point pas en cours de traitement
 
Et même , je ne ferai pas une colonne de statut, mais 3 dates : createdAt, activatedAt, doneAt  pour te permettre de monitorer tout ça et de scaler intelligement
 
En journée, cette table est agglomérée dans des stats et purgée

 
Sauf erreur de ma part si tu partitionnes tes topics, chaque partition est affectée à un et un seul groupe de consommateurs. Du coup si tu ajoutes un nouveau groupe de consommateurs, les partiitions vont être réaffectées, mais tu auras toujours la garantie qu'un seul groupe gère une partition. Donc potentiellement ton truc c'est un consommateur = un groupe, et les opérations d'un point à garantir dans la même partition en entrée.
Les partitions de ton topic deviennent des "groupes de points" et tu répartis ta charge en fonction de ces groupes de points. Par contre il faudra prévoir un nombre de partitions supérieur ou égal au nombre max de consommateurs que tu veux pouvoir coller dessus...
la seule différence de conf entre 2 consommateurs ce serait l'ID du groupe, ça parait raisonnable...
 
...ou alors je fume la moquette sur ce que fait kafka...

Mais en vrai, si ça tourne aujourd'hui, qu'il n'y a pas trop de cout de fonctionnement, qu'il n'y a pas trop de montée en charge prévisible => je n'optimiserai pas

Ouais mais c'est toujours le même problème : on se trimballe des tonnes de dépendances. Quand je vois des projets Java, web, Electron ou autres qui réalisent des tâches triviales et qui ont besoin de centaines de Mo de dépendances, ça me fait juste chier.

TIL: les Mars non-US sont une copie des Milky Way US, les Mars US originaux n’ont aucun rapport, et les Milky Way non-US s’appellent 3 musketeers aux US.

Tu généralises
Visual studio est une app electron, atom aussi  
 
Par contre, c'est facile de faire de la merde (mais elle est faite rapidement et elle marche facilement, ce n'est pas si pire)

Ça existe des outils point se faire des dash de perfs style arewefastyet? (mais documentés et génériques, quand j’avais regardé arewefastyet c’était plus ou moins hard-codé pour aller chercher des trucs chez Mozilla, dans perfherder).

  à la perf/perftop ?  ( https://perf.wiki.kernel.org/index. [...] h_perf_top )

Non, à la arewefastyet.

Et les Mars US ils ressemblent à quoi ?

J’ai pas trouvé d’équivalent. C’est un nougat aux amandes enrobé de chocolat (sans caramel).
 
Ce qui s’en rapproche le plus c’est le snickers amande (qui a d’ailleurs remplacé le mars US), sans le caramel.

Oui apparemment c'est un snickers amandes. Et la version non-US _est_ la version originale, la barre Mars US a été créée après (et abandonnée depuis)

 
bah c'est la solution la plus simple. Mais si on veut qu'il puisse scaler tranquille, il faut réserver sa capacité max sur le noeud du cluster où il est déployé (parce que sinon il pourra pas monter en charge quand il en aura besoin)
Alors que si tu monte un pod, OSEF de sur quel noeud on le met.
 
 

 
1 : j'ai dû mal expliquer : la table "POINTS" contient juste les ID des points. Le service y ajoute l'ID du point quand il écrit son opération, s'il n'y est pas déjà, et c'est tout.
Les opérations sont toujours ajoutées dans la table des opérations.
 
 
2 : les donnéers de la table OPERATIONS ne sont jamais modifiées. Le consommateur les lit, et les supprime quand il a fini. Le contenu de cette table doit être un flux, pas un stock.
 
 
 
 

 
hmmmm, ça marcherait, ça. Mais encore une fois : tu es obligé que chaque consommateur soit identifiable. Or dans un environnement genre K8S/Openshift, à ma connaissance tous les pods partagent la même config. Le seul truc qui permet de les identifier, àç la limite c'est le hostname.
Du coup, est-ce que Kafka peut gérer dynamiquement une nouvelle partition qui apparaît ou disparaît, et de lui affecter automatiquement un consommateur, pour faire en sorte qu'il y ait toujours un consommateur par partition?
 

 
Aujourd'hui ça tourne pas!
 
A pleine charge, on a le client qui nous bombarde de requêtes, sans se préoccuper de l'ordre / point. Donc si on a la requête MODIF_1 sur le point 1, qui arrive, et 2 millisecondes plus tard, l'opération MODIF_2 sur le même point qui arrive sur un autre pod, les 2 vont se baser sur le même état du point, alors que MODIF_2 devrait se baser sur la situation après application de MODIF_1.
 
Et on peut pas locker les points parce qu'il y a un timeout assez court, qui fait que si MODIF_2 échoue à cause de ça, elle sera rejouée 30 minutes plus tard  
(même s de notre côté, on l'applique quand même : le timeout ne concerne que le client)
 
(du coup, quand on a les pods ras la gueule pendant plus de 30 minutes, , on a un effet boule de neige qui fait chier)

J’ai bien précisé « la version US originelle ».

HArko a entendu dire qu'il y a de la thune à faire dans le traitement de données https://twitter.com/emmawage/status/1255172980788785152

Aucune idée, je suis pas expert du truc, j'ai juste regardé à quoi ça ressemblait quand les collègues ont commencé à s'en servir...je vais surement jouer avec d'ici quelques mois, mais là tout de suite j'en sais pas plus.
Après tu as toujours moyen d'avoir un service qui distribue des identifiants de groupe uniques  et tes consommateurs qui interrogent ce service au démarrage pour obtenir un n° unique (ou même tu bataille pas et tu utilises un UUID généré au démarrage comme id de groupe...). Comme ça tes consommateurs sont tous identiques mais consomment tous des données strictement cloisonnées.

[edit]

... et tu as pas besoin de garantir un consommateur par partition toi même, juste qu'il y a au moins autant de partitions que de (groupes de) consommateurs. C'est kafka qui se charge de la répartition et qui s'adapte quand tu rajoutes des consommateurs.

[edit2]

..je m’emmêle les pinceaux avec les groupes en fait je crois, il faut probablement que tous tes consommateurs soient dans le même groupe au contraire :

https://kafka.apache.org/intro

... du coup c'est encore plus simple à scaler...

Si je dis pas de bêtises:
Tu peux avoir autant de groupes que tu veux qui consomment un topic.
À l'intérieur d'un groupe, Kafka s'assure que les messages soient consommés une seule fois.
Tu peux avoir un ou plusieurs consommateurs par groupe, qui sont dynamiquement assignés aux partitions du topic.

Donc il faudrait que gfive crée M topics (un par point), avec N partitions pour pouvoir distribuer sur N consommateurs comme tu l'as dit.
Un pod devra lancer M consommateurs, chacun dans leur propre groupe. Et là tu peux scaler jusqu'à N pods.

Edit: oui voilà.

 
Tu sais que Java est modulaire depuis Java 9 et que tu peux packager des apps avec des runtimes allégés ?

Et y a même GraalVM native image! Enfin quand ça marche.
Apparemment y a des gens qui font du JavaFX avec ça (Gluon).

 
Oui, c'est le fils de l'inventeur de l'un qui a inventé l'autre, non ?

 
Du coup je voyais un seul topic mais N partitions, et X consommateurs (dans le m^mee groupe, du coup) avec X <= N.
Et j'y connais rien à kubernetes, mais pour moi l'idée pour scaler c'était un conteneur pas consommateur, quand on a plus de besoins on en démarre plus et youpi. Si kubernetes est aussi bien que c'est vendu par les collègues, il doit même être possible d'en démarrer un gros paquet la nuit quand il y a de la charge et de réduire la journée...

 
 
J'ai plusieurs millions de points.
 

...du coup un topic et N partitions.

...et juste s'assurer qu'un point ne change pas de partition coté producteurs

 
Genre les barres Nuts ? (Mais Nuts c'est aux noisettes)

 
Exactement.
 
On peut anticiper la charge et faire monter les pods à l'avance, ou bien faire monter des pods selon la charge, on doit même pouvoir le déclencher sur la taille de file d'attente, vu qu'on peut écrire des métriques custom, il me semble.
 

Le père a inventé la recette aux US et l’a refilée à son fils qui l’a rebrandée en Angleterre