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

 
YuraZ:

die Idee ist klar...

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

es muss einen Grund geben

Denn die Datenbank meistert die Aufgabe der Suche bereits perfekt, ohne alle Daten in den Arbeitsspeicher zu laden.
 
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 gesuchte 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.

Um es klar zu sagen: In Ihrem Fall müssten es 3a, 3b und 3c in komprimierter Form sein, denn Sie lassen die Anzahl der Wiederholungen weg.

Wenn Sie glauben, dass ein solcher Algorithmus eine Komprimierung von 70-80 % ermöglicht, irren Sie sich. Selbst bei russischsprachigem Text (ganz zu schweigen von Zahlen) werden die Daten durch diesen Ansatz nur aufgebläht.

Zum Beispiel wird das Wort "Expert" als "1E1k1с1п1е1р1t" umkodiert und nicht einmal ein Bit komprimiert, sondern zweimal aufgeblasen. Wenn Sie die "1" weglassen, findet trotzdem keine Kompression statt.

Das Datum und die Uhrzeit 2014.08.18 13:45:45 werden Ihnen nicht den Weg versperren.

Ganz zu schweigen von den Zitaten... Die Effizienz einer solchen Transkodierung liegt in diesem Fall also nahe bei 0. Dies ist der so genannte RLE-Algorithmus, der im PCX-Format verwendet wird.

 
elugovoy:

1. Um es klar zu sagen: In Ihrem Fall müssten es 3a, 3b und 3c in komprimierter Form sein, denn Sie lassen die Anzahl der Wiederholungen weg.

Wenn Sie glauben, dass ein solcher Algorithmus eine Komprimierung von 70-80 % ermöglicht, liegen Sie falsch. Selbst bei russischsprachigem Text (ganz zu schweigen von Zahlen) werden die Daten durch diesen Ansatz nur aufgebläht.

Zum Beispiel wird das Wort "Expert" als "1E1k1с1п1е1р1t" umkodiert und nicht einmal ein Bit komprimiert, sondern zweimal aufgeblasen. Wenn Sie die "1" weglassen, findet trotzdem keine Kompression statt.

Das Datum und die Uhrzeit 2014.08.18 13:45:45 werden Ihnen nicht den Weg versperren.

Ganz zu schweigen von den Zitaten... Die Effizienz einer solchen Transkodierung liegt in diesem Fall also nahe bei 0. Dies ist der so genannte RLE-Algorithmus, der im PCX-Format verwendet wird.

1. Das ist keine Tatsache. Vielleicht sind die Daten so beschaffen, dass alles dreimal vorkommt, deshalb ist es ein so einfacher Kompressionsalgorithmus.

Der Rest... Vielen Dank, Sie haben mir die Augen geöffnet. Ich wusste nicht, dass die Komprimierung kurzer Datenfolgen deren Größe erhöht.

 
Integer:
Denn die Datenbank leistet bereits gute Arbeit bei der Suche, ohne alle Daten in den Arbeitsspeicher zu laden.

Ein guter und korrekt eingerichteter SQL-Server (wenn Ihre Hardware z.B. 64g und 128zu hat)

nimmt praktisch die gesamten 64 g abzüglich der Anforderungen des Betriebssystems ein ... 128г

und die Suche nach 20 Gigabyte Daten (vorgespeicherte Daten) würde praktisch im Speicher stattfinden...

Deshalb ist es auch nicht sinnvoll, sie zu komprimieren.

--

 
Integer:

Das ist eine Art Andeutung:

Wie man sucht, habe ich bereits geschrieben.

Zunächst einmal sind "Hinweis" und "Behauptung" unterschiedliche Begriffe.

Zweitens, in meinen Worten ist nicht einmal ein Hauch davon zu erkennen, ich sage es noch einmalFür eine Quelldatei gibt es einen Baum, und für einen Teil der zu findenden Daten gibt es einen weiteren

Und mit einem mehr oder weniger seriösen Kompressionsalgorithmus (irgendeinem klassischen, sogar dem von Huffman) wird man die Suche nicht durchführen können. Nicht einmal theoretisch.

 
Integer:
Denn die Datenbank leistet bereits gute Arbeit bei der Suche, ohne alle Daten in den Arbeitsspeicher zu laden.
Deshalb ist es sinnvoll, 20 Gigabyte in der SQL-Datenbank zu speichern.
 
elugovoy:

Zunächst einmal sind ein "Hinweis" und eine "Behauptung" unterschiedliche Begriffe.

Zweitens, in meinen Worten ist nicht einmal ein Hauch davon zu erkennen, ich sage es noch einmalDie Quelldatei hat einen Baum, aber der zu suchende Teil der Daten hat seinen eigenen Baum.

Und mit einem mehr oder weniger seriösen Komprimierungsalgorithmus (irgendeinem klassischen, sogar dem von Huffman) werden Sie nicht in der Lage sein, die Suche durchzuführen. Nicht einmal theoretisch.

Warum sollte ein Teil der Daten einen anderen Baum haben, wenn Sie die gleichen Daten komprimieren? Wenn unterschiedliche Daten, lassen Sie es einen anderen Baum haben. Das Wichtigste ist, dass die komprimierten Daten übereinstimmen, wenn die gleichen Daten komprimiert werden.
 
Integer:
Warum sollte es für einen Teil der Daten einen anderen Baum geben, wenn die gleichen Daten komprimiert wurden? Wenn andere Daten, dann soll es einen anderen Baum geben. Was uns interessiert, ist die Koinzidenz der komprimierten Daten, wenn die gleichen Daten komprimiert werden.

Dimitri - wenn das möglich wäre

vor langer Zeit hätten sie eine SQL-Industriedatenbank geschaffen - mit (SCHNELLER) Suche in gut (80%-90%) komprimierten Daten...

auch mit Insert Update Delete

 
Integer:

1. Das ist keine Tatsache. Vielleicht sind die Daten so beschaffen, dass alles dreimal vorkommt, daher der einfache Komprimierungsalgorithmus.

Der Rest... Danke, dass Sie mir die Augen geöffnet haben, ich wusste nur nicht, dass die Komprimierung kurzer Datenfolgen deren Größe erhöht.

Und noch ein kleines Argument, um meine Augen offen zu halten. Jede Kodierung hat einen Zweck.

Es gibt eine Dekompressionskodierung, die dazu dient, binäre Daten über Kommunikationskanäle zu übertragen, die nur Fernschreiben unterstützen (z. B. Bilder per E-Mail), wobei normalerweise Base64 auf der Grundlage des Radix-Algorithmus verwendet wird.

Redundante Kodierung in Verbindung mit Datenkorrektur (wie CD Aduio) mit dem Ziel, die Daten so weit wie möglich vor Beschädigung des physischen Trägers zu schützen.

Komprimierungskodierung, der Zweck Lagerung/Archivierung Daten.

 
YuraZ:

Dmitry - wenn es möglich wäre

hätten sie schon längst eine industrielle SQL-Datenbank gebaut - mit (SCHNELLER) Suche in gut (80%-90% ) komprimierten Daten...

Gehen Sie in eine zweite Runde? Lesen Sie noch einmal ab Seite 5-6. Lesen Sie den Beitrag aufmerksam.

Unterstellen Sie mir nicht, was ich vorgeschlagen habe. Ich habe vorgeschlagen, kondensierte Sequenzen zu vergleichen, die unabhängig voneinander komprimiert werden. Nicht nach kleinen, separat komprimierten Texten in einer separat komprimierten großen Datei zu suchen.