Design-Ideen für die Bereitstellung von Hochfrequenz-Daten

Question

Ich möchte etwas zu speichern und Zeitreihendaten, die aus einer Vielzahl von Quellen in unterschiedlichen Zeitintervallen kommt zu dienen. Dies umfasst sowohl Rohdaten als auch berechnete Daten. Nehmen wir zum Beispiel an, ich möchte alle 30 Sekunden eine Temperaturmessung protokollieren und eine Temperaturprognose, die ich alle 5 Minuten separat berechne.

Ich muss in der Lage sein, die Daten schnell abzufragen, und ich habe festgestellt, dass eine relationale Datenbank überhaupt nicht gut funktioniert, sobald sie zu groß wird. Ich habe also überlegt, eine Art In-Memory-Sache zu erstellen, aber ich bin mir sicher, dass es irgendwann zum Absturz kommen wird. Daher muss ich die Daten auf der Festplatte speichern. Ich habe mich also gefragt, warum nicht einfach die ganze Sache auf Festplatten basieren, mit einer Art Caching für häufig angeforderte Daten?

aber ich bin ein bisschen ratlos, wie man das macht. Ich stelle mir vor, dass Datenquellen in regelmäßigen Abständen Aktualisierungsdatensätze an den Server übermitteln, indem sie eine Art String-Schlüssel/-Symbol verwenden, um die Daten zu identifizieren. der Server bekommt die Daten und was dann? schreibe es in eine Art Binärdatei? Könnte ich in eine Datei pro Symbol schreiben? (nehmen Sie über 100k Symbole an)

Ich denke, was ich will, ist googles BigTable ähnlich, aber in einem viel kleineren Maßstab. Im Grunde eine verteilte Hash-Tabelle, die einen String-Schlüssel einer Zeitreihe zugehöriger Daten zuordnet, mit sehr schnellem Abruf und der Möglichkeit, eine Bereichsabfrage nach Zeit abzurufen. und zusätzliche Punkte für mehrdimensionale Daten.

Oh, und dies würde (idealerweise) von einem C#/Windows-Projekt - es muss nicht sein, dass hohe Leistung.

Answer 1

Wenn Sie eine Datenbank verwenden und Indizierung und den relationalen Teil herausnehmen, bekommen Sie ziemlich genau, was Sie beschrieben haben. Ich bin mir jedoch nicht sicher, wie nützlich es wäre. Könnten Sie uns eine bessere Idee geben, warum eine Datenbank für Sie nicht funktioniert hat? Was hast du versucht, das hat nicht funktioniert?

Answer 2

Ich muss Ihnen sagen, dass kein "Dateisystem" -Ansatz (den ich kenne) schneller sein wird als eine relationale Datenbank. Und es wird wahrscheinlich viel schlimmer sein.

Das Problem mit relationalen Datenbanken ist nicht, dass sie inhärent langsam sind, sondern dass das Platzieren von Daten sehr einfach ohne Rücksicht darauf, wie die Daten gespeichert werden, durchgeführt werden kann. Ein guter Index, selbst für Millionen von Datensätzen, sollte Ergebnisse in Sekundenbruchteilen liefern. Es ist mehr eine Frage des Designs als ein Problem des Zugriffs. Wenn Sie es gut auslegen, wird der Zugriff kommen.

edit: Wenn Sie mit "relationale Datenbank" auch Microsoft Access meinen, haben Sie recht; Es ist langsam mit vielen Platten. Ich würde diesen Weg nicht gehen. Schauen Sie in MySql, wenn Geld ein Problem oder Oracle/Sql Server ist, wenn Geld nicht ist.

Answer 3

Ich bin nicht sicher, warum Sie in einer Datenbank dafür sind. Ich habe Echtzeitstatistiken über Tabellen mit 10 Millionen Zeilen erstellt. Außerdem könnten Sie die Messwerte periodisch aufstapeln, um Hunderttausende Zeilen in Hunderte von Zeilen kompilierter Daten zu verwandeln - abhängig von Ihren Bedürfnissen.

Für In-Memory-Persistenz und Schlüssel-Wert-Paar-Zugriff können Sie sich memcachedb ansehen. Es basiert auf Memcached und bietet hervorragende Leistung.

Auch, nachdem Sie darüber nachgedacht haben, könnten Sie das Ding einfach als Hashtabelle im Speicher ausführen und es dann regelmäßig in das Dateisystem für die Persistenz serialisieren.

Answer 4

Ich würde mit anderen zustimmen, dass eine Datenbank Ihre beste Wette wäre.

Wenn Sie wirklich eine so große Datenmenge generieren, dass es zu einem Leistungsproblem kommt, können Sie zwei Tabellen erstellen - eine als "Echtzeit" -Quelle und eine andere als "Archiv".

Ihr System würde neue Daten in die Echtzeittabelle einfügen und ein Stapeljob würde regelmäßig Daten von dort in die Archivtabelle verschieben. Wenn die Leistung ein Problem darstellt, würden Sie nur die kleinere Echtzeittabelle abfragen. Wenn Sie tatsächlich alle Daten abfragen müssten, würden Sie eine Ansicht abfragen, in der UNION die Echtzeit- und Archivtabellen anzeigt.

Answer 5

Klingt wie eine SCADA (System Control And Data Acquisition) Art Anwendung, die Nutzung der Datenerfassung Teil des Systems. Haben Sie sich Lösungen von der Stange angesehen? Wonderware/IndustrialSQL oder ein Konkurrenzprodukt?

Nachdem mein jetziger Arbeitgeber (The MetService, New Zealand) alle 30 Sekunden, 1 Minute oder 1 Stunde von automatischen Wetterstationen (Temperatur, Niederschlag, Wind, etc) und Prognosen zu einer Oracle DB protokolliert. Minimale Indexierung; Indizes verlangsamt 3 von 4 DML-Aktionen und beschleunigt Selects Natürlich brauchen Sie die 3 Aktionen, um schnell zu sein, insbesondere die Insert. Schnelles IO-System. Sehr schnelle IO für Redo-Logs. Wir bewegen uns zu partitionierten Tabellen, so dass die Löschungen schneller sind und weniger Redo generieren (den Tabellenbereich einschließlich des Inhalts löschen, anstatt ein Löschen auszugeben). Ernsthaft, obwohl leichte, schnelle Transaktionen für Einfügungen gegeben sind. Schwerwiegend ist jedoch die Leistung von Maschinen, die Inserts ausführen und Netzwerke zwischen ihnen und der DB herstellen.

Answer 6

Leider bin ich verboten durch NDA-Vereinbarungen, Ihnen zu sagen, wie dies zu tun ist. Ich habe an dem Team gearbeitet, das eine nicht relationale Datenbank erstellt hat, die genau das tut, was Sie versuchen. Es heißt Zitadelle. Ich kann Sie jedoch auf den Link für das, was öffentlich verfügbar ist, hinweisen, und es sollte Ihnen einige Ideen geben, wie es funktioniert.

http://zone.ni.com/devzone/cda/tut/p/id/6579

könnten Sie kaufen nur das Produkt, aber es ist ziemlich teuer.

Auch als Karl weist darauf hin, dies ist in der Regel in SCADA-Produkten verwendet wie Wonderware, Lookout und LabVIEW DSC.

Eine Suche nach SCADA data storage ergibt auch einige interessante Lektüre.

---

Nebenbei können relationale Datenbanken dieses Problem lösen, wenn die Datenmenge gering ist. Was im Laufe der Zeit passiert, ist, dass die Daten unbegrenzt wachsen und die relationale Datenbank über ihre Kapazität hinaus gefüllt wird. Ein gutes SCADA-Datenspeichersystem kann leicht 50000 Punkte verarbeiten, die in einer Sekunde abgefragt werden. Obwohl sie irgendwann zu groß werden, um sie problemlos zu handhaben.

Answer 7

"RRDTool ist das OpenSource Industriestandard, Hochleistungs-Datenprotokollierungs- und Grafiksystem für Zeitreihendaten."

Es besteht aus zwei Teilen, einer, der Zeitreihendaten protokolliert, speichert und abruft, und einem zweiten Teil für die grafische Darstellung. Es gibt viele Beispiele dafür.

Auch wenn Sie es nicht verwenden, ist das Design definitiv relevant.