Nous avons besoin d'exécuter des requêtes analytiques sur les données stockées dans rds. Et cela devient très très lent à cause des requêtes groupées et de la taille toujours croissante des tables. Par exemple, nous avons les 3 tables suivantes dans RDS:
select name from alm, group, con where alm.group_id=group.id and alm.con_id=con.id group by name, group.type, con.ip
chacun des tableaux contient une très grande quantité de données et est mis à jour plusieurs fois par minute à mesure que les nouvelles données arrivent.
Maintenant, nous voulons exécuter des requêtes d'agrégation comme:
alm(id,name,cli, group_id, con_id ...) group(id, type,timestamp ...) con(id,ip,port ...)
Nous souhaitons également que les utilisateurs exécutent des requêtes d'agrégation personnalisées à l'avenir, par opposition à la requête de correction que nous fournissons à l'avenir.
Jusqu'à présent, les options que nous envisageons se déplacent vers Cassandra, Elasticsearch ou Dynamo db afin que l'agrégation soit plus rapide. Quelqu'un peut-il expliquer comment résoudre ce problème? Ou des miettes d'expérience? Quelqu'un sait-il que toutes les technologies ont un sérieux avantage sur les autres?
3 Réponses :
Cassandra et DynamoDB sont assez différents d'ElasticSearch. Et tous les trois sont très différents des offres de bases de données relationnelles.
Pour les analyses ad hoc, les bases de données relationnelles, avec un schéma bien conçu, peuvent être assez bonnes jusqu'au point où vous devez diviser vos données sur plusieurs serveurs (les problèmes de réplication commencent alors à dominer les avantages). Et c'est vraiment la principale motivation des bases de données non relationnelles. Mais le hic, c'est que pour résoudre le problème de mise à l'échelle horizontale, ils échangent généralement certaines fonctionnalités telles que la jonction et l'agrégation.
La recherche élastique est vraiment excellente pour répondre aux requêtes de recherche, mais pas particulièrement bonne pour les agrégations (autres que les dénombrements, les sommes et leurs estimations très basiques). Il est étonnant d'indexer de grandes quantités de données, mais il ne peut pas répondre aux requêtes impliquant plus d'un index.
Si vous avez de gros volumes de données et que vous avez besoin d'une agrégation, vous avez à peu près deux options:
si vous pouvez vous en sortir avec des analyses hors ligne, les infrastructures de traitement de données distribuées telles que Spark peuvent vous apporter les réponses dont vous avez besoin de manière très efficace
si vous avez besoin d'analyses en ligne, l'approche la plus courante consiste à pré-calculer les agrégations et à les mettre à jour au fur et à mesure que vous obtenez plus de données, de sorte que les réponses aux requêtes puissent être très rapides sans avoir à traiter beaucoup de données pour chaque requête
N'ayez pas peur de mélanger et d'assortir. Les bases de données relationnelles ont leur objectif, tout comme les bases de données non relationnelles. Il n'y a cependant pas de solution miracle.
Une autre option est les bases de données orientées colonnes , ce type de base de données est plus adapté aux cas `` analytiques '' lorsque vous avez de nombreux champs de données et que vous souhaitez effectuer des agrégations ou extraire un sous-ensemble de champs pour une grande quantité de données.
Récemment, Yandex ClickHouse est devenu très populaire et il existe un service orienté colonne d'Amazon - Redshift . Il existe également plusieurs autres solutions
Stocker dans le parquet et utiliser Spark, partitionner efficacement
Question pertinente: stackoverflow.com/questions/27054954/...