Ich brauche Hilfe! Ich kann das Problem nicht lösen, ich stoße an die Grenzen der Hardware - Seite 6

 
YuraZ:

>>> Ich weiß nicht, wonach ich suche ...

>>> Sie müssen alle Sequenzenwiederholt durchgehen und einige Berechnungen durchführen.

Nun - ja - Suche - aber sie durchsucht 20 Gigabyte...

Im Prinzip basiert die Suche auf der Tatsache, dass es eine Suche und einen Vergleich gibt

Ich halte mich an das, was der Autor geschrieben hat.

Vielleicht können die Daten nicht verkleinert - komprimiert - indiziert werden


ist es logisch, die Daten in SQL zu speichern

Übergabe der Geschäftslogik an den Server + Daten

der Expert Advisor sendet nur kurze Daten zur Aufzählung und Berechnung an den Server

und erhalten eine fertige Antwort.

Die Suche mit roher Gewalt ist das Mittelalter.
 
Integer:

Oh, und ich bin von vielen Dingen hier beeindruckt.

Ich denke, dass sogar ein Kind in der Lage sein sollte, dies zu verstehen. Wenn ein Text mit einem Algorithmus komprimiert wird, ist er heute und morgen noch genau gleich.

Übrigens - 3 Terabyte wurden stundenlang von Server zu Server kopiert - Netzwerk von 1gb

bei der Komprimierung in ZIP wurden 3 Terabyte über einen Tag lang komprimiert

Wenn Sie das großartige Dienstprogramm LiteSpeed gekauft haben, das zunächst den Speicher des Servers komprimiert und dann Backups

Die Komprimierungszeit von 3 Terabyte wurde auf ein paar Stunden reduziert.

Auch das Auspacken (um etwas zu ändern oder zu löschen) dauert mehrere Stunden.


Das Lösen des Suchalgorithmus für komprimierte Daten ist cool!

vielleicht wird in Zukunft jemand Algorithmen entwickeln, um in bereits komprimierten Datenbanken nach Einfügungen und Löschungen zu suchen

... aber es gibt noch keine solchen Algorithmen im industriellen Maßstab


Es gibt industrielle Datenbanken von ORACL MS SQL niemand auf der Welt speichert Daten in komprimierter Form - wenn mit ihnen intensiv gearbeitet wird

 
YuraZ:

1. 3 Terabyte wurden übrigens mehrere Stunden lang von Server zu Server kopiert - 1gb Netzwerk

Bei der ZIP-Komprimierung haben wir über einen Tag gebraucht, um 3 Terabyte zu komprimieren.

Ich habe ein cooles Dienstprogramm namens LiteSpeed gekauft, das zuerst den Serverspeicher komprimiert und dann Backups

Die Komprimierungszeit von 3 Terabyte wurde auf ein paar Stunden reduziert.

Das Auspacken (um etwas zu ändern oder zu löschen) dauert ebenfalls ein paar Stunden.


2. Das Lösen des Suchalgorithmus für komprimierte Daten ist cool!

3. vielleicht wird in Zukunft jemand Algorithmen entwickeln, um in bereits komprimierten Datenbanken nach Einfügungen und Löschungen zu suchen

4. ... aber es gibt noch keine solchen Algorithmen im industriellen Maßstab


Es gibt industrielle ORACL MS SQL-Datenbanken, niemand auf der Welt speichert Daten in komprimierter Form - wenn man intensiv mit ihnen arbeitet

1. Bei der vorliegenden Aufgabe wird die Datenkomprimierung nur einmal durchgeführt, und es kann eine Woche dauern, bis die Daten komprimiert sind.

2) Was ist daran so cool?

3) Warum sollten wir etwas erfinden? Die Frage ist, ob Sie es brauchen oder nicht.

4. Und was, wenn nicht?

 
Integer:

1. Für die vorliegende Aufgabe ist die Datenkomprimierung einmalig, Sie können sie eine Woche lang durchführen.

2. was ist daran so cool?

3. was gibt es zu erfinden? Die Frage ist: Ist das notwendig oder nicht?

4. Und was, wenn nicht?

1) p1 erst nach Lösung von p4

2) na ja - ich weiß nicht, vielleicht ist die Frage(FAST) Suche in großen Datenmengen schon von genügend qualifizierten Fachleuten und mehr als einmal durchdacht worden - und bis jetzt kein Algorithmus

3) Weiß Gott - die Suche in komprimierten Daten mag erfunden sein, aber sie ist nicht gelöst, und höchstwahrscheinlich, weil sie einfach nicht gebraucht wird...

4) Vielleicht erfinden die besten Köpfe der Welt einen Algorithmus(FAST) zur Suche in komprimierten Daten

die Suche (LANGSAM) in komprimierten Daten ist möglich - mit einer Methodik (Dekomprimierung und anschließende Suche) ist das keine Frage...

 

Niemand spricht von der Suche in komprimierten Daten. Es geht um den Vergleich von zwei komprimierten Sequenzen.

Angenommen, ein Array, "aaa", "bbb", "vvvv". Jedes der drei Array-Elemente wird unabhängig von den anderen komprimiert. Angenommen, wir komprimieren und erhalten das Array "a", "b", "c".

Wir haben die gesuchte Zeichenkette "bbb", die wir in dem Array finden müssen. Vor der Suche komprimieren wir es und erhalten "b". Jetzt suchen und finden.

 
Integer:

Niemand spricht von der Suche in komprimierten Daten. Es geht um den Vergleich von zwei komprimierten Sequenzen.

Angenommen, ein Array, "aaa", "bbb", "vvvv". Jedes der drei Array-Elemente wird unabhängig von den anderen komprimiert. Angenommen, wir komprimieren und erhalten das Array "a", "b", "c".

Wir haben die gewünschte Zeichenkette "bbb", die wir in dem Array finden müssen. Vor der Suche komprimieren wir es und erhalten "b". Jetzt suchen und finden wir sie.

die Idee ist klar...

und dennoch ist diese Methodik (bei einer schnellen Suche) in den Datenbanken der Industrie nicht zu finden

es muss einen Grund geben

 
Integer:

Oh, und ich bin von vielen Dingen hier beeindruckt.

Ich denke, dass sogar ein Kind in der Lage sein sollte, dies zu verstehen. Wenn Sie einen Text mit einem Algorithmus komprimieren, wird er heute und morgen in komprimierter Form genau dasselbe sein.

Wollen Sie damit sagen, dass man mit demselben Komprimierungsalgorithmus und der Komprimierung zweier unterschiedlicher Texte zwei völlig identische Datensequenzen erhalten kann?

Wie kommen Sie darauf, dass ich das sage?

 
YuraZ:

die Idee ist klar...

und dennoch ist diese Methodik (mit einer schnellen Suche) nicht auf der Basis der Industrie verfügbar

muss es einen Grund geben.

Natürlich gibt es Gründe dafür :)

Bei der Datenkompression geht es um die Beseitigung von Redundanzen. Und je effizienter die Komprimierung erfolgt, desto geringer ist die Redundanz. Und die oben vorgeschlagene Suchmethode wird nicht funktionieren, weil in dem komprimierten Text jeder Teil vom gesamten Text abhängt.

 
Contender:

Natürlich gibt es dafür Gründe :)

Bei der Datenkompression geht es um die Beseitigung von Redundanzen. Und je effizienter die Komprimierung erfolgt, desto weniger Redundanz gibt es. Außerdem kann man mit der obigen Methode nicht suchen, da in einem komprimierten Text jeder Teil vom gesamten Text abhängt.

:-) das ist es, worüber wir reden ...
 
elugovoy:

Wie kommen Sie darauf, dass ich das sage?

Das ist eine Art Andeutung:

Die Komprimierung einer Textdatei ist 4-8 mal höher. Bedenken Sie, dass die Komprimierungsalgorithmen für jede Datei einen eigenen Transcodierungsbaum erstellen.

Mit anderen Worten, die Quelldatei hat einen Baum, aber der Teil der Daten, den Sie suchen, hat einen anderen Baum..

Ich frage mich nur, wie Sie vorschlagen zu suchen? auch theoretisch ))))

Wie man sucht, habe ich bereits geschrieben.