Discussion :

[skuatamad]

Je n'ai pas tout lu, mais juste une remarque :
L'index suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UNIQUE KEY `Search` (`date`,`siteId`,`userId`,`countryId`)

n'est probablement pas adapté pour un filtre du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE date >= "2014-01-01" AND siteId IN (25,45,67) AND countryId = 2 AND userId IN (55,223,795)

La date devrait plutôt être placée en dernier (et ne pas être nommé date...)

Il est quand même nécessaire de rajouter certains index, sans faire une combinaison exhaustive.

Par ailleurs, mysql n'est pas très adapté pour le besoin car
- pas de fonction analytique pour les besoins des requêtes complexes qui donc sont encore plus complexes en mysql.
- pas d'index bitmap
- pas de vues matérialisées

L'absence de fonctionnalité a un coup !

Postgresql a effectivement plus de fonctionnalité utile pour votre besoin, mariadb c'est juste mysql donc inutile pour la problématique.

[SQLpro]

J'en suis à 150Go de données. (Sachant que ça ne fait que 6 mois qu'on récupère de vraies données (en gros les données de 2013 ne représentent presque rien) et qu'on en a de plus en plus au fil du temps).

@SQLpro : Je comprend. Cependant, je ne pense pas avoir de données orphelines étant donné que la suppression au niveau des models de dimension est tout simplement impossible du côté applicatif (et je ne m'amuse pas à en supprimer au hasard en ligne de commande dans la base ) et comme je l'ai réécrit après, l'intégrité des données à ce niveau là n'est pas critique et même si je me retrouve à avoir des données orphelines, ce n'est pas grave non plus. Mon problème est vraiment au niveau des performances et pas de l'intégrité de mes données

Vous n'avez donc jamais eu de transaction annulées ? Heureux homme !!!!

Je me marre de plus en plus !!!

A +

[CinePhil]

Comme dit par mes prédécesseurs :
- pas sûr que vos sous-tables soient utiles ;
- optimisez vos index en suivant les conseils des articles de SQLPro ;
- gérez votre intégrité dans le SGBD à l'aide des clés étrangères.

Mais je subodore un autre problème éventuel... puisque vous avez dit que vous gériez l'intégrité par l'application, est-ce que, par malheur, vous utiliseriez en plus un ORM (Objet Réellement Merdique ) pour la partie de gestion des données dans votre application ?
Si c'est le cas, écrivez vous même vos requêtes et/ou faites des vues dans le SGBD et requêtez de façon simple les vues.

Pour les mises à jour avec vos taux de change, utilisez des procédures SQL plutôt qu'une fonction applicative.

À une plus petite échelle que vous, j'ai réalisé en 2008/2009 une base de données MySQL avec des tables de plusieurs dizaines de millions de lignes mais grâce à un bon modèle de données et une bonne indexation, aucune requête ne prenait plus d'une seconde, malgré des jointures entre grosses tables et malgré la moindre performance des serveurs de l'époque par rapport à ce que vous avez à votre disposition aujourd'hui.