Da (a) die Informationen, mit denen Sie arbeiten, an sich eine sehr wertvolle organisatorische Ressource zu sein scheinen und (b) das Datenvolumen beträchtlich sein wird, würde ich entschieden (c) eine relationale Datenbank auf einer der folgenden Daten aufbauen die wichtigsten SQL-Plattformen.
Das erfordert natürlich - aus einer sehr allgemeinen Perspektive - drei wesentliche Faktoren:
Ein klar definiertes konzeptionelles Schema, in dem die Prototypen von Dingen, dh die Entitätstypen (einschließlich ihrer Eigenschaften und Wechselbeziehungen ), die für das Geschäftsumfeld, mit dem Sie arbeiten (z. B. die Türme und ), relevant sind , genau identifiziert und markiert werden müssen Von Ihnen erwähnte Sensoren ).
Wie Sie wissen, beinhaltet dieser Punkt den Aufbau einer kontinuierlichen und produktiven Kommunikation mit Geschäftsexperten.
Ein logisches Layout , das die konzeptionelle Ebene mit Genauigkeit wiedergibt , mittels Tabellen (dh mathematische Beziehungen) halten gut abgegrenzten Spalte mit entsprechenden Spaltennamen und Typen (dh Beziehung Attribute) und alle der entsprechenden Einschränkungen , um sicherzustellen , dass die Daten und erfüllen Alle Regeln, die auf der vorherigen Ebene festgelegt wurden.
Daher kommt hier die enorme Kraft des relationalen Modells ins Spiel (obwohl seine Vorteile positive Auswirkungen auf andere Abstraktionsebenen haben).
Eine physikalische Anordnung , die, zum Beispiel, erhöht die Ausführungsgeschwindigkeit der -dynamic- logischen Datenmanipulationsoperationen und garantiert die logischen Beschränkungen.
Da das relationale Modell physische Datenunabhängigkeit bietet , kann ein Datenbankverwaltungssystem (DBMS der Kürze halber) auf dieser Ebene jede Art von Struktur bereitstellen, nicht ausschließlich Indizes, um die logischen Definitionen zu unterstützen. Bei den führenden SQL-Plattformen bedeutet dies in der Regel genau das Einrichten einer Indizierungsstrategie auf der Grundlage der datenbankspezifischen Abfragetendenzen, und Sie haben sehr interessante Überlegungen zu einigen möglichen Konfigurationen angestellt, ohne jedoch die Besonderheiten zu kennen Informationsbedürfnisse mit Genauigkeit, spezifische Ratschläge in dieser Hinsicht anzubieten, wären nicht geeignet.
Andere Elemente, die eine Bewertung verdienen, sind beispielsweise die Aktualisierung der Netzwerkinfrastruktur zur Erhöhung der Bandbreite, die Ermöglichung geeigneter Serverkonfigurationen (in Bezug auf Hardware und Software) usw. Und wenn und nur wenn ein Praktiker ausreichend qualifiziert ist, könnte er oder sie dies sogar tun Ändern Sie den Quellcode des DBMS Ihrer Wahl (natürlich in Open Source-Umgebungen praktikabler).
Auf diese Weise werden die folgenden Aspekte hervorgehoben
- Verwalten und Abrufen von Turm- / Sensorkonfigurationen, um die Datenanalyse zu verstehen.
- Datenvisualisierung durch Sensor oder Zeitintervalle für meteorologische Beobachtungen.
- Stellen Sie Kunden zuverlässige und beständige Datenressourcen / Datensätze zur Verfügung, um die Modell- und Sensorleistung zu vergleichen (möglicherweise ist eine Nachbearbeitung erforderlich, um das erforderliche Format zu liefern?).
wäre gut angesprochen, da Sie leicht Anfragen deklarieren könnten, um beispielsweise Informationen in sehr aussagekräftigen Formen zu erhalten. Beispielsweise können Sie Daten abrufen, die mit verknüpft sind
- der Sensor durch SensorNumber identifiziert
1750, am Turm installiert identifiziert durch TowerNumber 31, zwischen dem Datum 1 June 2017und dem Datum27 June 2017 .
Da (1) die Daten in einer relationalen Datenbank mit Hilfe von Operationen, die auf der relationalen Algebra basieren, logisch in Mengen verwaltet werden , und (2) die verschiedenen SQL-Engines für Mengen physikalisch optimiert sind (einige mehr als die anderen) Verarbeitung können Sie zB
- vergleiche Menge a mit Menge b ;
- verbinde Menge c mit Menge d ;
- erhält Untersatz f durch eine Verengung am Set e ;
- Erzeugen von n Teilmengen aus n gesetzten Schnittpunkten;
- Projekt n Attribute aus Menge f
- Informationen aus Menge z abrufen , die das Ergebnis einer Vereinigung von Menge x mit Menge y sind ;
- und so weiter.
Die Datenmanipulationsmöglichkeiten sind in der Tat riesig die unerreichte Vielseitigkeit des relationalen Paradigmen -demonstrating , da Sie nicht nur mit arbeiten können Basistabellen (die mit deklarierten diejenigen CREATE TABLE … ( … );Aussagen) , sondern auch mit abgeleiteten diejenigen (die , die über ausgedrückt SELECT …;Operationen, manchmal fixiert , wie VIEWs) . Mit anderen Worten, Sie können (i) neue Datenstrukturen ausdrücken , die auf (ii) früheren basieren, die auf (iii) dem einzelnen zugrunde liegenden relationalen Konstrukt, dh der mathematischen Beziehung, basieren.
Offensichtlich kann sich die Anordnung der Basistabellen und -spalten einer relationalen Datenbank weiterentwickeln, und (a) neue Basistabellen oder -spalten können in diese Datenbank aufgenommen werden, wenn (b) das Verfolgen neuer Entitätstypen oder Entitätstyp-Eigenschaften in der Datenbank als sinnvoll erachtet wird einschlägiger Geschäftskontext. Mit anderen Worten, es wird erwartet, dass weder die anfängliche Struktur noch die Öffnungsbeschränkungen einer relationalen Datenbank statisch oder unveränderlich sind. Außerdem lässt sich eine von Anfang an angemessen organisierte Datenbank viel einfacher ändern, wenn neue Informationsanforderungen auftreten.
In Übereinstimmung mit den obigen Überlegungen muss das logische Format der anwendbaren Sätze deklarativ auf der logischen Datenbankebene erstellt werden. Die grafische oder präsentative Formatierung der Sätze (z. B. die verwendeten Farb- oder Schriftarten) muss wiederum über den Code eines oder mehrerer Anwendungsprogramme verarbeitet werden (ja, meist prozedural , möglicherweise mit Hilfe eines Objekts) -orientiertes Framework, HTML usw.), um den Zugriff und die Präsentation solcher Sets benutzerfreundlich zu gestalten. Natürlich können Sie auch Berichtssoftware verwenden, die eine Verbindung zu Ihrer Datenbank herstellt.
Die Modellierung einer relevanten Datenbank
Angesichts der Tatsache, dass Sie mit Sensordaten arbeiten (zu denen unter anderem Informationen in Form von Zeitreihen gehören ), finden Sie möglicherweise Hilfe bei der Gestaltung mehrerer Datenbanken und der allgemeinen Verwaltungsprinzipien, die in den beiden außergewöhnlichen Antworten von @PerformanceDBA enthalten sind. zu den Fragen mit dem Titel:
Die Ansätze Relational, Flat File und NoSQL
Das relationale Modell von Dr. Edgar Frank Codd , obwohl 1970 veröffentlicht, bleibt wirklich die modernste und eleganteste Methode (basierend auf Logik und Mengenlehre), um das Problem des Datenmanagements zu bewältigen. Die unterschiedlichen SQL-DBMS sind wiederum die beliebtesten Annäherungen (die zwar nicht vollständig kompatibel, aber dennoch sehr leistungsfähig sind) an die in der relationalen Theorie vorgeschlagenen Systeme, und einige von ihnen wurden stark optimiert (z. B. hinsichtlich ihrer physikalischen Eigenschaften). Level-Mechanismen) seit Jahrzehnten. Darüber hinaus können (und werden) die wichtigsten SQL-Plattformen natürlich recht effizient mit den aktuellsten Speicher- (z. B. Festplatten) und Verarbeitungstechnologien (z. B. CPUs) arbeiten.
Auf der Grundlage eines leistungsstarken DBMS würde eine relationale Datenbank, die auf konzeptioneller, logischer und physischer Ebene ordnungsgemäß entworfen wurde, eindeutig zu einem eigenständigen, selbstbeschreibenden und selbstschützenden Vermögenswert, der (1) vertrauenswürdig ist und (2) a bietet Schnelle Reaktion, zwei Aspekte, die, wie Sie wissen, von großer Bedeutung sind.
Flatfiles
Daher die folgende Behauptung
Mir wurde gesagt, dass der Grund für die Verwendung von Flatfiles darin besteht, dass eine relationale Datenbank zu viel Aufwand bedeuten würde.
wird leicht verworfen, da der Flat-File-Ansatz wäre:
- vorwissenschaftlich;
- bei weitem nicht optimal für große Datenmengen;
- zu umständlich;
- anwendungsprogrammabhängig (und Sie müssten die meisten Funktionen, die richtige DBMS nativ bieten, von Hand implementieren);
- seine Leistung wird leicht untergraben;
- usw.
Während die - viel bequemere - relationale Mode, um es gelinde auszudrücken:
- würde eine große Skalierbarkeit bieten (es ist unabhängig von der physischen Ebene, sodass Sie die zugrunde liegenden physischen Mechanismen nach Bedarf verbessern können);
- würde einen einfachen Stil bringen, um die Daten zu manipulieren (über abstrakte Operationen) und
- könnte mit mehreren Anwendungsprogrammen gleichzeitig arbeiten (z. B. einer oder mehreren mobilen Apps und / oder einer oder mehreren Web-Apps und / oder einer oder mehreren Desktop-Apps usw.).
Wenn Sie sich jedoch für die Verwendung von Flatfiles entscheiden, sollten Sie die Verwendung eines robusten Dienstprogramms wie Awk bewerten , das zwar kein DBMS ist (und nicht als solches konzipiert wurde), aber nützliche Ressourcen für den Umgang mit Dateien , Datensätzen , Feldern usw. Bereitstellt . Siehe das GNU Awk Benutzerhandbuch für weitere Informationen zu diesem Thema.
NoSQL
"Unstrukturierte Daten" und zugehörige Begriffe
Gemäß ihrer Propaganda besteht die anfängliche Rechtfertigung für die Verwendung von NoSQL-DBMS darin, dass sie in Geschäftsdomänen verwendet werden sollen, in denen „unstrukturierte Daten“ verarbeitet werden, sodass die Frage aufgeworfen wird:
- Was soll der Ausdruck "unstrukturierte Daten" bedeuten?
In dieser Hinsicht ist zu sagen, dass die Daten, die von ihrer Natur werden strukturiert; Wenn es keine Struktur hätte, wäre es etwas Bedeutungsloses, folglich könnte so etwas (i) nicht als Daten betrachtet werden und (ii) wäre es nicht wert, verwaltet zu werden. Daher sind „unstrukturierte Daten“ ein widersprüchlicher und unglücklicher Ausdruck.
Ein anderer Ausdruck dieser Kontexte sind „halbstrukturierte Daten“. Dieser Satz legt nahe, dass es Daten gibt, die „teilweise“ oder „halbiert“ strukturiert sind, sodass gemäß dem vorherigen Absatz nur der „Teil“ oder die „Hälfte“, die strukturiert sind, tatsächliche Daten sein können, der verbleibende „Teil“. oder „halb“ ist nur eine formlose Sache, weil es keine Struktur gibt und nicht als Daten bezeichnet werden kann.
Ein weiterer, leider typischer Begriff, der im NoSQL-Marketing vorkommt, sind „polymorphe Daten“. Wenn dieser Begriff so etwas wie "Daten mit vielen verschiedenen Formen" bedeutet, dann handelt es sich tatsächlich um gewöhnliche Daten, die wie immer in vielen verschiedenen Formen auftreten. Und da es viele verschiedene Formen hat, weist es viele unterschiedliche Strukturen auf , sodass diese „Art“ von Daten nichts Besonderes ist.
Es ist unnötig zu erwähnen, dass Daten und Datenstrukturen immer Änderungen ausgesetzt waren , auch diesbezüglich gibt es nichts Ungewöhnliches.
Datenvolumenwachstum
Offensichtlich ist das Informationsvolumen, das mit computergestützten Systemen verwaltet wird, im Laufe der Jahre definitiv gewachsen - und wird im Laufe der Zeit exponentiell weiter wachsen, da jeden Tag neue Systeme gebaut werden -, aber das hat nichts damit zu tun die Struktur der Informationen an sich .
Fehlen einer abgerundeten theoretischen Grundlage
Eine kritische Einschränkung von NoSQL-Systemen (es gibt verschiedene Klassen, z. B. dokument- und graphbasiert ) besteht darin, dass keines der aktuellen Produkte - obwohl stark vermarktet und als „modern“ gekennzeichnet - eine solide theoretische Grundlage besitzt (wenn überhaupt). Dies unterstützt jedes der drei wichtigsten Elemente eines ordnungsgemäßen DBMS, dh Tools für die Definition von Daten (a), (b) Manipulation und (c) Verengung. Der NoSQL-Ansatz deutet also tatsächlich auf eine Regression in eine alte Zeit hin, in der der Umgang mit den Daten in einer ad hoc und unsoliden Vorgehensweise mit all der damit verbundenen unnötigen Komplexität durchgeführt wurde.
Heutzutage sind Graphensysteme im „NoSQL“ -Spektrum enthalten. Diese Softwareprodukte laden dazu ein, Daten aufgrund von Operationen auf zwei unterschiedlichen Strukturen zu verwalten: Knoten und Beziehungen , die wiederum im Widerspruch zum Begriff „unstrukturierte Daten“ stehen, und sie zeichnen sich in der Gruppe „NoSQL“ dadurch aus, dass sie dies tun eine mathematische Grundlage haben. Grafikprodukte ähneln jedoch eher Netzwerkplattformen , die seit zehn Jahren als veraltet gelten (ein offensichtlicher Nachteil besteht darin, dass sie, wie oben vorgeschlagen, zwei Strukturen für die Datendarstellung benötigen, während ein relationales DBMS - gemäß dem Informationsprinzip - braucht nur einen).
Auch wenn die Erstellung der verschiedenen NoSQL-Systeme im Vergleich zu den Ursprüngen der meisten SQL-DBMS chronologisch neuer ist, sind die meisten Konzepte, auf denen die NoSQL-Produkte basieren, praktisch primitiv .
Ein NoSQL-Programm sollte hauptsächlich in Szenarien eingesetzt werden, in denen z.
- Dem IT-Personal fehlen die technischen Fähigkeiten, um die Struktur der interessierenden Daten zu bestimmen (oder aufgrund ihrer Komplexität angemessen zu bestimmen). und / oder
- Die Organisation kann sich keine angemessene Aus- und Weiterbildung für das derzeitige Personal leisten oder keine neuen Mitarbeiter einstellen, die über die erforderliche Aus- und Weiterbildung verfügen. und / oder
- wenn die Integrität und Konsistenz der Daten nicht besonders wichtig ist; und / oder
- Wenn die betreffenden Daten mit denen von unternehmenskritischen Systemen gemischt werden, die eine hohe Präzision erfordern, wird dies nicht erwartet.
Aber selbst wenn die Struktur der fraglichen Daten nicht vor der Erstellung der betreffenden Systeme definiert wird, müssen zwangsläufig eine oder mehrere Personen dies tun
- entdecken Sie die oben genannte Struktur,
- Verwerfen Sie alle umgebenden „Störungen“ und
- Sammeln und verknüpfen Sie die richtigen Daten
Nachdem die Datenbank und die App (s) in die Produktionsphase eingetreten sind, um alle in ein Projekt investierten Ressourcen optimal nutzen zu können, ist die Abgrenzung der Datenstruktur eine Aufgabe, die nicht umgangen werden kann. Sie muss früher erledigt werden oder später.
Obwohl es möglich ist, den NoSQL-Weg zu gehen, sollten auf jeden Fall alle zuvor genannten Faktoren berücksichtigt werden.
Die robusteste Methode
Im Gegensatz dazu bietet die relationale Annäherung an die Informationsanforderungen eines Geschäftsumfelds - dh mit einem allgemeinen Paradigma dahinter - die Möglichkeit, (1) die Daten von Anfang an in ihrer natürlichen Struktur zu verwalten, was die Integration in andere Datenquellen erleichtert. und auch (2) neue vertrauenswürdige Strukturen durch Manipulation eines einzelnen Instruments zu erzeugen - wie in den vorhergehenden Abschnitten erläutert -, das eine solide wissenschaftliche Grundlage hat.
Gemäß Ihrer Beschreibung des betreffenden Szenarios haben Sie bereits eine bestimmte Struktur im Hinblick auf die relevanten organisatorischen Anforderungen identifiziert. Ich empfehle daher, die Business Domain-Experten zu bitten, diese zu validieren. Nacheinander empfehle ich, (i) die Konstrukte - die Beziehung, die Einschränkungen und die Operationen - zu nutzen, die vom relationalen Modell bereitgestellt werden, um diese Struktur und die jeweiligen Daten zu verarbeiten, und (ii) das SQL-DBMS Ihrer Wahl, das sehr wahrscheinlich ist bieten sehr effiziente physikalische Werkzeuge, die den gegenwärtigen Anforderungen gerecht werden und zukünftige Skalierbarkeit bieten.