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

 

Ich versuche es noch einmal.

Wir haben drei Dateien.

1. L. Tolstoi. Krieg und Frieden, Band 1.

2. L. Tolstoi. Krieg und Frieden, Band 2.

3. F. Dostojewski. Verbrechen und Strafe.

Wir verpacken jeden von ihnen.

Wir haben drei gepackte Dateien ohne Namen (fragen Sie mich bloß nicht, wie ich mir eine Datei ohne Namen vorstelle). Wir haben auch eine nicht verpackte Datei, nämlich "Crime and Punishment".

Wie findet man diese Datei in den drei komprimierten Dateien am wirtschaftlichsten?

Option 1: Ich muss alle drei Dateien komprimieren und die gesuchte Datei finden.

Option 2. Komprimieren Sie die gesuchte Datei und finden Sie unter den drei komprimierten Dateien genau die gleiche Datei.

 
YuraZ:

Mm-hmm - also ist das, was Sie vorschlagen, nicht gut

Das war nicht mein Vorschlag. Auf jeden Fall ist es eine interessante Idee.
 
Integer:
Ja, ich weiß, wenn die Daten kurz sind, nimmt die Größe bei der Archivierung zu.

Wenn Sie in dieser Richtung weitermachen wollen, können Sie auch Hashing oder Prüfsummen für die Suche verwenden, Sie müssen keine Kompressionskodierung verwenden. Erstellen Sie einen Hash-Index und suchen Sie nach Dichotomie.

Dies gilt jedoch nur, wenn der Quellenteil in voller Größe verfügbar ist.

In solchen Fällen verwende ich zum Beispiel DBMS ohne irgendwelche Tricks. Ich verbringe weniger Zeit mit der Entwicklung und das Produkt ist stabil.

 

Ihr sagt alle die richtigen Dinge, und dies unterstreicht einmal mehr, dass die Option der Kompression für die Aufgabe gerechtfertigt sein sollte.

Sie müssen sich auf die Problemstellung verlassen.

 
elugovoy:

Wenn Sie in dieser Richtung weitermachen wollen, können Sie auch Hashing oder Prüfsummen für die Suche verwenden, Sie müssen keine Kompressionskodierung verwenden. Erstellen Sie einen Hash-Index und suchen Sie nach Dichotomie.

Dies gilt jedoch nur, wenn der Quellenteil in voller Größe verfügbar ist.

In solchen Fällen verwende ich zum Beispiel DBMS ohne irgendwelche Tricks. Ich verbringe weniger Zeit mit der Entwicklung, und das Produkt ist stabil.

Eine gute Idee.
 
Integer:
Das war also nicht mein Vorschlag. Die Idee ist auf jeden Fall interessant.

>>> Es geht um den Vergleich zweier komprimierter Sequenzen.

Dima! Erinnere mich daran, dass wir genau darüber gesprochen haben.

>>> das ist genau das, was wir in der Praxis besprochen haben.

>>> Ja, ich weiß, wenn die Daten kurz sind, erhöht sich die Größe bei der Archivierung.

>> deshalb taugt es nichts

--

Deshalb gibt es diese Ideologie in den industriellen Datenbanken nicht.

...

 
elugovoy:

Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.

Но это при наличии исходной порции в полном объеме.

Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.

Ganzzahlig:

Eine gute Idee.

Sie können es versuchen

>>> In solchen Fällen verwende ich zum Beispiel DBMS ohne irgendwelche Tricks. Die Entwicklungszeit ist kürzer, und das Produkt ist stabil.

aber es ist besser, eine fertige industrielle SQL-Datenbank zu verwenden

 
YuraZ:

>>> Es geht um den Vergleich zweier komprimierter Sequenzen.

Dima! Erinnern Sie mich daran, dass wir genau darüber gesprochen haben.

>>> das ist genau das, was wir in der Praxis besprochen haben.

>>> Ja, ich weiß, wenn die Daten kurz sind, erhöht sich die Größe bei der Archivierung.

>> deshalb taugt es nichts

--

Deshalb haben auch die Industriestandorte diese Ideologie nicht.

...

Ich denke, das hat einen anderen Grund. Denn dort wird das Problem des Ladens großer Daten in den Outliner anders gelöst, sie werden nicht geladen, sondern direkt von der Festplatte gelesen. (wahrscheinlich)
 
YuraZ:

Versuchen Sie dies

>>> Ich zum Beispiel benutze in solchen Fällen ein DBMS ohne irgendwelche Tricks. Ich verbringe weniger Zeit mit der Entwicklung, und das Produkt ist stabil.

aber es ist am besten, fertige industrielle SQL-Datenbanken zu verwenden

Yurichik, ich meine ohne irgendwelche Verrenkungen bei der Dateiverarbeitung, Komprimierung usw. Ich meinte nur die Arbeit mit SQL und Roboter-/Anzeigelogik. Ich habe mit vielen Datenbanken gearbeitet, das einzige Problem war, MQL und SQL zusammenzubringen)). Ich habe eine gut aussehende Lösung ohne Arrays und Strukturen erstellt.

Im Allgemeinen ziehe ich es vor, das Rad nicht neu zu erfinden und Probleme mit den besten Mitteln zu lösen.

 
Integer:
Ich denke, das hat einen anderen Grund. Da das Problem des Ladens großer Daten in das Betriebssystem dort anders gelöst ist, werden sie nicht geladen, sondern direkt von der Festplatte gelesen. (denke ich)

der Server macht es... sehr effizient.