Comment gérer les requêtes de plus de 500 millions d'articles

La structure de mes données est la suivante:

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

J'ai besoin d'effectuer les requêtes suivantes:

Première:

• Filtrer les données par date, filter_a, filter_b, filter_cet d' autres

Deuxièmement, avec les données filtrées:

• compter tous les enregistrements
• obtenir la moyenne de variable_a, variable_betvariable_c
• obtenir l' écart-type de variable_a, variable_betvariable_c
• obtenir des quartiles de variable_a, variable_betvariable_c
• regrouper les données par groupou second_groupet agréger (Count, Avg, Std, ..)

Le nombre des utilisateurs du système est d' environ 10 ou 15, mais le nombre d'éléments est énorme, il est en ce moment 70M mais il sera 500M dans quelques semaines et il sera 1000M dans environ un an.

Le nombre de requêtes est petit, pas plus de 10 utilisateurs simultanément, mon problème est de savoir comment gérer ces requêtes avec cette énorme quantité de données.

Qu'est-ce que j'ai essayé jusqu'à présent?

• J'ai commencé par mongodb, au début c'était rapide mais ça devenait lent lors du calcul des quartiles avec 10M +. Cela s'est amélioré lorsque j'ai ajouté des index, mais cela n'a pas beaucoup aidé lorsque j'ai dû interroger toutes les données. J'ai commencé à utiliser mongodb car les données étaient très dynamiques mais heureusement le format des données "ne va plus changer".

• Comme filter_aet filter_bpourrait être vu comme des noeuds, j'ai essayé neo4j. Je l'ai beaucoup aimé neo4j mais mon graphique avait BEAUCOUP d'arêtes pour que les requêtes ne soient pas très rapides.

• Enfin, comme le format des données ne changera pas et qu'il ne s'agit que d'une seule collection / table, il ne nécessite donc aucune jointure dans SQL, j'ai vérifié postgresql. Mes tests ont été plus rapides avec postgresql, mais j'ai peur qu'il ne puisse pas évoluer correctement à l'avenir.

De quoi ai-je besoin?

• Le postgresql est-il un bon choix pour ce cas?
• Y a-t-il un autre type de base de données que je pourrais utiliser? lequel est le meilleur pour ce cas?
• Que pouvais-je faire d'autre pour l'améliorer?

Éditer

• Environ 1 million d'éléments sont insérés chaque jour et «ne devraient pas changer» au fil du temps.
• La vitesse d'écriture n'est pas importante
• L'exigence difficile est de lire / agréger rapidement

Merci!

Au lieu de s'appuyer sur une base de données relationnelle pour effectuer ces calculs statistiques sur des données de séries chronologiques, je vous suggère de déplacer ce travail mathématique et de post-traitement en dehors de la base de données dans une application cliente.

En utilisant un langage de script comme Python ou Ruby, vous pouvez résoudre le problème de manière incrémentielle en recherchant des «morceaux» de données sur une période de temps fixe, calculer un résumé statistique intermédiaire, puis combiner les résultats sur plusieurs morceaux, pendant que vous bouclez sur toute l'histoire. Certaines mesures statistiques sont difficiles à combiner entre les morceaux, mais quelque chose comme Avg () n'a besoin que de sum () et count () par morceau, O (1) vs O (chunksize), donc la fusion de morceaux peut bien évoluer.

Étant donné que vos données ne changent pas et qu'elles sont uniquement ajoutées, je stocke les données où vous le souhaitez; Amazon S3 par exemple, mais toute base de données à lecture rapide sera correcte. Pas d'index. La base de données / FS que vous choisissez doit avoir la possibilité de lire les données dans des compartiments: vous pouvez, par exemple, avoir un fichier par jour avec vos enregistrements 1M.

Ensuite, j'utiliserais Spark pour faire le filtrage / l'analyse. Il est basé sur un cluster, vous pouvez l'adapter à vos besoins.

La réponse dépend de la façon dont vous allez utiliser les données après cela. Si pour le traitement, mieux utiliser Cassandra, si pour l'analyse, mieux utiliser Hive.

Ce type de situation est idéal pour l'entreposage de données, en utilisant les techniques perfectionnées par Ralph Kimball et co., Sur des plates-formes comme SQL Server (celle que je connais le mieux). Ils ont été conçus spécifiquement pour ce type de scénario: d'énormes quantités d'enregistrements de données relativement statiques, pour lesquelles vous devez calculer des agrégats de ce type. NonLa technique relationnelle sera adaptée à l'entreposage de données correctement implémenté dans des applications de ce type, bien que certaines soient certainement meilleures que d'autres si votre organisation ne peut tout simplement pas se permettre les licences des packages logiciels (tels que SQL Server Analysis Services) qui les implémentent. Il existe également une courbe d'apprentissage pour implémenter des langages tels que MDX qui sont conçus sur mesure pour ce type d'accès aux données. Si l'entreposage de données est une option viable pour votre organisation, alors ne perdez pas de temps à chercher une solution relationnelle; ce n'est pas un problème de base de données relationnelle. Je peux poster quelques références de base à Kimball, etc. et des liens vers SSAS et MDX (désolé, je ne peux pas aider Oracle et d'autres concurrents que je ne connais pas) si besoin est. J'espère que ça aide.