Wann sollte ich SQL Azure verwenden und wann sollte ich Tabellenspeicher verwenden?

Wann sollte ich SQL Azure verwenden und wann sollte ich Tabellenspeicher verwenden? Ich dachte, verwenden Sie Tabellenspeicher für Transaktionsverarbeitungsszenarien, z. B. Debit-Guthabenkonten, und verwenden Sie SQL Azure, wenn Daten nicht für Transaktionszwecke verwendet werden, z. B. Berichterstellung. Was denken Sie?

Dies ist eine hervorragende Frage und eine der schwierigeren und schwieriger umkehrbaren Entscheidungen, die Lösungsarchitekten beim Entwerfen für Azure treffen müssen.

Es sind mehrere Dimensionen zu berücksichtigen: Auf der negativen Seite ist SQL Azure für Gigabyte Speicher relativ teuer, lässt sich nicht besonders gut skalieren und ist auf 150 GB / Datenbank beschränkt. Dies ist jedoch sehr wichtig, da für SQL keine Transaktionsgebühren anfallen Azure und Ihre Entwickler wissen bereits, wie man dagegen programmiert.

ATS ist insgesamt ein anderes Tier. Es ist mega-skalierbar, spottbillig zu lagern, aber häufig zugänglich. Für die Manipulation ist außerdem eine erhebliche Menge an CPU-Leistung von Ihren Knoten erforderlich. Grundsätzlich werden Ihre Rechenknoten zu Mini-DB-Servern, da die Delegierung aller relationalen Aktivitäten an sie übergeben wird.

Meiner Meinung nach sollten Daten, auf die häufig zugegriffen wird und die keine große Skalierbarkeit erfordern und nicht sehr groß sind, für SQL Azure bestimmt sein, andernfalls für Azure Table Services.

Ihr spezielles Beispiel, Transaktionsdaten aus Finanztransaktionen, ist ein perfekter Ort für ATS, während Metainformationen (Kontoprofile, Namen, Adressen usw.) perfekt für SQL Azure sind.

Igor und Mark gaben großartige Antworten. Lassen Sie mich noch ein bisschen mehr hinzufügen ...

Mit SQL Database (früher SQL Azure genannt) können Sie jetzt Datenbanken mit bis zu 500 GB haben. Um darüber hinauszugehen, müssten Sie Ihre Daten partitionieren. Hinweis: Ursprünglich habe ich Shards mit SQL-Verbund vorgeschlagen, aber diese Funktion wurde inzwischen eingestellt.

ATS bietet Transaktionen auf Partitionsebene an (Entitätsgruppentransaktionen). Weitere Informationen finden Sie in diesem MSDN-Artikel . Dies ist nicht so robust wie SQL Azure-Transaktionen, ermöglicht jedoch Stapeloperationen in einer einzelnen Transaktion.

BEARBEITEN Es ist über ein Jahr her, seit diese Frage gestellt (und beantwortet) wurde. Ein Vergleichspunkt war die Preisgestaltung. Während SQL Azure immer noch teurer als ATS ist, sind die Kosten für SQL Azure im vergangenen Jahr erheblich gesunken. Datenbanken haben jetzt gestaffelte Preise, beginnend bei 4,99 USD für 100 MB, und steigen auf 225 USD für 150 GB (ein großer Rückgang gegenüber den Preisen von 9,99 USD / GB im letzten Jahr. Die vollständigen Preisdetails finden Sie hier .

EDIT Aug 2014 Ein weiteres Jahr später ein weiteres Update. Während Web- / Business-Ebenen weiterhin bestehen, werden sie untergegangen (und SQL-Verbände sind nicht mehr verfügbar). Die neuen Basic, Standard und Premium - Reihen sind jetzt verfügbar (siehe hier für weitere Details).

Einige dieser Antworten scheinen nicht vollständig zu sein, daher füge ich meine 2 Cent hinzu.

Gute Punkte von Azure Table:

• Die Stärke ist die Fähigkeit, viele kleine Daten zu speichern. Die Azure-Tabelle basiert auf Azure Blob, ist jedoch auf kleinere Daten ausgerichtet
• Viel billiger als Azure SQL Server
• Immer wenn Sie sowohl den Partitionsschlüssel als auch den Zeilenschlüssel kennen, ist der Datenzugriff sehr schnell.
• Entity transactions sind möglich, wenn Sie zwei verschiedene "Schemas" im selben Partitionsschlüssel platzieren.
• Wenn die Gesamtzeilengröße WENIGER ALS 980 KB beträgt (SQL-Zeile)
• Wobei jede Eigenschaft WENIGER ALS 64 KB ist (SQL-Spalte)
• Es kann als SQL eines armen Mannes wirken.

Die schlechten Punkte der Azure-Tabelle:

• SQL ist die Schwachstelle. Erwarten Sie nicht, dies für eine große SQL-Tabelle zu verwenden, da sonst Leistungsprobleme auftreten.
• Es ist nur eingeschränktes SQL verfügbar. Erwarten Sie keine Verknüpfungen jeglicher Art, außer dem, was Sie in Linq implementieren
• Azure Table SQL lässt sich nicht so gut skalieren wie die Fähigkeit, unendlich viele Daten zu speichern
• Wenn Sie in einer WHERE-Klausel nicht sowohl einen Partitionsschlüssel als auch einen Zeilenschlüssel angeben, ist mit einem langsamen Tabellenscan zu rechnen
• Erwarten Sie, dass sich die Leistung beim Tabellenscan verschlechtert, wenn Sie weitere Zeilen hinzufügen
• Erwarten Sie nicht, dass Azue Table-Abfragen schnell sind, wenn Sie weitere Zeilen hinzufügen
• Fazit: Wenn Sie Azure Table verwenden, um sich wie SQL zu verhalten, fügen Sie nicht viele Daten hinzu. Wenn Sie viele Daten (Gigabyte) haben, planen Sie einfach nicht, leistungsstarke SQL-Abfragen zu erhalten. Sie sparen Geld, wenn Sie diese regulären SQL-Funktionen nicht benötigen.

Bei Transaktionen ist es genau umgekehrt: SQL Azure unterstützt Transaktionen. Tischspeicher nicht.

SQL Azure ist im Grunde ein SQL Server, der in Windows Azure ausgeführt wird. Wenn Sie also über eine vorhandene Anwendung verfügen , die SQL Server verwendet, bietet SQL Azure einen guten Migrationspfad . Die Größe einer Datenbank in SQL Azure (derzeit 150 GB) ist jedoch begrenzt. Daher kann die Skalierbarkeit begrenzt sein.

Die Speicherung von Tischen ist dagegen extrem skalierbar, erfordert jedoch eine andere Denkweise. Es ist keine relationale Datenbank . Eine gute Einführung finden Sie in diesem Artikel: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Die eigentliche Antwort lautet: "Versuchen Sie wirklich, Azure Table Storage nicht zu verwenden". Wenn Sie von einer relationalen Datenbank zu einer No-SQL-Datenbank wechseln, müssen Sie natürlich Ihre Meinung zu Ihrer Speicherarchitektur ändern. Aber die Probleme mit ATS gehen weit über die Notwendigkeit hinaus, "anders zu denken". Wie andere Leute bereits betont haben, handelt es sich nicht nur um einen "No-SQL" -Datenspeicher, sondern um eine besonders verkümmerte, behinderte und sehr leistungsschwache Instanz eines No-SQL-Speichers. Es geht nicht darum, über ATS "anders denken" zu müssen. es ist eine Frage von ATS nicht Ihnen die Werkzeuge , die Ihnen Ihre Arbeit tun müssen , um - Tools , die andere nicht-SQL - Datenspeicher haben Sie geben.

Das einzig Gute an ATS ist, dass Sie sehr schnell und mit minimalen Speichergebühren viele, viele Daten darin ablegen können. Grundsätzlich können Sie jedoch nicht hoffen, diese Daten wieder herauszubekommen, es sei denn, Sie haben das Glück, einen Anwendungsfall zu haben, der auf magische Weise dem Partitionsschlüssel- / Zeilenschlüssel-Speichermodell entspricht. Wenn Sie dies nicht tun - und ich vermute, dass es nur sehr wenige Menschen tun -, werden Sie viele Partitionsscans durchführen und die Daten selbst verarbeiten.

Darüber hinaus scheint sich Azure Table Storage in Bezug auf die Entwicklung in einer Sackgasse zu befinden. Wenn Sie sich die Anforderung "Sekundärindizes unterstützen" in den Azure-Feedback-Foren ansehen ( http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes ), sehen Sie diese Unterstützung für Bereits 2011 wurden Sekundärindizes versprochen, es wurden jedoch keine Fortschritte erzielt. Auch bei den anderen Top-Anforderungen für die Tabellenspeicherung wurden keine Fortschritte erzielt.

Jetzt weiß ich, dass Scott Guthrie ein guter Typ ist, und ich hoffe, dass all diese Stagnation auf dem Tischspeicher ein Vorwort zu Azure ist, um das Problem zu beheben und sich etwas wirklich Cooles auszudenken. Das ist meine Hoffnung (obwohl ich keine Beweise dafür habe). Im Moment würde ich Azure Table Storage dringend empfehlen, es sei denn, Sie haben keine Wahl. Verwenden Sie Azure SQL. Verwenden Sie Ihre eigene Instanz von MongoDB oder eine andere No-SQL-Datenbank. oder verwenden Sie Amazon DynamoDB. Verwenden Sie jedoch keinen Azure-Tabellenspeicher.