Magasins Key-Value vs. RDBM vs. & # 8220; Cloud & # 8221; DB (SDB) [fermé]

Question

Je suis à l'aise dans l'espace MySQL après avoir conçu plusieurs applications au cours des dernières années, puis perfectionné en permanence les aspects de performance et d'évolutivité. J'ai également une expérience de travail avec memcached pour fournir des accélérations côté application sur des jeux de résultats fréquemment interrogés. Et récemment, j'ai implémenté Amazon SDB en tant que ma "base de données" principale. pour une expérience de commerce électronique.

Pour simplifier à l'excès, j'ai rapidement décidé d'utiliser le service SDB: l'utilisation d'une structure de base de données sans schéma me permettait de me concentrer sur le problème logique de mon projet et d'accumuler rapidement du contenu dans mon magasin de données. . En d’autres termes, ne vous inquiétez pas de la configuration et de la normalisation préalable de toutes les permutations possibles des attributs d’un produit; commencez simplement à charger les produits et la SDB se souviendra simplement de tout ce qui est disponible.

Maintenant que j'ai réussi les premières itérations de mon projet et que je dois configurer des interfaces simples pour les données, je suis confronté à des problèmes que j'avais pris pour acquis en travaillant avec MySQL. Ex.: Regroupement dans des instructions select et limitation de la syntaxe pour interroger les "éléments 50 à 100". L’avantage en termes de facilité que j’ai obtenu en utilisant une architecture sans schéma de SDB, j’ai perdu face à un coup de performance consistant à interroger / mettre en boucle un jeu de résultats avec un peu plus de 1800 éléments.

Maintenant, je lis des articles sur des projets tels que Tokyo Cabinet, qui étend le concept de magasins de clé-valeur en mémoire afin de fournir une fonctionnalité pseudo-relationnelle à une vitesse ridiculement supérieure (14x je lis quelque part).

Ma question: Existe-t-il des consignes rudimentaires ou des méthodes heuristiques que je peux, en tant que concepteur / développeur d’application, évaluer quel technicien de base de données est le plus approprié à chaque étape de mon projet?

Ex: à une étape de prototypage où les inconnues logiques / techniques de l’application rendent la structure de données fluide: utilisez SDB. À une étape plus avancée, où les produits livrables par l'utilisateur sont une priorité, utilisez des outils traditionnels qui vous évitent de passer du temps à dev à écrire la logique de tri, de regroupement ou de pagination.

Une expérience pratique de ces outils serait très appréciée.

Merci beaucoup!

R. Shaheeb

Answer 1

Les nouvelles solutions ne sont pas des solutions miracles.

Comparés au SGBDR classique, ces systèmes apportent des améliorations dans certains aspects (évolutivité, disponibilité ou simplicité) par compromis (réduction de la capacité d'interrogation, uniformité éventuelle, performances horribles pour certaines opérations).

Ne les considérez pas comme des substituts de la base de données traditionnelle, mais comme des outils spécialisés répondant à un besoin spécifique et connu.

Prenons Amazon Simple DB, par exemple, SDB est en fait un énorme tableur. Si vos données ressemblent à cela, cela fonctionnera probablement bien, et l’extensibilité et la simplicité exceptionnelles vous feront gagner beaucoup de temps et d’argent.

Si votre système nécessite des requêtes très structurées et complexes, mais que vous insistez avec l'une de ces nouvelles solutions, vous vous retrouverez bientôt au milieu de la ré-implémentation d'un SGBDR amateur et mal conçu, avec tous ses problèmes inhérents.

À cet égard, si vous ne savez pas si cela répondra à vos besoins, je pense qu'il est préférable de faire vos premières itérations dans un SGBDR classique, car ils vous offrent la meilleure flexibilité et la meilleure capacité, en particulier dans le déploiement d'un serveur unique. et sous charge modeste. (voir Théorème du CAP ).

Une fois que vous avez une meilleure idée de l’affichage de vos données et de leur utilisation, vous pouvez faire correspondre vos besoins à une solution alternative.

Si vous voulez la simplicité d'une solution hébergée sur le cloud, mais avez besoin d'une base de données relationnelle, vous pouvez vérifier: Amazon Service de base de données relationnelle

Answer 2

Les problèmes que vous rencontrez sont la raison pour laquelle les spécialistes en SGBDR analysent certains des systèmes alternatifs d’un œil jaunâtre. Oui, les systèmes alternatifs gèrent extrêmement rapidement certaines exigences spécifiques, mais dès que vous voulez utiliser autre chose avec les mêmes données, le plus rapide des flottes devient le retardataire. En revanche, un SGBDR gère généralement les variations avec plus d'aplomb; ce n'est peut-être pas aussi rapide que le plus volumineux pour la charge de travail spécialisée que ce dernier est micro-optimisé pour gérer, mais il se détériore rarement aussi rapidement lorsqu'il est appelé à traiter d'autres requêtes.