IM Rédigez une application «Preuve de concept» pour étudier la possibilité de déplacer un système de commerce électronique sur mesure ASP.NET à Windows Azure au cours d'une réécriture nécessaire de l'application complète.
Je suis tenté de regarder en utilisant le stockage de la table Azure comme alternative à SQL Azure, car les entités étant stockées sont susceptibles de modifier leur schéma (propriétés) au fil du temps, car l'application mûrit plus loin et je n'ai pas besoin de faire des changements de schéma de base de données sans fin. . De plus, nous pouvons construire une intégrité réafférentielle dans le code applicateur - de sorte que le cas d'envisage de stockage de table azur est une forte.
Le seul problème potentiel que je puisse voir à ce moment-là est que nous faisons une petite quantité de rapports simples - c'est-à-dire la valeur des ventes entre deux dates, nombre d'articles vendus pour un produit particulier, etc. Je sais que le stockage de la table ne prend pas en charge les fonctions de type agrégat, et je pense que nous pouvons atteindre ce que nous voulons avec une utilisation intelligente des partitions, plusieurs types d'entités pour stocker des sous-ensembles des mêmes données et éventuellement pré-agrégation, mais je ne suis pas sûr à 100% sur la manière de Allez-y.
Est-ce que quelqu'un connaît des documents approfondis sur les principes de conception de stockage de la table Azure afin de faire une utilisation appropriée et efficace des tables, des partitions et des conceptions d'entité, etc.
Il y a quelques documents simplistes autour, et les livres actuels disponibles ont tendance à ne pas aller sur ce sujet de manière beaucoup en profondeur.
FYI - Le site du commerce électronique compte environ 25 000 clients et prend environ 100 000 commandes par an.
4 Réponses :
Je pense qu'il y a trois problèmes potentiels, je pense à porter votre application pour le stockage de table.
Honnêtement, je pense une approche hybride - peut-être EF ou NH à SQL Azure pour les données critiques, avec de grands objets stockés dans la table / blob?
Assez de mon avis! Pour "en profondeur":
Super conseil - Merci, mais j'étais vraiment après des conseils sur où obtenir des informations plus approfondies sur la conception d'une stratégie de partitionKey / entité pour atténuer l'inconvénient de passer à un SGBD non relationnel
Merci Dean - J'ai ajouté un point supplémentaire sur Azurescope - mais cela ne vous aidera toujours pas vraiment avec vos conseils "Meilleures pratiques pour l'utilisation des affaires". Presque tous les conseils que j'ai vus sur les meilleures pratiques sont vraiment venus au niveau "Performance" - par ex. Comment concevoir vos clés afin d'éviter les points chauds. À un niveau pratique, j'ai trouvé un défi de concevoir des applications à l'aide d'un stockage juste azur - l'absence de tout type d'indexation secondaire (par exemple, la carte-réduite de Ravendb) rend le magasin d'entité clé assez difficile à utiliser efficacement. Vous pouvez dupliquer les données, mais vous vous retrouvez avec des problèmes de transaction.
Si vous commencez à examiner le stockage Azure telle que la table, il ne ferait aucun mal à regarder d'autres offres NOSQL sur le marché (en particulier autour des bases de données de documents). Cela vous donnerait un aperçu de l'espace NOSQL et la solution autour de ces stockages sont conçues. Vous pouvez également penser à une approche hybride de la solution SQL DB + NOSQL. Les parties du système peuvent très bien se prêter au modèle de stockage de table Azure. Les solutions NOSQL telles que la table Azure ont leurs propres défis tels que
Avez-vous vu ce post? HTTP: //blogs.msdn.com/b/windowsazureStorage/archive/2010/11/06/how-to-get-might-Out-Of-Windows-AZURE-TABLE.ASPX
Couverture assez approfondie des tables
Tous les documents de conception de la table que j'ai vus sont à peu près exclusivement concentrés sur les sujets d'évolutivité et de performances de recherche. Je n'ai rien vu liée à des considérations de conception pour la déclaration ou la BI.
Maintenant, les tables d'azur sont accessibles via des API de repos et via le SDK Azure. Selon les rapports dont vous avez besoin, vous pourrez peut-être retirer les informations dont vous avez besoin avec un minimum d'effort. Si vos exigences de rapport sont très sophistiquées, alors SQL Azure avec Windows Azure SQL Signaling Services pourrait être une meilleure option à prendre en compte?