Reprise du message précédent :

je crois que dans oracle tu peux indexer une vue (matérialisée), du coup tu pourrais peut-être créer une vue des données active, avec l'indexation sur la vue, et laisser rouler la grosse table derrière ?

https://docs.oracle.com/cd/E11882_0 [...] #DWHSG8216

edit: je pense qu'au final dans le moteur ça fait strictement ce que tu ferais à la main, mais au moins c'est pas toi qui doit faire gaffe aux invariants.

Spas con, mais je dois aussi pouvoir chercher sur les données non actives.

pourquoi pas une table des positions récentes avec un trigger qui insère dans une table des positions toute dates confondues / histo
 
et des scripts de purge qui vont bien  
 
?

 
Ok, donc t'as grosso-merdo des données "de prod" et des données "d'archive" dans la même table, avec des données qui restent vivantes 2 ans mais une durée de conservation des archives sur 28 ans?
 
Vu d'ici, quand un mec passe à l'état "archive" il faut dégager ses données dans une/des tables dédiées aux données "mortes". Ca te fait des données "de prod" plus light donc plus de réactivité, et les délais de traitement longs sont (a priori) pas gênants sur de l'archive...non?

Tu noteras qu'ils ont compris qu'il valait mieux pas entrer en bourse trop tôt comme durant la première bulle .com, vu que les traders en face vont forcément se mettre à vendre short quand le vent tourne.
Aujourd'hui ces boîtes entretiennent l'illusion le plus longtemps possible, et au final c'est les employés assis sur un gros tas de parts valant que dalle qui se font bien enfiler.
À ça t'ajoutes parfois une culture fondée sur le mépris des régulations et les retours de bâton qui s'ensuivent, comme pour Theranos ces jours. Ça va être rigolo.

le 15/01 :  

Et sinon :

En même temps je le comprends :it's a small world est fermé, ça énerve

C'est pas exactement le genre de trucs pour lequel le partitionnement de tables est fait? https://docs.oracle.com/html/A96524_01/c12parti.htm Genre tu fais un partitionnement annuel ou mensuel, t'as le temps de voir venir avant la limite de 64000 partitions/table.

En un peu plus soft, tu peux aussi faire de l'indexation partielle, tu indexes les 18 derniers mois de données mais les trucs plus anciens sont pas indexés.

plein de bonnes idées pour mon problème et d'autres inapplicables, je réponds. tt à l'heure.

Tu peux faire une autre vue avec exactement le même schéma mais pas les index pour l'archive

Citer Spotify pour parler des boites de la SV, fallait oser    
 
Parler d'Uber qui n'est globalement pas une boite de tech, pareil.
 
Ce n'est pas parce qu'un système est mal utilisé qu'il est mauvais. J'ai pas le temps de developer plus la, mais il y a eu un certain nombre de choses dites qui ressemblent plus à un amalgame et à une vision relayée par la presse.
 
Mais oui, je conseille aux gens autour de moi de se mettre au chaud dans des boites solides en ce moment, ça va saigner

tu vois t'as bien fait de signer à Montpellier

C'est pas encore signé
 
Je signe lundi.

Mon calvaire quotidien

des détails, des détails, ....

 
Oui c'est suédois, mais ca suit le même modèle donc ça reste pertinent : même âge, même source de financement, même propension à générer des pertes.
 
Après je jette pas bébé avec l'eau du bain, y'a sûrement un tas de startup qui jouent le jeu avec l'optique de devenir rentable de manière réaliste a un horizon réaliste (et qui y arriveront ou pas , c'est le jeu des startup).
 
Mais là je te parle de l'eldorado qui en vendu, en mode si t'es pas une boîte comme nous t'es qu'un con (cfhttp://paulgraham.com/ineq.html ).
Je pense qu'avant d'être aussi arrogant faudrait prouver le modèle un peu plus.

 
Il n'y a pas de données d'archive / actives, en fait.
 
C'est les positions des mecs placés sous surveillance électronique avec GPS (les délinquants sexuels en fin de peine après leur sortie de taule, et Harko depuis l'affaire Dati)
 
Ils ne restent que 18 mois sous surveillance en moyenne, parce qu'ils récidivent tous (pour le moment, depuis le début du suystème, un seul mec n'est pas retourné en taule)
 
Je reçois donc des données pour les mecs en cours de placement (environ 60 à un instant donné, mais ça peut changer), et je dois conserver tout l'historique (la base entière est une archive, c'est une autre appli qui gère les positions au quotidien, en fait, et qui ne peut pas garder les données pour des raisons de perfs, de volume, et de législation)
 
Donc, si je compte ~40 nouveaux mec / an, sur 28 ans de conservation, je vais avoir un millier de dossiers dans la DB, avec pour chacun 18 mois de positions, à la louche. Soit environ 8 millions de positions par tête de pipe, et 8 milliards au total (ça, c'est si la loi ne fait pas subitement passer le nombre de mecs de 60 tous les 18 mois à 10000 )
 
Et je dois tout indexer (ou pas, en fait, on y viendra) parce que les positions servent a posteriori pour des besoins d'enquête (d'où les 28 ans : une victime a 10 ans après sa majorité pour porter plainte => 28 ans)
 
Donc, je ne peux pas écarter des données des recherches : si on dit "je veux savoir s'il y avait un mec sosu placement près du 12 rue du quai à ploumarach' le 10 Juillet 1990, ben ça doit me retourner un résultat (et la perf a assez peu d'importance : les enquêtes urgentes sont faites avec l'appli de surveillance)
 
voilà pour le contexte.
 
Pour les propositions :
 
- celle de Nraynaud, un peu retravailler, ça pourrait être d'avoir une vue par dossier, indexée, et de virer l'indexation sur la base entière : je sélectionne d'abord les dossiers sur la date, puis je cherche dans les vues, mais bon.
 
- les idées de Skeye et Fiscalisator sont pas dans la cible mais c'est ma faute que j'explique mal avec les 30 mots qu'on parle pas le latin
 
- masklinn et le partitionnement : la table est partitonnée (by range sur les dates, par trimestre). Et l'index aussi. Mais les tests qu'on a fait sur une table non partitionnée avec 7 millions de positions donnent de très mauvais résultats en suppression (en gros, le machin part en mise à jour de l'index géographique, et on en a pour la journée au moment du commit). Or, en prod, avec 60 mecs et un partitionnement par trimestre, on aura plus de 8 millions de lignes par partition. Et il faudra traiter toutes les partitions sur la durée de placement du dossier à supprimer. Bref c'est pas gagné.
 
Mais au final, je me demande si l'indexation géographique est un si bon calcul. Parce que le premier critère discriminant, c'est la date.
 
En faisant une première sélection sur la date, on va éliminer l'énorme majorité des positions (la fenêtre max de recherche sur la date, c'est 60 jours. Donc, 60 jours, à 60 mecs "glissants", ça fait ~5 millions de positions)
 
Faudrait voir ce que donne la recherche géographique là dessus sans indexation... Je m'attendais à moins, fait chier.
 
Tous ces calculs reposent sur un échantillonage de 1 minute, mais je me souviens plus si c'est ça dans els faits. Mais ça change pas grand chose aux ordres de grandeur.
 
 
 
 
 

Indexation brutale: tu mets tes données en wgs84 (sinon tu vas en chier avec les dom tom, mais les gps retournent du wgs84 de toutes façons) tu sépares latitude et longitude, ensuite tu fais un index composite (lat, long)
Voire même un triple composite (date, alt,long)
 
Ensuite tu fais tes recherches par des carrés angulaires de 100km de côté. Et tu raffinés dedans.
 
Ça fait une anomalie sur la longitude au niveau de la ligne de date et des pôles, mais je pense que tu t'en fous.
 
Et ensuite tu fais ton calcul géographique sans la moindre indexation sur les résultats, et tu peux même le faire faire par le package géographique de la base. Tu as esri ou les trucs natifs ?
 
Edit : et tu fais ta première recherche avec 100km sur une terre sphérique, comme ça tu peux directement calculer ton angle et le mettre en dur

 
Les données sont en wgs84. C'est stocké sous un type Oracle qui fait partie d'une extension (MDSYS.SDO_GEOMETRY). et il y a des procédures et des fonctions dans l'extension pour faire des calculs & co (genre transformer les cercles en ploygones. Je sais pas pourquoi ils ont fait ce choix là, d'ailleurs, parce que l'API JS qui affiche les zones est tout à fait capable d'afficher un cercle, mais bon...
 
Donc séparer ça en plusieurs bouts pour séparer latitude / longitude, ça s'étudie, mais pas en première option : la première c'est de voir si une autre indexation que la géographique pose aussi le problème de perfs à la suppression ou pas. Si oui, ça sert à rien de changer d'index. Si non, ça peut être une bonne piste.

Tu peux indexer sur une fonction, pour tester rapidement, tu peux indexer sur la fonction qui extrait la latitude.

... Au final, c'est même vachement plus con que ça avec la latitude et la longitude indexées : il suffit de chercher bêtement par intervalle des deux.
 
J'ai des zones de recherche circulaires, mais il suffit de chercher dans le carré qui l'englobe et de virer les faux positifs après la requête SQL..  
 
(bon, après le mode de recherche est particulier : ils cherchent d'abors les dossiers qui ont des positions dans la zone à la date, puis ils affichent la carte avec la zone de recherche, et des cases à cocher pour chaque mec est fans les résultats. Ensuite, quand tu coches, ça affiche les positions, mais pas toutes : il y a un échnatillonage pour pas blinder la carte de marqueurs.

Si il y a peu de recherche,  beaucoup d'écriture, et que les recherches peuvent prendre le temps de s'executer : pourquoi mettre un/des index ?

mon problème ça va être quand faire ça.. La MOE me bombarde de demandes de mise à jour d'une doc obsolète et detoutes façons destinée à dégager quand on refera l'IHM, et j'ai même pas le temps de corriger les bugs
Le pire, c'est que la solution de résolution d'adresse qu'ils ont est obsolète (rues pas à jour, etc..), et que ce qui les préoccupe, c'est de savoir si on a bien écrit dans les specs que les zones sont affichées en bleu

Pour la représentation de geoloc, je te consille une heatmap , il y a plein de plugins leaflet qui le fond et c'est très parlant

Arrete de poste en parallèle
Pour le géocoding : addock  (https://github.com/addok/addok ) + BAN ( https://adresse.data.gouv.fr/ ) . gratuit et assez efficace

Oui, c'était mon histoire de carré sur une terre ronde, l'intervalle angulaire direct à coup de "<" sur la latitude et la longitude. Zéro fonction géographique.

 
Ca fait justement partie des questions que je me pose...
 
Surtout avec le partitionnement de la table.
 

 
bah là c'est pas trop adapté : on cherche à afficher la position d'un type. Et y'a pas assez de mecs pour qu'une heatmap ait des différences significatives : 60 sur le territoire Français + dom/tom, y'a peu de chances d'avoir autre chose que 60 points isolés.

 
j'avais pas saisi du premier coup, et je fatigue en plus (parce qu'en même temps, je met ces lutains de docs à jour et je met de la glae sur ma cuisse).. Au pire, je peux même prendre le temps de calculer précisément les bornes de mon carré de recherche, c'est pas ça qui va pourrir les perf.

Sur 60 jours, un type a 86400 geoloc / personne
 
Pour l'avoir fait sur des véhicules, ça permet de voir des pattern de maraudes.

J'ai entendu ça aussi. Il faut tout de suite lui retirer sa licence, les types qui conduisent en dormant, ça peut être très dangereux.

 
mhhhh, pas con....  
 

Tu fait une FFT 2D sur la heatmap et tu les as dire
 
Edit parce que je me fais chier à LAX et la seule célébrité que j'ai spoté c'est la bande de marseillais débiles de la télé : ce qui est bien avec la FFT sur la heatmap c'est que tu vas voir tout de suite qu'il tourne pas toutes les 15m sur un circuit de 100km de long, et ça tu l'aurais pas su sinon, alors que sinon tu pourrais avoir le doute.

 
J'aime la façon dont tu penses

8 millions de lignes par partition, c'est rien. Mais pour la suppression, c'est un drop de la partition elle-même, pas une suppression ligne à ligne, parce que sinon, effectivement t'as pas fini.
Sinon j'ai pas vraiment lu ton post parce qu'il est tard, mais un create table en live ne pose aucun problème (si les scripts sont corrects bien sûr).

Perso, j'ai pas compris. Tu peux traduire ?

 
bah je peux pas dropper toute la partition, en fait. Et l'expérience de cet après midi montre que les temps de suppression d'un million de lignes parmi 7 sont beaucoup trop longs pour que ça soit viable.
 
Surtout si on répète ça sur 4x28 partitions (minimum)

Ben en général, on partitionne par trimestre/semestre/whatever, et on droppe celles qui sont obsolètes. Je ne sais pas si tu es dans ce cas-la. Sinon, la suppression ligne à ligne prend un temps fou puisqu'il va faire des jointures dans tous les sens. Donc il faut supprimer d'abord les lignes dans les tables qui ne dépendent d'aucune autre, puis, les autres, et en dernier celles qui dépendent des précédentes. Ca normalement, je pense que tu dois pouvoir le faire par bloc de lignes "successives", ce qui devrait aller bcp plus vite.

Dernière chose: tu bosses pour un ministère ? On peut supposer qu'ils payent un support Oracle, ben prends ton téléphone, ils sont là pour ça.

Ce qui m'emmerde un peu c'est qu'avec une BDD gratuite il mettrait tout en une seule table et ça serait rapide et il en serait pas là. Oracle évidemment qu'ils vont pas optimiser leur indexation spatiale ils vendent les licences en fonction de la puissance qui est sous le logiciel, plus il est lent, plus tu mets de machines et plus ils gagnent d'argent.

genre un mysql spatial ?  

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.