Hash table mit dynamischen arrays - effizienz

Hallo,

ich habe folgendes Problem und zwar möchte ich eine Hash-table
erzeugen, in der dynamische Arrays enthalt sind. Ich habe das ganze
mal mit folgendem Code ausprobiert:

my %Hash;
my @arr =3D (7,'Hallo');
my @arr2 =3D (78,'Hallo', 'and');
$Hash{'1'} =3D \@arr;
$Hash{'2'} =3D \@arr2;

my $as =3D $Hash{'2'};
print scalar @$as;

Nun möchte ich z.B. in den Array in Hash{'2'} ein weiteres Element
einfügen. Wie kann ich denn sowas machen?

Ist diese Methode effizient? In den Hash müssen ca. 1,5 Mio Elemente
eingefügt werden. Die Arrays besetehen ca. jeweils aus 10 Elementen.
Bei den Elementen handelt es sich teilweise um String und teilweise um
Zahlen.

Viele Grüsse und danke für Eure Hilfen!
Anton

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:
> ich habe folgendes Problem und zwar möchte ich eine Hash-table
> erzeugen, in der dynamische Arrays enthalt sind. Ich habe das ganze
> mal mit folgendem Code ausprobiert:
>
> $Hash{'1'} = \@arr;
> $Hash{'2'} = \@arr2;
>
> my $as = $Hash{'2'};
> print scalar @$as;
>
> Nun möchte ich z.B. in den Array in Hash{'2'} ein weiteres Element
> einfügen. Wie kann ich denn sowas machen?

Wo einfügen? Vorne/hinten/mittig?
Für hinten:
push @$as, 'MeinElement';

> Ist diese Methode effizient? In den Hash müssen ca. 1,5 Mio Elemente
> eingefügt werden. Die Arrays besetehen ca. jeweils aus 10 Elementen.
> Bei den Elementen handelt es sich teilweise um String und teilweise um
> Zahlen.

Du solltest dann bei dem großen Hash, wenn du schon vorher weißt, dass
dort so viele Elemente drin sein werden, den Speicher vorher reservieren:
keys(%mein_riesen_hash)=1500000;

Bei solchen riesigen Datenmengen solltest du überlegen, ob nicht eine
andere Verarbeitungsweise günstiger ist.

Wolf

Re: Hash table mit dynamischen arrays - effizienz

Hallo,

Wolf Behrenhoff schrieb:
> Wo einfügen? Vorne/hinten/mittig?
> Für hinten:
> push @$as, 'MeinElement';
Egal, was am schnellsten geht.

>> Ist diese Methode effizient? In den Hash müssen ca. 1,5 Mio Elemente
>> eingefügt werden. Die Arrays besetehen ca. jeweils aus 10 Elementen.
>> Bei den Elementen handelt es sich teilweise um String und teilweise um
>> Zahlen.
>
> Du solltest dann bei dem großen Hash, wenn du schon vorher weißt, dass
> dort so viele Elemente drin sein werden, den Speicher vorher reservieren:
> keys(%mein_riesen_hash)=1500000;
>
> Bei solchen riesigen Datenmengen solltest du überlegen, ob nicht eine
> andere Verarbeitungsweise günstiger ist.
Welche könnte da besser sein?

Mein Problem ist das folgende: Ich habe eine Tabelle in Oracle. In
dieser Tabelle sind ca. 1,5 Millionen Datensätze enthalten, wobei jeder
Datensatz aus ca. 350 Feldern besteht. Von diesen 350 Feldern sind
derzeit ca. 250 bei allen Datensätzen leer; ca. 10 sind relativ häufig
befüllt und der Rest auch nur sehr spärlich.
Aus den Daten der Tabelle, die ungleich null sind wird nun mittels Perl
eine XML-Datei generiert.
Derzeit wird ein Full-Table-Scan über die gesamte Tabelle durchgeführt
und dann mittels einer Schleife alle Elemente durchgeschleift, wobei
immer nur die zum Schreiben vorgehalten werden, die ungleich null sind.
Dieser Schreibeprozess benötigt auf einem extrem leistungsfähigen System
über 1,5h, was ich ziemlich lang finde für die Erstellung einer
XML-Datei mit letztlich "nur" 350MB.
Nun habe ich mir überlegt 350 Select Aufrufe von jeweils nur einer
Spalte zu machen (zusammen mit dem Primary Key der Tabelle) und die
Daten schrittweise in eine Hash-Tabelle zu schreiben, d.h. der Schlüssel
der Hash-Tabelle ist jeweils der Primary-Key der Datenbank-Tabelle.

Habt Ihr eine Idee wie ich mein Problem zu einer Lösung führen könnte?

Viele Grüße,
Anton

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg wrote:

> Habt Ihr eine Idee wie ich mein Problem zu einer Lösung führen könnte?

Stelle erstmal fest, was wie lange dauert:

1) Transfer sämtlicher Daten in das Programm (ohne Verarbeitung)
2) Aufbau der Datenstruktur
3) Zusammensuchen der Daten aus der Datenstruktur
4) Schreiben der Daten auf die Datei

Dann kann man ehesten sehen, wo eine Optimierung ansetzen sollte.
Du hast es anscheinend mit einem völlig deformierten
Datenmodell zu tun. Vermutlich müsste man das schon ganz anders
auslegen, wollte man an die Ursache gehen.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Hash table mit dynamischen arrays - effizienz

Hi,

Frank Seitz schrieb:
> Stelle erstmal fest, was wie lange dauert:
>
> 1) Transfer sämtlicher Daten in das Programm (ohne Verarbeitung)
Wenn Du hiermit meinst, dass die Daten mittels eines fetchrow aus dem
zuvor aufgerufenen SQL-Statement in die "verbundenen" Variablen
übertragen werden, dann liegt hier definitiv der Hauptteil der
Verarbeitung, da ja über eine halbe Milliarde mal eine Schleife
durchlaufen wird... und ca. 1,5 Mio mal fetch-row aufgerfuden wird
(genauer: fetchrow_hashref). Ich habe das mal für 20.000 Datensätze
getestet. Ca. 10% gehen drauf für das konvertieren in XML-Format und das
Schreiben in die Datei. 90% für die fetchrow-hashref-Aufrufe. Da wir
auch andere Tabellen haben, die 1,5 Mio Datensätze haben und dort die
Verarbeitung in pasabler Zeit abläuft, können 1,5 Mio Datensätze nicht
das Problem sein. Das Problem entsteht letztlich erst durch die 350
Spalten, die zu über 70% nicht gefüllt sind.

> 2) Aufbau der Datenstruktur
> 3) Zusammensuchen der Daten aus der Datenstruktur
> 4) Schreiben der Daten auf die Datei
Wenn ich Deine Aufgliederung richtig deute nehmen diese Schritte nur ca.
10% der Zeit in Anspruch.

>
> Dann kann man ehesten sehen, wo eine Optimierung ansetzen sollte.
> Du hast es anscheinend mit einem völlig deformierten
> Datenmodell zu tun. Vermutlich müsste man das schon ganz anders
> auslegen, wollte man an die Ursache gehen.
Das Datenbankmodell kann man nicht ändern und wenn man alle Details
kennt macht es auch grundsätzlich etwas Sinn (Verifizierbarkeit,
Sicherheit, etc.) ;)

Grüsse,
Anton

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:

> Mein Problem ist das folgende: Ich habe eine Tabelle in Oracle. In
> dieser Tabelle sind ca. 1,5 Millionen Datensätze enthalten, wobei jeder
> Datensatz aus ca. 350 Feldern besteht. Von diesen 350 Feldern sind
> derzeit ca. 250 bei allen Datensätzen leer; ca. 10 sind relativ häufig
> befüllt und der Rest auch nur sehr spärlich.
> Aus den Daten der Tabelle, die ungleich null sind wird nun mittels Perl
> eine XML-Datei generiert.
> Derzeit wird ein Full-Table-Scan über die gesamte Tabelle durchgeführt
> und dann mittels einer Schleife alle Elemente durchgeschleift, wobei
> immer nur die zum Schreiben vorgehalten werden, die ungleich null sind.
> Dieser Schreibeprozess benötigt auf einem extrem leistungsfähigen System
> über 1,5h, was ich ziemlich lang finde für die Erstellung einer
> XML-Datei mit letztlich "nur" 350MB.

Eine Hash-Table sollte für dein Problem eigentlich schon funktionieren. Da
dort ohnehin nur Referenzen auf die Daten gespeichert werden, nicht die
Daten selbst, spielt es für die Hash-Table keine Rolle, was da alles
dranhängt.

Bei derart miserabler Performance liegt dein Problem möglicherweise sonstwo.
Hast du sichergestellt, dass dein System nie ins Swappen kommt? Ist dein
Algorithmus über jeden Zweifel erhaben? Wie lange dauert es, wenn du nur
15'000 oder auf 150'000 Datensätze verarbeitest?

Wäre es eventuell denkbar, dass die Daten beim lesen direkt verarbeiten und
dann wieder ausgeben würdest, ohne sie zuvor alle zu speichern? Oder wäre
es denkbar, Teile deiner Verarbeitungsroutinen von Perl auf SQL auszulagern
und die Datenbank machen zu lassen?

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://albasani.net/cgiirc/irc.cgi

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg wrote:
>
> Wenn Du hiermit meinst, dass die Daten mittels eines fetchrow aus dem
> zuvor aufgerufenen SQL-Statement in die "verbundenen" Variablen
> übertragen werden, dann liegt hier definitiv der Hauptteil der
> Verarbeitung, da ja über eine halbe Milliarde mal eine Schleife
> durchlaufen wird...

Wieso iterierst Du über die 350 Attribute?

> und ca. 1,5 Mio mal fetch-row aufgerfuden wird
> (genauer: fetchrow_hashref).

Ein fetchrow_arrayref() ist effizienter, wenn Du
den Datensatz ohnehin gleich wegwirfst.

> Das Problem entsteht letztlich erst durch die 350
> Spalten, die zu über 70% nicht gefüllt sind.

Selektionen mit vielen Spalten werden bei Oracle sehr langsam.
350 Kolumnen in einer Tabelle ist extrem viel.
Ich hatte mir schon gedacht, dass da die meiste Zeit draufgeht.
Dann hast Du aber letztlich kein Perl-Problem. Frage doch
mal in de.comp.database.misc, ob Du durch geschicktes
Selektieren (wie Du es selbst schon angedacht hast)
oder mittels anderer Datenbank-Kniffe die Sache
effizienter gestalten kannst.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:
> Hallo,
>
> ich habe folgendes Problem und zwar möchte ich eine Hash-table
> erzeugen, in der dynamische Arrays enthalt sind.

> $Hash{'1'} = \@arr;
> $Hash{'2'} = \@arr2;

Mir fällt gerade noch was ein:
Ist dein Primary Key Integer? Dann könntest du ja auch ein Array of
Array nehmen. Oder gibt es zu viele Zahlen zwischendrin nicht? Mir
erschließt sich der Sinn des Hashes noch nicht. Wie ich dich verstanden
habe, selektierst du ja eh alles. Demnach könntest du doch jedes
fetchrow in ein fortlaufendes Array eintragen und nicht den Hash nutzen.

Wolf

Re: Hash table mit dynamischen arrays - effizienz

Hallo,

Wolf Behrenhoff schrieb:
> Anton Berg schrieb:
>> Hallo,
>>
>> ich habe folgendes Problem und zwar möchte ich eine Hash-table
>> erzeugen, in der dynamische Arrays enthalt sind.
>
>> $Hash{'1'} = \@arr;
>> $Hash{'2'} = \@arr2;
>
> Mir fällt gerade noch was ein:
> Ist dein Primary Key Integer? Dann könntest du ja auch ein Array of
Nein, ist er leider nicht.

> Array nehmen. Oder gibt es zu viele Zahlen zwischendrin nicht? Mir
> erschließt sich der Sinn des Hashes noch nicht. Wie ich dich verstanden
Der Sinn des Hashes ist folgender (zumindest meiner Meinung nach):
Ich selektiere spaltenweise, d.h. zuerst den Primarykey mit der ersten
nicht key-spalte, dann mit der zweiten nicht key-spalte usw. Hierbei
selektiere ich immer nur jeweils die Werte, die in der nicht-key spalte
ungleich null sind, d.h. in etwa:
select key_spalte, nicht_key_spalte_1 from riesige_tabelle where
nicht_key_spalte_1 is not null;
select key_spalte, nicht_key_spalte_2 from riesige_tabelle where
nicht_key_spalte_2 is not null;

Diese SQL-Statements führe ich für alle Spalten aus. In ca. 250 der
Fälle bekomme ich als Ergebnis die leere Menge, d.h. muss keine weiteren
Schritte ausführen. Bei ca. 90% der Restlichen bekomme ich eine kleine
Ergebnismenge <50.000 (wobei viele kleiner 1000 sind) und bei den
restlichen bekomme ich im Millionener-Bereich.

Nun laufe ich die Ergebnismenge durch und greife jeweils über den
primary-key auf das Element in der Hash-Tabelle zu und aktualisiere dort
schrittweise die Werte, die ich aus der Tabelle herausgelesen habe.
Da ich Spaltenweise vorgehe, benötige ich einen schnellen Zugriff auf
die einzelnen Elemente in der Hash-Tabelle (da ich ja nur die Elemente
ungleich null selektiere, weiß ich nicht wieviele Elemente zwischen der
vorherigen und der aktuellen Null liegen).

> habe, selektierst du ja eh alles. Demnach könntest du doch jedes
> fetchrow in ein fortlaufendes Array eintragen und nicht den Hash nutzen.
Grundsätzlich könnte ich das (und hier habe ich was nicht detailliert
genug erläutert). Dies geht jedoch nicht, da ich zusätzlich für die
XML-Datei auch noch den Spaltennamen brauche. Ich wollte daher in dem
Array, den ich in dem Hash-Array schreibe, folgende Struktur ablegen:
Spaltenname1 Spaltenwert1 Spaltenname2 Spaltenwert2 ....

Natürlich verdoppelt das die Größe, aber im Vergleich zur jetztigen
Lösung wo ca. 500.000.000 Felder in DB umsonst selektiert werden, spielt
das glaube ich nicht so eine große Rolle.

Grüsse,
Anton

>
> Wolf

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg wrote:

> Ich selektiere spaltenweise, d.h. zuerst den Primarykey mit der ersten
> nicht key-spalte, dann mit der zweiten nicht key-spalte usw. Hierbei
> selektiere ich immer nur jeweils die Werte, die in der nicht-key spalte
> ungleich null sind, d.h. in etwa:
> select key_spalte, nicht_key_spalte_1 from riesige_tabelle where
> nicht_key_spalte_1 is not null;
> select key_spalte, nicht_key_spalte_2 from riesige_tabelle where
> nicht_key_spalte_2 is not null;

Also 350 Full-Table-Scans über 1,5 Mio. Datensätzen?

> Diese SQL-Statements führe ich für alle Spalten aus. In ca. 250 der
> Fälle bekomme ich als Ergebnis die leere Menge, d.h. muss keine weiteren
> Schritte ausführen.

D.h. von den 350 Tabellenspalten sind 250 generell leer?
Warum lässt Du diese dann nicht einfach weg?
Eine Selektion über "nur" 100 Kolumnen wäre schonmal
eine deutliche Optimierung.

Mich würde mal interessieren, was inhaltlich in dieser
Mammuttabelle (was die Breite betrifft) drinsteht.
Ich kann mir nicht vorstellen, dass das
gut modelliert ist.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:

>> Array nehmen. Oder gibt es zu viele Zahlen zwischendrin nicht? Mir
>> erschließt sich der Sinn des Hashes noch nicht. Wie ich dich verstanden
> Der Sinn des Hashes ist folgender (zumindest meiner Meinung nach):
> Ich selektiere spaltenweise, d.h. zuerst den Primarykey mit der ersten
> nicht key-spalte, dann mit der zweiten nicht key-spalte usw. Hierbei
> selektiere ich immer nur jeweils die Werte, die in der nicht-key spalte
> ungleich null sind, d.h. in etwa:
> select key_spalte, nicht_key_spalte_1 from riesige_tabelle where
> nicht_key_spalte_1 is not null;
> select key_spalte, nicht_key_spalte_2 from riesige_tabelle where
> nicht_key_spalte_2 is not null;
>
> Diese SQL-Statements führe ich für alle Spalten aus. In ca. 250 der
> Fälle bekomme ich als Ergebnis die leere Menge, d.h. muss keine weiteren
> Schritte ausführen. Bei ca. 90% der Restlichen bekomme ich eine kleine
> Ergebnismenge <50.000 (wobei viele kleiner 1000 sind) und bei den
> restlichen bekomme ich im Millionener-Bereich.

Das erscheint mir extrem ineffizient. Ich gehe mal davon aus, dass du auf
die meisten Spalten keinen Index gesetzt hast. Dein SQL-Server wird
vermutlich des öfteren viel Zeit damit verbraten, um festzustellen, dass er
nichts zurückgeben muss (d.h. durch die ganze Tabelle laufen und jeden Wert
darauf prüfen, ob er nicht null ist).

Wäre es auch denkbar, die ganze Tabelle mit einem einzigen Select auszulesen
und dann jeden eingelesenen Datensatz fortlaufend zu verarbeiten und gleich
auszugeben, ohne ihn weiter zu speichern? Das wäre möglicherweise
effizienter.

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://albasani.net/cgiirc/irc.cgi

Re: Hash table mit dynamischen arrays - effizienz

Roman Racine schrieb:
> Anton Berg schrieb:
>
> Das erscheint mir extrem ineffizient. Ich gehe mal davon aus, dass du auf
> die meisten Spalten keinen Index gesetzt hast. Dein SQL-Server wird
> vermutlich des öfteren viel Zeit damit verbraten, um festzustellen, dass er
> nichts zurückgeben muss (d.h. durch die ganze Tabelle laufen und jeden Wert
> darauf prüfen, ob er nicht null ist).
>
> Wäre es auch denkbar, die ganze Tabelle mit einem einzigen Select auszulesen
> und dann jeden eingelesenen Datensatz fortlaufend zu verarbeiten und gleich
> auszugeben, ohne ihn weiter zu speichern? Das wäre möglicherweise
> effizienter.
Ja, so wird das ja im Moment gemacht: Ein großer: select * from
riesige_tabelle
und dann die gesamte Rückgabe-Menge von ca. 750 Mio Elementen
durchgehen, obwohl von diesne tasächlich nur ca. 15 Mio gebraucht werden.

>
> Gruss
>
> Roman°

Re: Hash table mit dynamischen arrays - effizienz

Frank Seitz schrieb:
> Anton Berg wrote:
>
>> Ich selektiere spaltenweise, d.h. zuerst den Primarykey mit der ersten
>> nicht key-spalte, dann mit der zweiten nicht key-spalte usw. Hierbei
>> selektiere ich immer nur jeweils die Werte, die in der nicht-key spalte
>> ungleich null sind, d.h. in etwa:
>> select key_spalte, nicht_key_spalte_1 from riesige_tabelle where
>> nicht_key_spalte_1 is not null;
>> select key_spalte, nicht_key_spalte_2 from riesige_tabelle where
>> nicht_key_spalte_2 is not null;
>
> Also 350 Full-Table-Scans über 1,5 Mio. Datensätzen?
Ja, das war ja auch nur so eine Idee. Ich habe das mal getestet. Für das
Aufrufen der SQL-Statements ohne Verarbeitung der Ergebnisse hat das
System 25 Minuten gebraucht. Ich bin da allerdings noch nicht mittels
fetch die einzelnen Ergebnisse durchgegangen.

>
>> Diese SQL-Statements führe ich für alle Spalten aus. In ca. 250 der
>> Fälle bekomme ich als Ergebnis die leere Menge, d.h. muss keine
weiteren
>> Schritte ausführen.
>
> D.h. von den 350 Tabellenspalten sind 250 generell leer?
> Warum lässt Du diese dann nicht einfach weg?
> Eine Selektion über "nur" 100 Kolumnen wäre schonmal
> eine deutliche Optimierung.
Jo, das wäre eine super Optimierung, aber diese 250 Spalten sind eben
nicht generell leer. Die Befüllung wechselt. Es sind jedoch immer mehr
als 70% der Kolumnen leer. Dies wechselt jedoch von Tag zu Tag.

>
> Mich würde mal interessieren, was inhaltlich in dieser
> Mammuttabelle (was die Breite betrifft) drinsteht.
> Ich kann mir nicht vorstellen, dass das
> gut modelliert ist.
Gute Modellierung ist das nicht, aber das Modell macht aus vielerlei
Hinsicht großen Sinn (Security, Verifizierbarkeit, usw.). Abgesehen
davon habe ich keine Möglichkeit etwas an der Modellierung der Tabelle
zu ändern.

Möglicherweise muss ich mich einfach damit abfinden, dass man es nicht
performant machen kann.

Grüsse,
Anton

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:

> Roman Racine schrieb:
>> Anton Berg schrieb:
>>
>> Das erscheint mir extrem ineffizient. Ich gehe mal davon aus, dass du auf
>> die meisten Spalten keinen Index gesetzt hast. Dein SQL-Server wird
>> vermutlich des öfteren viel Zeit damit verbraten, um festzustellen, dass
>> er nichts zurückgeben muss (d.h. durch die ganze Tabelle laufen und jeden
>> Wert darauf prüfen, ob er nicht null ist).
>>
>> Wäre es auch denkbar, die ganze Tabelle mit einem einzigen Select
>> auszulesen und dann jeden eingelesenen Datensatz fortlaufend zu
>> verarbeiten und gleich auszugeben, ohne ihn weiter zu speichern? Das wäre
>> möglicherweise effizienter.
> Ja, so wird das ja im Moment gemacht: Ein großer: select * from
> riesige_tabelle
> und dann die gesamte Rückgabe-Menge von ca. 750 Mio Elementen
> durchgehen, obwohl von diesne tasächlich nur ca. 15 Mio gebraucht werden.

Naja, das wird vermutlich die effizienteste Lösung sein, wenn du an der
Datenbank selbst nichts schrauben kannst. Interessant wäre deine Idee, wenn
du verhindern könntest, dass du für jedes der 350 Queries einmal durch die
ganze Tabelle laufen musst. Vielleicht wäre das Anlegen von Indizes eine
Möglichkeit.

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://albasani.net/cgiirc/irc.cgi

Re: Hash table mit dynamischen arrays - effizienz

Roman Racine schrieb:
> Naja, das wird vermutlich die effizienteste Lösung sein, wenn du an der
> Datenbank selbst nichts schrauben kannst. Interessant wäre deine Idee, wenn
> du verhindern könntest, dass du für jedes der 350 Queries einmal durch die
> ganze Tabelle laufen musst.
Hast Du eine Idee, wie das gehen könnte?
Ich dachte, dass wenn Oracle das macht, sprich mir eine kleinere
Ergebnismenge zurückliefert, dann mit Sicherheit das gesamte effizienter
macht, als wenn ich Perl das Iterieren durch die 750 Mio Datensätze
machen lasse.

Ich werde morgen früh mal weiter draüber nachdenken. Aber danke schonmal
für Eure Hilfen.

Gute Nacht,
Anton

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg schrieb:

> Roman Racine schrieb:
> > Naja, das wird vermutlich die effizienteste Lösung sein, wenn du an
> > der
>> Datenbank selbst nichts schrauben kannst. Interessant wäre deine Idee,
>> wenn du verhindern könntest, dass du für jedes der 350 Queries einmal
>> durch die ganze Tabelle laufen musst.
> Hast Du eine Idee, wie das gehen könnte?
> Ich dachte, dass wenn Oracle das macht, sprich mir eine kleinere
> Ergebnismenge zurückliefert, dann mit Sicherheit das gesamte effizienter
> macht, als wenn ich Perl das Iterieren durch die 750 Mio Datensätze
> machen lasse.

Naja, was du jetzt tun willst, ist ja eigentlich nichts anderes als 350 mal
durch eine Spalte der Tabelle gehen und nach jedem Durchgang einen Join
durchzuführen (d.h. die Ergebnisse der neuen Spalte zu den bisherigen
Ergebnissen joinen). Es wäre vermutlich effizienter, wenn du das komplett
auf der DB tun würdest, anstatt es in Perl nachzuprogrammieren. (Evtl. in
passender Gruppe fragen, wie man das mit deiner DB effizient tun kann.)

Wesentlich was einsparen könntest du, wenn du nicht in jeder Spalte suchen
müsstest, ob irgendwo ein Eintrag steht, beispielsweise über Indizes oder
über eine zweite Tabelle, in der Information darüber verwaltet wird, in
welchen Spalten sich Einträge befinden. Dann wärst du die ca. 200 Spalten,
in denen nichts steht, in ein paar Sekunden los.

Dann könntest du entweder spaltenweise vorgehen, so wie du das vorschlägst,
oder im Select-Statement nur noch die Spalten auswählen, in denen auch was
drinsteht und dann zeilenweise vorgehen oder einen Mix von beiden Varianten
wählen.

Da solltest du in einer passenden DB-Gruppe nachfragen, wie man deine
Tabelle optimieren kann.

Gruss

Roman°
--
IRC-Freenode: #usenet-friends
http://albasani.net/cgiirc/irc.cgi

Re: Hash table mit dynamischen arrays - effizienz

Anton Berg wrote:

> Mein Problem ist das folgende: Ich habe eine Tabelle in Oracle. In
> dieser Tabelle sind ca. 1,5 Millionen Datensätze enthalten, wobei jeder
> Datensatz aus ca. 350 Feldern besteht. Von diesen 350 Feldern sind
> derzeit ca. 250 bei allen Datensätzen leer; ca. 10 sind relativ häufig
> befüllt und der Rest auch nur sehr spärlich.

Das hört sich nicht unbedingt nach dem besten denkbaren Datenbankdesign an.

Re: Hash table mit dynamischen arrays - effizienz

Hi,

>
> Da solltest du in einer passenden DB-Gruppe nachfragen, wie man deine
> Tabelle optimieren kann.
Mache gerade einen Test mit einer Idee, die ich gerstern Nacht noch
hatte und jetzt nach ca. 1/3 der Arbeitszeit, sieht es gut aus
(möglicherweise könnte ich die Hälfte der Zeit einsparen).

Ich bin dabei folgendermaßen vorgegangen:
Ich habe einen großen SQL-Statement erzeugt, der mir die Anzahl von
Elementen in der DB zählt, also sowas wie:
select count(spalte1), count(spalte2), count(spalte2), count(spalte2)
... from riesige_tabelle
und dann wähle ich nur die Spalten aus, die ein Ergebnis ungleich null
zurückgeliefert haben und führe folgendes SQL-Statement aus:
select spalte1, spalte3, .... from riesige_tabelle
wobei hier wirklich nur die Spalten ausgewählt werden, die _nicht_
leer sind.

Bisher dauerts noch an... der Test ist jetzt erst zu gut 50% fertig.