Wann sollte ich die Verwendung von Sql Azure und Wann sollte ich die Tabelle Speicher?

Wann sollte ich die Verwendung von Sql Azure und Wann sollte ich die Tabelle Speicher?
Ich dachte , verwenden Sie die Tabelle Speicher für Transaktions-Verarbeitung Szenarien, z.B. debit-Kredit-Konten Art von Szenario und Sql Azure, wenn die Daten nicht verwendet werden für transaktionale Zwecke.e.g die Berichterstattung.
Was denkst du?

InformationsquelleAutor Allan Rwakatungu | 2011-02-08
  1. 65

    Dies ist eine ausgezeichnete Frage und eine, die härter und härter, um reverse-Entscheidungen, die Lösung, die Architekten haben, um bei der Gestaltung für Azure.

    Gibt es mehrere Dimensionen zu berücksichtigen:
    Auf der negativen Seite, SQL Azure ist relativ teuer für gigabyte Speicherplatz, nicht skaliert super gut und ist beschränkt auf 150gigs/Datenbank
    allerdings, und das ist sehr wichtig, es gibt keine Transaktions-Gebühren gegen SQL Azure und Ihre Entwickler, die bereits wissen, wie man code dafür.

    ATS ist ein anderes Tier alle zusammen. In der Lage mega-Skalierbarkeit, es ist Schmutz Billig zu speichern, aber wird teuer auf den Häufig zugegriffen wird. Es erfordert auch eine erhebliche Menge an CPU-Leistung von Ihrem Knoten zu manipulieren. Es ist im Grunde zwingt die compute-Knoten werden mini-db-Server als die delegation von allen relationalen Aktivität richtet sich auf Sie.

    Also, meiner Meinung nach, auf die Häufig zugegriffen Daten, die nicht braucht enorme Skalierbarkeit und ist nicht super groß sein sollte, bestimmt für SQL Azure, sonst Azure Table Services.

    Ihre konkreten Beispiel -, Transaktions-Daten von Finanz-Transaktionen ist der perfekte Ort für ATS, während die meta-Informationen (Benutzerkonten, - Namen, - Adressen, etc.) ist perfekt für SQL Azure.

    • wie transaktionale Daten von Finanz-Transaktionen ist perfekte für die ATS wenn die ATS nur die Unterstützung von Transaktionen in die gleiche partition key? , Die mich umhauen...
    • Weil "Transaktionen" bedeutet, verschiedene Dinge. Eine Transaktion im Falle von finanziellen Transaktion bedeutet, dass ein Datensatz, in der Erwägung, dass in Bezug auf ATS Unterstützung von Transaktionen bedeutet es, dass das ganze speichern wird entweder gelingen oder fehlschlagen.
    • Sie sagen "große Skalierbarkeit". Wie groß ist das große? Es sind noch ein paar zahlen verglichen werden?
    • Überprüfen Sie diesen link: blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/... - untere Abschnitt enthält Skalierbarkeit Ziele
    InformationsquelleAutor Igorek
  2. 31

    Igor und Mark gab gute Antworten. Lassen Sie mich hinzufügen, nur ein bisschen mehr...

    Mit SQL-Datenbank (früher SQL Azure), Sie können nun Datenbanken bis zu 500 GB. Um darüber hinaus gehen, müssten Sie Ihre partition Daten. Hinweis: Ursprünglich schlug ich vor Scherben mit SQL-Verbände, aber dieses feature ist seitdem im Ruhestand.

    ATS bietet Transaktionen an der partitions-Ebene (entity group transactions). Sehen in diesem MSDN-Artikel für weitere Informationen. Dieser ist nicht so robust wie Azure SQL-Transaktionen, aber es erlaubt für batch-Operationen in einer einzigen Transaktion.

    BEARBEITEN ist Es schon über ein Jahr her, seit die Frage gestellt (und beantwortet). Ein Vergleich wurde auf die Preisbildung. Während SQL Azure ist immer noch teurer als die ATS, die Kosten von SQL Azure ist deutlich gesunken im vergangenen Jahr. Die Datenbanken jetzt haben gestaffelte Preise, beginnend bei $4,99 für 100 MB, Erhöhung auf $225 für 150GB (einen großen Tropfen von der $9.99 /GB Preise vom letzten Jahr. Alle Preisinformationen sind hier.

    BEARBEITEN Aug 2014 ein Weiteres Jahr später ein weiteres update. Während web - /business-Schichten bestehen, sind Sie sunsetted (und SQL-Verbände ist nicht mehr verfügbar). Die neue Basic -, Standard-und Premium-Ebenen sind jetzt verfügbar (siehe hier für details).

    • +1 auf die Aktualisierung mit neueren Daten.
    InformationsquelleAutor David Makogon
  3. 17

    Einige dieser Antworten scheinen nicht vollständig, so werde ich hinzufügen, meine 2 cents.

    Azure-Tabelle ist Gut, Punkte:

    • Stärke ist seine Fähigkeit zum speichern von vielen kleinen Daten; - Azure-Tabelle basiert auf der Azure-Blob, sondern orientiert sich an kleinere Daten
    • Viel billiger als Azure-SQL-Server
    • Wenn Sie wissen, beide den partition key und den row-key, der Zugriff auf Daten ist sehr schnell.
    • Entity transactions sind möglich, wenn Sie zwei verschiedene "Schemata" in der gleichen partition-Taste.
    • Wo die gesamte Zeile Größe ist WENIGER ALS 980K (SQL-Zeile)
    • Wo jede Eigenschaft ist WENIGER ALS 64 Kb (SQL-Spalte)
    • Es kann als ein armer Mann ist SQL.

    Azure-Tabelle schlechte Punkte:

    • SQL ist der schwache Punkt. Erwarten Sie nicht, verwenden Sie dies auf einem großen SQL-Tabelle oder Sie wird in performance-Problemen leiden.
    • Eingeschränkte SQL verfügbar ist, nicht erwarten, dass Verknüpfungen jeglicher Art, außer dem, was Sie implementieren, Linq
    • Azure SQL-Tabelle nicht so gut skalieren wie seine Fähigkeit, eine unendliche Menge von Daten
    • Wenn Sie nicht angeben, sowohl eine partition key und Zeile Schlüssel in einer WHERE-Klausel, erwarten eine langsame Scannen der Tabelle auftreten
    • Erwarten table scan-Leistung verschlechtern, wie Sie weitere Zeilen hinzufügen
    • Nicht erwarten, dass Azue Tabelle Abfragen werden schnell, wie Sie weitere Zeilen hinzufügen
    • Bottom line, wenn Sie mit Azure-Tabelle handeln, wie SQL nicht hinzufügen, Unmengen von Daten. Wenn Sie viele Daten (GB), nicht nur planen immer high-performance-SQL-Abfragen. Sie werden Geld sparen, wenn Sie nicht brauchen diese regelmäßige SQL-features.
    InformationsquelleAutor TLDR
  4. 10

    Wenn es um Transaktionen, es ist gerade anders herum: SQL Azure unterstützt Transaktionen; table storage nicht.

    SQL Azure ist im Grunde Ausführung von SQL Server in Windows Azure, also, wenn Sie ein bestehenden Anwendung, verwendet SQL Server, SQL Azure bietet eine guten Migrationspfad. Allerdings gibt es auch Grenzen auf, wie groß eine Datenbank auf SQL Azure (derzeit 150 GB), so gibt es Grenzen, wie viel es skaliert werden kann.

    Tabelle Speicher, auf der anderen Seite, ist extrem skalierbar, erfordert aber eine andere Art des Denkens. Es ist keine relationale Datenbank. Siehe z.B. dieser Artikel für eine nette Einführung: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

    • Ich Rede von Transaktionen in einer Weise, die Microsoft bezieht sich auf Sie: der Zugriff auf die Daten werden als eine Transaktion in der Azure Abrechnung Bedingungen. ATS unterstützt Transaktionen, wenn auch in etwas beschränkter Weise wie David schon angedeutet.
    InformationsquelleAutor Mark Seemann
  5. 3

    Die richtige Antwort ist, "Versuchen wirklich schwer, nicht zu verwenden, Azure Table Storage". Immer dann, wenn Sie aus einer relationalen DB zu einer no-sql-Datenbank, sind Sie natürlich gehen zu müssen, zu ändern, wie Sie denken über Ihre storage-Architektur. Aber die Probleme mit den ATS gehen weit über einfach nur brauchen, um "anders denken". Andere Leute haben darauf hingewiesen, dass es nicht nur eine "No-SQL" Daten-speichern, ist es ein besonders verkrüppelte, Behinderte, und sehr-low-featured Instanz einer No-SQL-Speicher. Es geht nicht darum, dass man "anders denken" über ATS; es ist eine Frage, die der ATS nicht zu geben Ihnen die Werkzeuge, die Sie für Ihre Arbeit benötigen - tools, die andere nicht-sql-Daten speichert tun geben Sie.

    Über die einzige Sache, die gut über ATS ist, dass Sie können sehr viele Daten in kürzester Zeit und mit minimalen Lagerkosten. Jedoch, Sie können grundsätzlich nicht die Hoffnung zu bekommen, dass die Daten wieder heraus, es sei denn, Sie Glück genug, um ein use-case, der magisch entspricht dem Partition-Key/Row-Key storage-Modell. Wenn Sie nicht - und ich vermute, dass nur sehr wenige Menschen tun - Sie gehen zu tun eine Menge von partition durchsucht, und die Verarbeitung der Daten selbst.

    Darüber hinaus, Azure Table Storage zu sein scheint in eine Sackgasse in der Entwicklung. Wenn man sich die "Unterstützung Sekundäre Indizes" Anfrage auf die Azure-feedback-Foren (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), Sie können sehen, dass die Unterstützung für Sekundäre Indizes versprochen wurde so weit zurück wie 2011, aber keine Fortschritte erzielt. Noch hat keine Fortschritte gemacht worden, auf einem der anderen top-Anforderungen für die Tabelle Speicher.

    Nun, ich weiß, dass Scott Guthrie ist eine Qualität Kerl, also meine Hoffnung ist, dass alle diese stagnation auf dem Tisch Storage front ist ein Vorwort zu Azure zu fixieren, und kommen mit etwas wirklich cool. Ich hoffe (obwohl ich habe null Beweise das der Fall ist). Aber für jetzt, es sei denn, Sie haben nicht die Wahl, würde ich dringend empfehlen, gegen Azure Table Storage. Verwenden Sie Azure SQL; verwenden Sie Ihre eigene Instanz von MongoDB oder einige andere Nicht-SQL-DB; oder die Nutzung von Amazon DynamoDB. Aber don ' T verwenden Sie Azure Table Storage.

    • Ist diese Empfehlung noch gültig im Nov 2017 nach den Verbesserungen, die sich aus den ATS ?
    • Ich glaube, meine Meinung ist immer noch gültig, da habe ich nicht wirklich gesehen erhebliche Verbesserungen der jeder Geschmack ATS richtige (lassen Sie mich wissen, wenn ich was übersehen habe-spezifisch). Es ist eine weitere damit zusammenhängende Möglichkeit, nämlich Kosmos DB, die die Fähigkeit hat, zu "handeln" wie die ATS über die Tisch-API (docs.microsoft.com/en-us/azure/cosmos-db/table-introduction), aber mit einer viel besseren Satz von Funktionen. Natürlich, ich könnte mir vorstellen, dass der Preis wie Kosmos DB und nicht wie ATS. Aber wenn Sie beginnen, frisch und wollen eine Azure-native option ist, würde ich einfach gehen mit nativen Kosmos-DB - (oder Azure-SQL).
    • vielen Dank für die Beratung... CosmosDB ist offenbar ziemlich teuer im Vergleich zu ATS.. ich werde bewerten Optionen weiter und fahren Sie Fort.
    InformationsquelleAutor Ken Smith
Schreibe einen Kommentar