en termes SQL, nous stockons des données telles que ceci: toutes les valeurs de dimension sont des entiers. Cette table devient très grosse. Nous voulons des lectures bêtement rapides pour des questions telles que ceci: Nous voulons écrit rapidement et ne vous souciez pas de transactions et cohérence. Nous nous soucions de la tolérance de la disponibilité et de la partition éventuelles. Je regardais des alternatives "Nosql". Casandra peut-il faire le genre de questions que je cherche? Ce n'est pas immédiatement évident de lire leurs docs ... Si cela peut le faire, quelle est sa performance pour ces types de requêtes? regardait également mongodb, mais leur "groupe ()" A des limitations graves pour autant que je puisse lire (max de 10 000 rangées). Avez-vous de l'expérience avec l'une de ces bases de données et que vous le recommanderiez comme une solution au problème décrit ci-dessus? y a-t-il d'autres bases de données que je devrais considérer que cela peut faire ce genre de requêtes rapidement? acclamations,
Jimmy
3 Réponses :
examinait également Mongodb, mais leur fonction "Groupe ()" présente de graves limitations autant que je puisse lire (max de 10 000 rangées).
Pour clarifier, il y a 10 000 rangées retournées. Dans votre exemple, cela fonctionnera jusqu'à 10 000 combinaisons de
dimension1 / dimension2 . Si c'est trop volumineux, vous pouvez également utiliser le Carte / Réduire . Notez que si vous exécutez une requête avec plus de 10 000 résultats, il est préférable d'utiliser la carte / réduire et enregistrer ces données. 10k est un gros résultat de requête à autrement "jeter".Avez-vous de l'expérience avec l'une de ces bases de données et vous le recommanderiez-vous comme une solution au problème décrit ci-dessus?
Beaucoup de gens utilisent réellement MongoDB pour faire ce type de récapitulatif "en temps réel", mais ils utilisent des "comptoirs" au lieu de "agrégation". Au lieu de "rolling-up" des données détaillées, ils feront un insert régulier, puis ils incrètiront des comptoirs.
En particulier, en utilisant le modificateurs atomiques comme
$ INC &$ Appuyez sur pour mettre à jour atomiquement les données dans une seule demande.Jetez un coup d'œil à Hummingbird pour que quelqu'un faisait ça maintenant. Il y a aussi un système d'exploitation d'événements open source soutenu par MongoDB: grislog2 . Serverdensity effectue également la journalisation des événements de serveur soutenu par MongoDB.
En regardant ces personnes peut vous donner une inspiration pour les types de journalisation que vous voulez faire.
La fonction carte / réduction de Mongodb est-elle adaptée à une interrogation en temps réel? J'ai vu quelques "vieux" postes qui suggèrent que ce n'est pas, peut-être que c'est amélioré?
La carte / réduction de MongoDB est généralement pas recommandée pour interrogation en temps réel. Typiquement, le m / r est utilisé pour la pré-agrégation, puis vous interrogez dans cette collection. Donc, au lieu de faire des m / r en réponse à une demande de l'utilisateur, vous faites m / r en tant que Roll-ups sur une base régulière et interrogez sur ces résultats.
"groupe par" et "stupidement rapide" ne vont pas ensemble. C'est juste la nature de cette bête ... d'où les limitations sur l'opération de groupe de Mongo; Cassandra ne le supporte même pas de manière nativement (bien qu'elle ne fait pour la ruche ou les requêtes de cochon via Hadoop ... mais celles-ci ne sont pas destinées à être stupidement rapides).
Systèmes tels que le rainbird de Twitter (qui utilise Cassandra) fait des analyses en temps réel, faites-le en dénormalisant / pré-calculant les comptes: http://www.slideshare.net/kevinweil/rainbird-realTime-analytics-at-twitter-strata-2011
"Groupe par" et "stupidement vite" vont ensemble, car c'est ce que je ressens lorsque je joue avec l'API Google Analytics. Je reçois le groupe jusqu'à 7 dimensions (sur un possible choix de plus de 70+) et c'est stupidement rapide. Je suppose qu'ils utilisent bigtable, mais même alors, comment organisent-ils leurs données? Je ne peux pas imaginer dénormaliser toutes les combinaisons possibles jusqu'à 7 dimensions.
Si vous avez 7 dimensions sur des choix de plus de 70+ éventuels, avec Dites 10 mesures par dimension en moyenne (qui est une figurine très faible), comment vous désormerez-vous / pré-calculez les comptes pour une période de billion de billions de milliards de billions de billions de milliards de dollars ?
GA a un tas de doctorats résolvant le problème. Vous devez avoir sûrement entendu parler de Dremel. Ga a également de grandes grappes. En ce qui concerne les rapports personnalisés, ils peuvent les générer à la demande, au lieu de pré-calculer. Quoi qu'il en soit, c'est un problème très difficile, sinon il y aurait plus de solutions sur le marché.
J'ai commencé à descendre ce chemin à un but similaire (collecte de mesures et rapports de métrique), et voici où j'ai fini par ...
Obtenir les données en est la partie facile. Obtenir les données est la partie difficile.
Si vous avez le temps et le talent, vous pouvez apprendre et utiliser une combinaison d'outils open source tels que décrits ici: http: //kibana.org/infrastructructure.html . La liste de pièces:
Si vous avez plus d'argent que le temps, envisagez de splunk. C'est cher, mais c'est un bon choix pour beaucoup de situations. par exemple. Je suis dans une situation dans laquelle le client est extrêmement rare sur les gens, mais cela ne me dérange pas de dépenser de l'argent, alors Splunk a été un bon ajustement en ce sens que c'est plus une solution clé en main que d'apprendre et de coudre ensemble un composé d'outils .
De quel côté êtes-vous? Pourriez-vous gérer une solution .NET?
"" "J'étais aussi regardé mongodb, mais leur fonction" Groupe () "a des limitations graves autant que je puisse lire (max de 10 000 rangées)." "- Utilisez m / r à la place!
Est-ce que la seule requête que vous voulez faire sur vos données? Je vous suggérerai de vous organiser de manière différente de vos données, vous pouvez les stocker déjà dans le formulaire souhaité. Le sujet ici n'est pas si NOSQL peut faire la requête que vous avez à l'esprit, mais changer de votre esprit pour vous adapter à la philosophie Nosql. Changez le schéma et vous n'aurez plus besoin de grouper par ...
@Alor Un utilisateur serait de préférence capable de filtrer sur n'importe quelle dimension et de choisir de dire jusqu'à 5 dimensions max (sur 30, incl. Dimensions de temps). Je suppose que vous suggérez de générer des clés pour toutes les combinaisons (triées) des valeurs de dimension, puis des valeurs contiennent tous les compteurs métriques pour chacun? Si je devais éviter de regrouper, alors que 1 enregistrement est mis à jour, ce qui contient les valeurs de 30 dimensions, je devrais mettre à jour 174 436 compteurs (tous ont une longueur maximale de la touche 5 valeurs de dimension). Combien de temps faudrait-il (à peu près) pour mettre à jour que de nombreux compteurs à MongoDB ou à Cassandra?