Reprise du message précédent :

Hum, Ou pg?
 
Bon, souhaitez moi bonne chance, je viens de brancher mon iPhone dans une prise USB de siège d'avion. J'espère que je vais pas me chopper une saloperie.

Je me demandais si par conduction le long du cable USB y'avait moyen d'espionner ou injecter du signal dans le domaine RF, genre wifi, Bluetooth, gps ou gsm. Ça aurait un pouvoir de discrimination super élevé. Et tu peux toujours essayer de le diagnostiquer avec une antenne.

Pour les fans de Civilization, le Humble Bundle Firaxis est une mine d'or
 
https://www.humblebundle.com/

j'ai déjà les 3/4 des autres dans d'autres bundle

Tout à fait, parce qu'honnêtement, si je ne m'abuse ça fait moins d'un milliard de lignes sur les 28 ans, ça n'a quand même vraiment rien d'insurmontable.
Une seule table chronologique partitionnée et c'est bon. Sinon, il faut aussi insérer le timestamp dans les tables dépendantes et les partitionner chronologiquement, de façon à pouvoir faire les mêmes opérations de suppression par ranges de timestamps, dépendances en premier, puis table principale en dernier.
Et on indexe par date.

Maintenant, le jour où ils veulent suivre 10 000 personnes, et c'est pas du tout un scénario à exclure par les temps qui courent, - 60 personnes suivies seulement, je pensais que c'était bien plus que ça -, on entre dans le Big data, et là, je dirais qu'il faudra songer à passer à autre chose qu'Oracle.

pareil sur mon compte Steam

Si quelqu'un se demande encore pourquoi il faut voter à droite, comme gro5

   
 
(et en fait, Non, il fait aucune jointure pour les suppressions ligne à ligne : la table ne contient aucune clé référencée ailleurs)
 

 
ah ben ça... Mais bon, c'est là depuis un moment.. Mais bon, on a la TMA pour encore 3 ans, ça suffit pour leur proposer une migration (en deux étapes : 1 - virer l'extension spatial, 2 - passer sous Postgre (la seule alternative qu'on aura)
 

 
Pas forcément.
 
D'abord parce que l'échantillonnage toutes les minutes est complètement inutile. Il suffirait que l'appli qui envoie les données, au lieu de nous donner un ID complètment con par position, nous envoie un numéro d'ordre relatif au dossier, et on pourrait simplement stocker une position et le nombre d'occurences consécutives (éventuellement avec un calcul de proximité selon la précision du GPS)
 
Ca éviterait de récupérer et stocker les positions la nuit, déjà.
 
Ensuite, quand on est dans la zone d'assignation à résidence dans les horaires imposés, on n'a pas vraiment besoin de la position du mec non plus.
 
Sinon, pour le nombre, les 60 c'est ceux qui sont géolocalisés. Les condamnés de droit commun en surveillance électronique, ils sont juste assignés chez eux à certains horaires : ils ont un bracelet sans GPS, et une borne sur les zones d'assignation.
 
La borne détecte la présence du bracelet, ça suffit.
 
Les 60 mecs, ils ont comme les autres + un téléphone/GPS avec 2 boutons (un pour appeler et un pour décrocher), et des contrôles en plus (le téléphone envoie une alerte s'il est trop loin du bracelet hors zone d'assignation, etc..)
 
 
 

 
bah ça change rien en l'occurrence : les mecs sont des délinquants sexuels, ils ont fini leur peine de prison, et au lieu de les relâcher dans la nature on leur colle un bracelet géolocalisé. Ca permet de les récupérer plus vite quand ils déconnent (et pas si ils déconnent, donc)
 
C'est assez bancal au niveau du droit, d'ailleurs : en théorie ils ont purgé leur peine, et on leur en colle une supplémentaire. Mais bon.

Si on avait gardé des gens comme Dominique Perben ou Michèle Alliot-Marie à la justice, au service des victimes et non des criminels, on n'en serait pas là

Et sinon, si il y a une fréquence d'acutualisation fixe : tu stocke une trace gps par jour ou par mois, au lieu de juste stocker un hit ( une ligne au lieu d'une suite de point)  + eventuellement une table d'evenements déivant ( sortie de zone, coupure GPS, ...)

Ensuite les requêtes géographiques sont prévues pour

Et sinon, sur l'explosion du nombre de dossiers, ça marche pas en fait : il n'y a que sur les crimes sexuels que les délais de prescriptions commencent à courir à la majorité de la victime.
 
Et le nombre de criminels sexuels n'a aucune raison d'exploser du jour au lendemain.  
 
Donc, même si t'as 10k dossiers, on gardera pas les données plus de 10 ans (et encore, ça n'a pas grand intérêt à posteriori, en fait).
 

Il est chaud Dion aujourd'hui, c'est Taubira qui t'a mis dans tous tes états ?

 
On a tous les événements dans la DB, en plus. Mais ça sert manifestement moins pour les enquêtes que les positions.
 
Les positions, c'est nécessaire pour qu'on puisse savoir si le petit Kévin qui s'est fait agresser pendant qu'il se promenait au bois le 12 avril entre 8 et 9h peut avoir été victime d'un mec dans la DB.
 
Mais au final, les enquêtes c'est super rare, je pense. Il faut juste que ça soit possible.
 
La surveillance au jour le jour, elle est faite dans l'autre appli, qui nous envoie les données.
 
Il y a des mecs de la pénitentiaire qui surveillent les alarmes, et appellent la police si nécessaire. Mais leur appli ne peut pas garder toutes les données (pour plein de raisons : perfs, volume, et CNIL : les opérateurs n'ont pas le droit de voir les anciennes données, tout ça, donc au bout d'un moment l'appli les efface, après nous les avoir envoyées)
 

Alors stocke les traces GPS. Tu n'auras plus qu'un enregistrement par bonhomme et par jour ( ou par mois ) et tu utilisera l'indexe spatial comme il faut, sans avoir à faire de migration

 
L'appli m'envoie une position GPS par minute. Je vois pas comment je peux réduire ça à un enregistrement par bonhomme et par jour/mois?  
 
(je suis un noob en géoloc FYI)

 
Du coup tes suppressions de masse c'est quoi? Les délais de 28 ans expirés uniquement?

 
Exactement. Au bout de 28 ans, il faut pouvoir supprimer les positions du mec.
 
Et sur une table d'une taille comparable à ce que serait une partition au bout de 28 ans d'exploit, ça prend des plombes

définis "des plombes"?

aujourd'hui tu as chaque ligne qui a cette gueule :
date | POINT(lat ,  lng) | id_bonhomme

Tu pourrais avoir
date | id_bonhomme | LINE ( Point(lat,lng),POINT(lat,lng),..  

La longueur de la trace n'est pas vraiment un problème ( tu peux stocker en un seul objet la frontière précise d'un état, alors quelques milliers de points, c'est de la rigolade))

Le process de traitement d'une nouvelle coordonnées devient ( en pg, je ne connais pas oracle, et je ne souhaite pas le connaitre)

update table set trace = ST_addpoint(trace, ST_MakePoint(lat,lng))

edit : la fonction ne semble pas exister en oracle, mais quelqu'un l'a fait pour toi : http://spatialdbadvisor.com/oracle [...] for-oracle

bah hier, lancé à 16h, et pas fini à 18 quand j'ai dû débrancher le PC (la DB tourne sur une VM dessus)

Super idée, ça aussi.

Faut voir si les recherches seraient possibles avec ce genre de stockage, j'imagine que oui... Une piste de plus à explorer.

[Edit] En fait non. Il leur faut la date précise avec la position, et en plus :
- je ne suis pas sûr de les recevoir dans l'ordre.
- l'intervalle d'envoi de position n'est pas fixe (la précision augmente ou diminue selon les circonstances)

Logique, fondamentalement la position ça leur dit rien d'intéressant sauf si le type est assigné à résidence, donc sauf s'il est possible de rattacher des métadonnées aux points les formes c'est plus pour de la visu.

c'est pour ça qu'il faut une plage d'actualisation fixe. sinon, c'est mort . la date du point n sera donc date_debut + n* interval

Pour le cas du desordre : st_addpoint accepte d'intégrer un point n'importe ou dans une trace, donc ça peut être gérable si tu as la garantie que tu as un interval fixe au final

Si les fréquences varient peu, tu peux regrouper les traces par fréquences :

du 01/01 au 12/02 jojo est localisé toutes les minutes , ensuite il l'est toute les 5 minutes  : tu fais une trace du 01/01/ au 12/02 et une autre ensuite

 
Et ton environnement de prod c'est quoi? Ta suppression c'est quoi un simple delete from position_delinquant where delinquant_id = 'lolz'?
T'as envisagé de tester en parallélisant ça pour voir les gains?

 
Ca aurait marché si :
 
- on était sûr de recevoir les positions dans l'ordre,  
- l'intervalle était fixe.
 
Tu te construis ton path sur la journée, le numéro d'ordre de la position te donne la date. Mais là non. Et voilà le bordel pour remettre une position à sa place
 
A moins de faire un truc où tu crées de base un path de N position (où N = le nombre max de positions dans une journée, cad avec le plus petit intervalle d'échantillonnage possible), ensuite, tu remplis que les positions aux index qui vont bien. Mais bon, c'est un sacré merdier quand même : que mettre dans les trous?

La FFT te permet de représenter en fréquence tes données (signaux) non périodiques.

 
Ma VM est la même que celle de la prod. Et l'hôte est un un Core I7 quad avec 16 Go de ram (la VM en a 8)
 
Donc je pense pas que ça joue.
 
Sinon, c'est pas un delete bourrin.. Mais en fait ça devrait. Il devrait y avoir un index sur l'id du mec (il y en a un sur ID + Date).
 
Mais j'ai regardé l'état de ma session quand il fait ça, et il est bloqué sur la gestion de l'index. Du coup je me demande si tout ça (le déccoupage sur la date, les commits intermédiaires) es tbien utile.

 
Et tu fais ça à quel moment? Genre tu peux pas te permettre d'interrompre la prod le temps de faire un disable indexes/delete/rebuild indexes?

un rebuild index sur une table plusieurs centaines de millions de lignes. J'ai un doute

 
C'est probablement plus rapide que de le laisser faire des maj des indexes à chaque ligne dégagée par le delete.

 
Non.
 

 
Voilà.
 

 
Avant, la procédure  c'était "on dégage l'index, on supprime, et on reconstruit". Ils ont tenté une fois, la reconstruction a duré 35 heures.

Bref, si c'est faisable de prévoir un temps de "maintenance" pour ce type d'opérations perso je tenterais ça:
1) Disable/drop indexes sur la table concernée
2) Delete en parallélisant
3) Rebuild indexes
 
C'est tout à fait le style de traitements de masse que j'ai eu à traiter sur de la fusion de bases il y a 2 ans, avec des tables qui montent à plusieurs dizaines de millions de lignes...

 
Je pense que ça marcherait si c'était pas ce lutain d'index géographique, en fait.
 
 

ok, donc amha tu l'as dans l'os en gardant ta structure actuelle effectivement. Partitionnement de la table par individu et drop de la partition concernée quand les 28 ans sont passés?

Tu as un type polyligne dans le système géographique, avec des des opérations dessus, mais je pense que c'est pas bon de l'utiliser, parce que tu va vouloir l'heure des points aussi. Sinon y'a des formats genre gpx, mais je pense que ça va être l'enfer à gérer.

 
C'est ma première question (avec une table à la place d'une partition par mec)
 
mais bon, c'est lourdingue : il faudrait aussi faire attention aux tablespaces, etc.. là avec le script de partitionnement de la table par range /date, c'est simple, la table est partitionnée à l'avance pour des années, tout bien tout propre...
 
Il suffirait juste de virer l'aspect "géographique" de la chose. Parce qu eje suis convaincu que c'est ça qui fait chier. (mais je dois le tester d'abord : je vais me faire une table à partir de celel avec 7millions de lignes, en transformant la position en 2 colonnes, et en faisant des index simples sur ces colonnes là, pour voir si ça va plus vite.

Surtout que bordel.. La DB, elle passe son temps à être sollicitée en écriture pour manger les données.
 
Les enquêtes, c'est lancé par 3 pauvres péquins depuis l'appli web, qui passe son temps à se branler la nouille.  
 
Lui faire faire le boulot de déterminer si une position est ou pas dans un cercle, plutôt que de le faire faire à Oracle, c'est pas débile.

Tu remplaces chaque position du mec par une gaussienne centrée sur le point et t'as une vidéo de la probabilité que le mec soit à un endroit à chaque instant mais tu veux détecter s'il a un comportement répétitif, donc tu fais la FFT de la vidéo, et t'as pour chaque fréquence les lieux où il se rend à cette fréquence là qui apparaissent en rouge.
Genre s'il va tous les 2 jours voir sa maîtresse, le chemin va apparaître en rouge pour la fréquence de 2 jours.  
 
Le tout à un coût de calcul modique équivalent à aws+Google pendant 2 jours par mec surveillé

 
T'as ça http://syncstop.com/ (pas testé), mais sinon je me dis qu'un simple cache en plastique fin devrait permettre de pas faire les contacts sur les pins qui vont bien pour les devices qui sont pas Apple (ils se chargent de façon un poil différente des autres).

Ouais, je veux en faire un complètement isolé et qui sache parler dans le tuyau pour demander toute la puissance dispo. Je pense que je peux le faire avec 2 micro contrôleurs à 8 pins et un convertisseur dc/dc.

REPONDEZ A LA QUESTION §§§
http://www.1bite2go.com/en/