Je voudrais passer de la valeur à l'approche clé approche SQL, parce que je traite « gros volumes de données » et souhaite bénéficier de systèmes tels que DynamoDB, Riak ou Cassandra.SQL à Key Value
C'est assez facile quand les données ne sont pas liées, donc on a une approche basée sur les documents (une clé primaire + des données, mais pas de relations).
J'apprécierais toute contribution théorique ou académique sur la façon de modéliser mes données.
J'ai utilisé NoSQL au cours des 4 dernières années et c'est exactement ce que je pense, ce que j'ai appris ... mes règles d'or personnelles.
Prémisse: dans le monde SQL toute relation possible entre les données, tout problème ou situation à traiter viennent souvent avec une réponse précise donnée à la fois par l'âge et "unicité" du produit - les gens provenant de cette "parfaite world "essayez de regarder le no-sql de la même manière, mais ici tout problème peut avoir de nombreuses solutions (ou pas de solutions) basées à la fois sur les besoins de l'application et sur le produit que vous utilisez.
Réfléchissez aux requêtes avant d'écrire le modèle. Le terme « axé sur requête » correspondent pas vraiment au contexte - aller en profondeur avec l'analyse, plus vous en savez sur la façon dont vous interrogez vos données, le meilleur sera le résultat
dénormaliser. Ne pensez pas à "une table possède certaines données" mais plutôt à "une table répond à quelques questions". - afin que vos données (ou un sous-ensemble différent de vos données) puissent être répétées dans différentes tables. C'est la norme et un moyen d'éviter les jointures et les relations
C'est implicitement une extension du premier 2: ne pensez pas que "les moins de tables feront le meilleur design" - plus sont les requêtes et probablement plus seront les tables
Étudiez votre produit - Chaque système offre des fonctionnalités différentes - certaines d'entre elles vous offriront un «tri des données» gratuitement, d'autres peuvent offrir des collections, des rappels, des déclencheurs, etc. le modèle pourrait être assez différent d'un produit à l'autre
Traitez avec vos besoins et possibilités - parfois vous devrez choisir, par exemple, si c le traitement d'une nouvelle table avec des données triées ou triées différemment du côté de votre client de données. Il n'y a pas de bonne réponse. Si vous avez peu d'espace disque ou de données à trier sont de petits ensembles, vous pouvez choisir un moyen, si vous avez peu de «puissance de calcul», mieux vaut choisir l'autre
Rappelez-vous que NoSQL ne signifie pas «Pas de SQL "mais" Non seulement SQL ".Vous pouvez aussi imaginer votre schéma comme un hybride (je pense que https://mariadb.org/ offre ce genre de solution) ou de se rappeler que vous pouvez mettre une couche de Hive/Shark/porc pour effectuer « requêtes back-end » plus complexes
Si vous choisissez Cassandra, après avoir étudié un peu le produit, donner un coup d'oeil ici:
HTH, Carlo
Quelle est la taille du "big data" pour vous? – peter