SQL DB + C# Performance
-
Hallo liebe Leute,
Problemstellung: 500.000+ Datensätze aus 5+ Tabellen aus der SAP-Datenbank müssen auf Windows-Plattform bearbeitet und ausgewertet werden.
**
Nun die Fragen**:
- Welche Sprache kommt eurer Meinung aus Performancegründen dafür in Frage? (Vorwissen spielt dabei keine bedeutende Rolle)- Für die interne Verarbeitung sind auf die schnelle zweit Optionen angedacht: einerseits die Verarbeitung über Objekte (jeder Datensatz ein Objekt) oder die Verarbeitung mit Hilfe einer SQL DB für Zwischentabellen - welche wäre aus der Performancebrille zu bevorzugen?
Mein momentaner Favorit ist C#.
Your thoughts?
-
Äh.
Kommt drauf an. Wenn die "Verarbeitung" komplett über Joins und dergleichen in SQL erfolgen kann (also OHNE Cursor zu verwenden), dann direkt in SQL. Entweder gleich auf dem SQL Server wo SAP drauf zugreift (in der TempDB oder einer extra dafür angelegten, was auch immer), oder halt auf einem extra Server.Wenn man damit nicht auskommt, dann Daten "runterladen", verarbeiten, und wieder hoch laden. C# wahrscheinlich nich ganz verkehrt, da es in ADO .NET wenigstens einen brauchbaren Support für Buld-Upload (Bulk-Insert) gibt. Bei 500.000 Datensätzen würde das sonst reichlich lange dauern die "Stück für Stück" hochzuladen (ein COMMIT pro Datensatz -> laaaaangsam).
Wenn Updates zu machen sind dann auch so, Daten runterladen, verarbeiten, hochladen (INSERT in Temp-Table), und dann das Update mit einer einzigen Query machen (UPDATE mit Join bzw. Sub-Selects).
EDIT: ich meine natürlich eine einzige Query pro Table, aber ich hoffe das war auch so klar /EDIT
Was die Verarbeitung über Objekte angeht: mal überschlagsmässig checken ob sich das mit dem Speicher ausgeht. Angenommen es soll auf einem 32 Bit System laufen, und alle Datensätzen sollen im Speicher sein, dann darf ein solches Objekt max. 2G/500K = 4K gross sein (inklusive allem Overhead natürlich). In Wirklichkeit natürlich kleiner, da der GC auch etwas freien Speicher braucht, die ganzen Usermode DLLs noch wegkommen etc. Also vielleicht eher 0,5 bis 1K. Das klingt noch realistisch, wenn die Tabelle nicht viele oder lange Strings enthält. Ist aber die Frage ob es bei 500K Datensätzen bleibt. Und dann wirds recht schnell eng.
Wenn die Daten Stück für Stück verarbeitet werden können ist das natürlich egal.
Ansonsten, nochmal zurück zur Sprache... sollte eigentlich egal sein, solange ihr das was ihr machen wollt damit gut machen könnt, und es ein brauchbares DB-Interface gibt.
-
Was hustbaer geschrieben hat Unterscheibe ich ohne Vorbehalt.
Dazusagen möchte ich aber noch das 500000 Rows ja nichts ist.
Es kommt darauf an was du für eine Verarbeitungszeit erwartest, ob das nur einmal passieren soll u.s.w.Insbesondere sind es ja ROWS aus unterschiedlichen Tabellen.
Wenn das Design gut ist dann gibt es keine Probleme. Egal welche Sprache.
Wir haben DB`s mit mehreren Millionen Rows welche sekündlich durchgearbeitet werden müssen.
Mit einem Pentium 200 und 100MB speicher ist es natürlich schon ein Problem.
Wir haben dafür z.B. SELECT-Server (MSSQL 2005) welche Daten liefern . Ein andere ist für INSERT zuständig damit die sich nicht in die Quere kommen.
Weiters natürlich ein GB-NETZ den die Daten müssen ja auch zum Programm der alles verarbeiten soll. Mit einem 10mBit Ring schau es da auch schlecht aus.
Wie du siehst braucht man für eine Analyse auch viele Parameter welche du nicht geliefert hast. Insbesondere was RDBMS betrifft.
-
Dazusagen möchte ich aber noch das 500000 Rows ja nichts ist.
Das erinnert mich ein wenig an Elektroniker -> Elektriker -> Starkstromelektriker ;o)
-
Vielen Dank hustbaer für deine hilfreiche Antwort.
@unix-tom: Mir ist durchaus bewusst, dass ich einige Parameter nicht bedachte habe, daher wende ich mich hier auch an die erfahrenen Leute
Deine angesprochenen Parameter folgen in kürze.Schonmal danke für den Input
