2010-06-29 10 views
5

Der Grund, warum ich diese Frage stelle, ist, weil wir A LOT (mehrere GB) von Daten aus einer SQL Server-Datenbank zu einer .Net-App für die Verarbeitung zu lesen planen. Ich würde gerne wissen, wie viel Speicherplatzaufwand für jede Aufzeichnung berechnet werden muss, um die Auswirkungen auf unseren Netzwerkverkehr abzuschätzen.In welchem ​​Format werden SQL Server-Daten serialisiert, wenn sie über das Netzwerk gesendet werden?

z. Ein Datensatz besteht aus 5 ganzen Zahlen (was 4 * 5 = 20 Datenbytes ergibt). Wie viele Bytes werden pro Datensatz physisch übertragen? Gibt es eine genaue Formel oder eine Faustregel?

+0

Tatsächlich, wenn Sie 5 int übertragen, erhalten Sie 8092 Bytes übertragen - immer. SQL Server ist in Seiten von 8K organisiert - Sie werden nie weniger als einen 8K-Block bekommen. –

+0

@marc_s: Denkst du über IO und Gedächtnis? – gbn

+0

@gbn: das - plus, wenn Sie ein unglückliches Layout haben, können Sie 4100 Bytes Ihrer 8K-Seite verwenden, und damit haben Sie fast 50% "locker"/leeren Raum, der bei jedem Anruf mitkommt. –

Antwort

10

SQL Server verwendet TDS protocol. Und MSDN

Ehrlich gesagt, würde ich mich nicht darum sorgen. GBs von Daten dauert Zeit egal wie es ist leider getan.

+0

Danke, der MSDN-Link zu "Tabular Data Stream Protocol Specification" ist wirklich hilfreich (obwohl es mit 154 Seiten ziemlich erschöpfend ist!) – Manu

4

Ich habe keine Ahnung über das tatsächliche Format, aber ich würde einen empirischen Ansatz vorschlagen und Wireshark anschließen und die Daten selbst messen.

+0

Dies ist ein hilfreicher Kommentar, keine Antwort. – Manu

+0

@Manu - Laut Chris 'Antwort ist ein Netzwerk eine komplexe Interaktion vieler Systeme. Es wäre also unmöglich, anhand einer Protokollspezifikation genau zu bestimmen, wie Ihre spezifische Implementierung reagieren wird. Wenn Sie etwas messen, erhalten Sie echte Welt gegen theoretische Zahlen und irgendwann müssen Sie das Netzwerk messen, um alle Annahmen, die Sie in Ihrem Design treffen, zu validieren. –

4

Wie Peter M sagte, testen Sie es.

Es gibt keine wirklich genug Berechnung, die Sie ausführen können, die Ihnen genug Informationen geben wird, um abzuarbeiten.

Die Realität ist, dass es zu viele Variablen zu berücksichtigen gibt. Zum Beispiel:

Mit welcher tatsächlichen Rate wird die Übertragung der NIC durchgeführt? Beachten Sie, dass diese Rate davon abhängt, welche Netzwerkkarten vorhanden sind und welche DRIVER diese Karten verwenden. Sie könnten ganz leicht eine 1-GB-Karte haben, die aufgrund von Treiberproblemen nur bei etwa 300 MB übertragen werden kann. Ich habe sogar zwei Karten des gleichen Herstellers mit den gleichen Treibern gesehen, die aufgrund eines leichten Konfigurationsunterschieds in einer der Karten unterschiedliche Übertragungsgeschwindigkeiten haben.

Welche anderen Geräte befinden sich zwischen den beiden fraglichen Maschinen? Abhängig von der Hardware, Betriebssystemen usw., können Sie sehr unterschiedliche Zahlen sehen. Ein 8-Port-1-Gb-Unmanaged-Switch mit 8 Ports von TRENDNet wird einen völlig anderen Durchsatz haben als ein Cisco-Managed-Switch mit 5000-Gb.

Sie müssen auch das bestehende Netzwerk „Wetter“ zum Zeitpunkt der Übertragung überlegen, was der Durchsatz von anderem Netzwerkverkehr über die gleichen Leitungen, die diese teilen. Dies wird ein vorübergehender Faktor sein, da sich die vorhandene Netzwerklast ändert, wenn unterschiedliche Anforderungen an sie gestellt werden.

Zusätzlich unterstützen einige TCP-Offloading, andere nicht. Wenn Ihre NICs nicht wirksam sind, wird die effektive Übertragungsrate durch die CPUs dieser Boxen beeinträchtigt.

Als nächstes müssen Festplatten in Betracht gezogen werden. Wenn man bedenkt, dass es sich um eine große Datenmenge handelt, werden sich die Lese- und Schreibgeschwindigkeiten der verschiedenen Festplatten auswirken. Sicher, das Netzwerk könnte tatsächlich mit 90% Effizienz laufen, aber wenn Sie große Datenmengen sprechen, könnten die Festplatten selbst nicht in der Lage sein, mithalten zu können und deshalb auf einen Wirkungsgrad von 25% oder weniger abfallen.

Punkt ist, haben Sie es zu testen und am Ende des Tages, das Protokoll, das Server verwendet SQL wird auf Ihre Erkenntnisse immateriell sein. Und führen Sie nicht nur einen Test, führen Sie einen Los von realen Tests. Nur dann werden Sie in der Lage sein, einen Durchschnitt zu erzielen; was immer noch aus ist, abhängig davon, was sonst gerade passiert, aber du solltest in der Lage sein, innerhalb von etwa 10% zu kommen.

+0

Letzte Anmerkung, die Sie vielleicht zu diesem Beitrag lesen möchten: http://www.codinghorror.com/ blog/2005/07/gigabit-ethernet-und-back-of-the-envelope-rechnungen.html – NotMe

0

Aus meinen Beobachtungen führen Standard-SQL-Befehle viele Round-Trips. Um viele Daten zu übertragen, hilft es, wenn Sie eine Tabelle hochladen können. Dann können Sie den Massenkopiervorgang verwenden, der viel effizienter ist. Siehe: Bulk Copy Operations in SQL Server (ADO.NET) und bcp Utility.

+0

Bulk-Copy-Operationen sind nur relevant, wenn auf sql-Server geschrieben wird, nicht, wenn Daten davon gelesen werden – Manu

+0

@Manu: Ja. Der Unterschied in der Leistung beim Schreiben ist riesig. Aber ich habe auch beim Lesen beträchtliche Beschleunigungen gesehen. Ich schätze, das hängt von deinem Szenario ab. –

0

Eigentlich ist das TDS-Protokoll ein extrem langsames Protokoll. SQL Server ist für die Verarbeitung von Daten optimiert, nicht für die Verwaltung von mehreren Tonnen an Daten. Während der Repräsentationsaufwand nicht groß ist, macht die Tatsache, dass es sich um ein Anfrage-Antwort-Protokoll handelt, und das Fehlen von Boxcaring im Vergleich zu dediziertem High-Throughput-Protokoll sogar innerhalb von SQL Server (wie die Database Mirroring- oder Service Broker-Protokolle) sehr langsam. Aber auch wenn TDS so langsam ist, wie es ist, wird ein SQL Server, der mit voller Geschwindigkeit durch eine TDS-Leitung schießt, Ihren .Net-Client garantiert überlasten.

Wenn Sie jemals eine Frage wie die von Ihnen gestellt stellen, bedeutet das, dass Sie es falsch machen.

Verwandte Themen