Ich brauche Hilfe! Ich kann das Problem nicht lösen, ich stoße an die Grenzen der Hardware - Seite 4
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich habe darüber nachgedacht. Ich wurde um eine Stellungnahme gebeten:
Wie hoch ist der Geschwindigkeitszuwachs im Vergleich zum Lesen einer Datei und wie hoch ist die Verlangsamung im Vergleich zur Arbeit im Speicher?
Das DBMS legt seine Tabellen so weit wie möglich im Speicher ab.
aber nicht in Ihrem Fall, es sei denn natürlich, Sie haben 32 GB RAM
Wie man also 20 GB in 4 GB unterbringt, ist eine echte Herausforderung für die Optimierung.
Wenn Sie Ihre Aufgabe vereinfachen wollen, sollten Sie ein regelmäßiges RAM-Laufwerk im Speicher einrichten.
Wenn Sie das nicht können, sollten Sie sich für eine Festplatte entscheiden.
Wie viel schneller wird es im Vergleich zum Lesen einer Datei sein und wie viel langsamer im Vergleich zur Arbeit im Speicher?
Nun, Sie müssen die Datei nicht nur lesen, sondern auch suchen, berechnen, Text in Zahlen umwandeln, sortieren, usw.
Erstens können Sie, wenn die Daten nicht häufig aktualisiert werden, beliebig viele Indizes für die an der Datensuche beteiligten Attribute (einschließlich aggregierter Attribute) erstellen. Dadurch wird die Suche (unter Verwendung von Indizes) und damit auch die Berechnung beschleunigt.
Zweitens verwenden MySQL, MS SQL, Oracle und andere Datenbanken die Technologie des Daten-Caching für sich wiederholende Abfragen, was ebenfalls einen gewissen Geschwindigkeitsvorteil mit sich bringt.
Drittens können Sie eine Tabelle in Teile (Partitionen) unterteilen, beispielsweise nach Jahren. Daher werden bei Abfragen, die Daten für ein Jahr auswählen, keine Daten in anderen Partitionen gelesen/gesucht.
Viertens: Da Ihre Quelldaten in Textform vorliegen, sollten sie beim Laden in die Datenbank aufgrund der natürlichen Typkonvertierung kleiner sein. Zum Beispiel benötigt die Zahl 124.223456221 in Textform 13 Bytes, in der Datenbank je nach Typ 4-8; Datum und Uhrzeit "2014-08-17 10:23:35" benötigen 19 Bytes und in der Datenbank 8 Bytes.
Fünftens: Wenn Sie häufig aggregierte Informationen für bestimmte Zeiträume verwenden, können Sie diese Daten einmal aggregieren und in einer anderen Tabelle speichern.
Wenn es nur um das Lesen von Daten in den Speicher geht, ist WinApi natürlich schneller, aber was macht man danach mit den Daten? Stellen Sie sich vor, selbst für die Suche nach dem richtigen Teil der Daten müssen Sie alle Daten von der Festplatte lesen. Oder Sie müssen die Indizierungsfunktionalität schreiben, Daten in der Datei sortieren, Indexdateien für alle Suchvorgänge erstellen und die Hälfte der DBMS-Funktionalität neu schreiben. Um eine solche Datenmenge zu verarbeiten und eine angemessene Leistung zu erzielen, ist dies notwendig.
Meine Meinung ist eindeutig - ein Server-DBMS (Datei-DBMS wie MS Access, SQLite wird hier nicht funktionieren) auf einem dedizierten Rechner. Die Leistung wird ausreichend sein und die Daten können leicht verarbeitet werden (SQL-Abfragen). Andernfalls verschwenden Sie viel Zeit mit dem Schreiben von Low-Level-"Internals" zur Verarbeitung der Datei.
Ich habe darüber nachgedacht. Ich wurde um eine Stellungnahme gebeten:
Wie hoch ist der Geschwindigkeitszuwachs im Vergleich zum Lesen einer Datei und wie hoch ist die Verlangsamung im Vergleich zur Arbeit im Speicher?
( Ich habe Erfahrung mit Datenbanken über 3TB und relativ kleinen Datenbanken von 10-100gigs )
aber mit bestimmter Hardware ... sagen wir 64gb RAM und mehr mit einem guten Festplatten-Subsystem
In dieser Situation im Vergleich zur Arbeit mit einer großen Datei
SQL wird sich erheblich beschleunigen, aber die Geschwindigkeit hängt natürlich von den SQL-Implementierungen ab
- korrektes Datenbankdesign - korrekte Indizes - korrekte Datenbankkonfiguration
das bedeutet Dateiaufteilung (so wie elugovoy es schreibt )
Eine vollständige Implementierung würde einen separaten Server und ein Server-Betriebssystem erfordern - SQL-Datenbank
wenn MS SQL muss nicht niedriger als 2008 (in Bezug auf die Software ist auch wünschenswert, nicht unter 64)
Meiner Meinung nach wird die Umsetzung jedoch ziemlich arbeits- und hardwareintensiv sein... (64 Bit ist ideal)
--
Wenn Sie nur 16 Gigabyte auf Ihrem Rechner haben und er als Station verwendet wird
Setzen Sie einfach SQL-Server auf es wird nicht groß sein - aber besser als mit einer Textdatei zu stören
Wenn Sie jedoch keine Erfahrung mit SQL haben, ist bei der Implementierung ein gewisser Aufwand erforderlich.
Und wenn diese Datei mit einem Archivierungsprogramm komprimiert wird, wie groß wird sie dann sein (da der Text sehr gut komprimiert sein sollte)?
Die Zeit, die zum Dekomprimieren jedes Durchlaufs benötigt wird, beeinträchtigt die Leistung.
die Zeit, die für die Entarchivierung jedes Durchlaufs benötigt wird, beeinträchtigt die Leistung
Ich meine damit nicht die Archivierung. Wenn durch die Archivierung das Volumen stark reduziert werden kann, dann ist es sinnvoll, die Informationen in einer Indexdatei zu komprimieren.
war ursprünglich
Und wenn diese Datei mit einem Archivierungsprogramm komprimiert wird, wie groß ist dann das Volumen (schließlich sollte der Text sehr gut komprimiert werden)?
daher die Reaktion auf Ihren Beitrag!
Indexdatei - erstellen... ? das ist ein anderes Thema
Noch cooler ist es, einen eigenen (SQL-ähnlichen) Server zu schreiben - aber warum?
von Anfang an war es
daher die Reaktion auf Ihren Beitrag!
Indexdatei - zum Erstellen... ? das ist ein anderes Thema
Noch cooler ist es, einen eigenen Server (z. B. SQL) zu schreiben - aber warum?
Die ursprüngliche Frage an den Autor war, wie stark die Datei komprimiert ist. ....
Darf ich fragen, warum?
Sie wird um 70-80% komprimiert, und was wird der Autor tun, um das von ihm beschriebene Problem zu lösen?