Große Datenmengen über 32 Bit ODBC

Hallo zusammen,

Ich hab ein Problem. Und zwar muss ich größere Datenmengen (mehrere Gigabyte) verarbeiten..

Das Problem, ich habe nur einen 32 Bit ODBC Treiber zur Verfügung. Somit werd ich OutOfMemoryException schnell begegnen..

Ich habe mir gedacht, zur Verarbeitung könnte ich ein 64 Bit Applikation erstellen und zur Datenbeschaffung ein 32 Bit Applikation..

Jedoch würde ich dann trotzdem das Problem noch haben, wenn ich eine Tabelle lese, die eine gewisse größe hat.. Natürlich könnte man diese dann "splitten". Aber das müsste man dann ja irgendwo definieren, da das Programm nicht weiß, ist die Tabelle jetzt zu groß? Jedoch definieren, wann er was splitten soll, ist auch nicht grad die tollste Methode! Und das Programm gegen ne Exception laufen lassen und dann zu splitten bis zur nächsten Exception etc, wäre ja absolut Performance-schädigend..

Noch ne andere Idee, wäre über irgendeine Schnittstelle zwischen den Programme, einfach vom 32 Bit ins 64 Bit die Rows zu schieben..

Vielleicht hattet ihr damit schonmal Probleme und irgendwelche Lösungsvorschläge! 😃

Gruß,

Raphael

Somit werd ich OutOfMemoryException schnell begegnen..

Warum? Was meinst du mit Verarbeiten? Wenn du eine Batchverarbeitung meinst, ist es kein Problem. Der Treiber cached nicht alle Daten und du hoffentlich auch nicht. Wenn du keine Batchverarbeitung hast, sondern wirklich alle Daten gleichzeitig haben willst, dann denk lieber nochmal drüber nach, ob du sie wirklich gleichzeitig haben willst.

Ich brauche wirkliche alle Daten, da Sie öfter als 1 mal gebraucht werden. Und Sie jedesmal erneut zu laden, würde nur mehr Zeit kosten!

Dann wirst Du früher oder später auch 128 Bit vorraussetzen statt nur 64 Bit.
Vergiss das komplette Laden von Datenbanken; es gibt immer einen anderen, und besseren Weg.

Wenn Du genau erzählst was Du vorhast, kann man Dir evtl andere Wege empfehlen.
Ebenfalls interessant wäre zu wissen, welche Datenbank Du nutzt, damit es unbedingt via ODBC laufen muss.

Also ein Beispiel

Ich habe:

Tabelle X
-ID
-Status
-Saison
-WertX

Tabelle Y
-ID
-WertY

Das Programm soll dann mit diesen Tabelle "rechnen"

Zum Beispiel, Average über X.WertX wo X.Saison = 2011Q1/2 und Y.WertY > 100

Natürlich könnte man dies über SQL in der Datenbank machen. Jedoch kann diese Datenbank nicht gerade sehr viel und außerdem brauche ich gewisse Tabellen öfter (5-10x) dadurch denke ich temporäres speichern wäre sinnvoll.

Die "roh" Daten kommen aus einer Datenbank (Progress OpenEdge - SQL-92, leider wie gesagt nur 32Bit ODBC)

Hi,

die Fa. OpenLink bietat auch einen ADO .NET Provider für OpenEdge (Progress) an: http://uda.openlinksw.com/dotnet-progress-mt/
Ich denke, der Zugriff wird auch bedeutend schneller als mittels ODBC sein.

Es macht auf jeden Fall wesentlich mehr Sinn, sowas von der Datenbank erledigen zu lassen und nicht selber. Wenn die Datenbank das nicht kann, kannst dir die Datenbank auch sparen. Dein Beispiel schaut jetzt auch überhaupt nicht kompliziert aus, bist du sicher, dass die Datenbank das nicht kann? Kann sein, dass es bei Progress etwas anders funktioniert, hatte mit deren Produkten nicht viel zu tun, fand das alles aber recht gewöhnungsbedürftig.
Aber selbst wenn du alle Daten mit SELECT * FROM Table holst, reicht auch ein 32 Bit Treiber. Du musst die Daten ja trotzdem selber cachen in deinem Programm, der Treiber schiebt sie nur durch. Aber so wie ich das sehe, versuchst du selber eine Datenbank nachzubauen, obwohl du schon eine benutzt, und davon kann ich nur nochmals abraten.

Nein, ich möchte nicht eine eigene Datenbank schreiben. Ich möchte lediglich die Daten verarbeiten. Mit Ihnen rechnen. Und dazu ist die vorhandene Datenbank einfach veraltet und auch nicht gerade die performanteste..

Und natürlich kann ich alles durch den ODBC Treiber jagen, dennoch bin ich eben auf 32 Bit auch beim Programm eingeschränkt und somit wenn mir der ODBC Treiber mehrere Gigabyte in mein Programm jagt, dann jagt mein Programm gegen die nächste OutOfMemoryException 😃

Kann Dir mit einer 64Bit Anwendung genauso passieren.
Aber - eigentlich - sollte Windows flexibel genug sein und die Auslagerungsdatei mit nutzen.

Trotzdem ist Dein Vorhaben mehr als fragwürdig.
Du beschwerst Dich über eine nicht performante Datenbank, schreibst aber eine Anwendung, die gezielt mehrere Gigabyte in den Speicher jagt.. und beschwerst Dich zudem über einen reglementierten Speicher. Einen Tod musst sterben - aber Du hast hier gegenläufige Anforderungen.

Naja bei einer 64 Bit Anwendung wären die Grenzen des Speichers ja hoch genug.

Und wer sagt Dir, dass nicht ein anderer mit seiner Applikation auf die selbe "tolle" Idee kam, und den Speicher bereits belegt, wenn Du Deine komplette Datenbank in den Speicher lädst?
Wer sagt Dir überhaupt, dass die Ressourcen, ganz egal ob 32Bit oder 64Bit des aktuellen PCs dafür ausreichen?

Irgendwie hast Du nicht zu Ende gedacht 😉

1. Ich lade nicht die komplete Datenbank in den Speicher.
2. Ich denke diese Diskussion läuft jetzt in die falsche Richtung und da es in nichts konstruktivem endet, bitte ich den Thread zu schließen.

Danke trotzdem 😃

Ich habe mir gedacht, zur Verarbeitung könnte ich ein 64 Bit Applikation erstellen und zur Datenbeschaffung ein 32 Bit Applikation..

Wenn du dein Problem unbedingt auf diese Weise lösen willst, kannst es schon so machen, hast ja die Lösung selber vorgeschlagen. Du könntest eine Art Client-Server Architektur aufbauen. Dabei wäre ein Programm 32 bittg und würde die Daten an das 64 Bit Programm weiterreichen. Das sollte kein Problem sein. Ich habs ja schon im ersten Post geschrieben, so lange weder du noch der Treiber die Daten cached, ist die Größe kein Problem. Und wenn dein 32 Bit Programm die Daten nur an das 64 Bit Programm durchschiebt, sollte es funktionieren.

Wäre da eine WCF Client-Server Architektur von Vorteil? Denn das wäre ja relativ schnell realisiert.

Als Binding netNamedPipeBinding, da es wahrscheinlich auf dem gleichen Rechner läuft und als TransferMode Streamed?

Aber Streamed wäre ja nur nützlich sofern man auch einen Stream hat..

Jedoch ODBC macht ja keinen Stream... 😕 Ne Idee? 😃

Irgendwie musst du die Daten natürlich serialisieren. Das kommt auch drauf an, was du übertragen willst, und wie häufig sich das ändert.
Ich würde sowas wahrscheinlich so performant wie möglich realisieren wollen. Wahrscheinlich einfache DTO Klassen für die Objekte definieren und sie möglichst einfach über WCF oder .NET Remoting rüberschieben.

Ihr wollt aber nicht ernsthaft vorschlagen "mehrere Gigabyte"

1. zu serialisieren
2. noch über das Netzwerk zu jagen und dann
3. dafür auch noch .NET Remoting zu verwenden und
4. wieder zu deserialisieren

?

Wieviele Stunden soll denn der Benutzer bereit sein, auf die Daten zu warten ?
Da ist es meiner Meinung nach schneller, die Tabellen lieber 10 mal direkt neu zu laden...

Da ist es meiner Meinung nach schneller, die Tabellen lieber 10 mal direkt neu zu laden...

Da ist was allerdings was dran...

Wie wäre es, mit einer WCF Architektur

Server - 32 Bit -> Bei Aufruf liest der gewisse Tabellen und schreibt diese in Dateien.

Client - 64 Bit -> Ruft Server auf und wartet bis Server fertig und bekommt als Antwort den Datei-Namen der Tabelle um diesen einlesen zu können..

Aber dann würd man immernoch serialisieren.. Da kommt man wohl nicht rum oder?

Wenn Du auch noch das Dateisystem mit ins Spiel bringst; arg viel unperformanter geht's dann wirklich nicht mehr 😉

Sagt wer? Schonmal was von SSD gehört? HDD war gestern 😉

Auch SSDs sind im Gesamtsystem betrachtet die wohl "langsamste" Komponente, egal ob SSD, HDD, Flash-Laufwerke, Flash-Schnittstellen.. deswegen habe ich auch Dateisystem und nicht HDD geschrieben 🙄
Ob nun 170MB oder 100MB schreiben macht bei der Übertragung von mehreren GB übers Netzwerk beim Projekt "wie schaffe ich es möglichst unperformant mit der DB zu agieren" kein Unterschied 😉

Ich liebe solche konstruktiven Moderatoren.

Wenn du nichts konstruktives zu sagen hast, dann lass es.

Ich denke, das beste wäre für dich jetzt einfach, das ganze mal auszuprobieren. In Dateien würde ich die Daten erstmal nicht schreiben, wenn du sie eh komplett im Speicher haben willst. Da kanst die Daten auch direkt durchschieben. Viel Aufwand ist es nicht, das mal auszuprobieren. Dann kannst ja sehen, ob du mit der Performance zufrieden bist, oder nicht. Bei solchen Batcherverarbeitungen ist die Geschwindigkeit meist eh nebensächlich.