Shutterstock
Nach einer kürzlich angekündigten Finanzierungsrunde in Höhe von 40 Millionen US-Dollar diversifiziert Timescale seine TimescaleDB-Plattform mit mehreren Zielen: Skalierbarkeit und Erweiterung neue Analyse-Engine.
Wie wir bei der Diskussion der allgemeinen Veröffentlichung von Amazon Timestream im letzten Herbst festgestellt haben, sind Zeitreihenplattformen eine alte, aber plötzlich neue Kategorie in der Datenbanklandschaft. Obwohl das IoT oft für das Ergebnis der Aktivität von Zeitreihendatenbanken genannt (oder beschuldigt) wird, gibt es zahlreiche Szenarien (z. B. auf den Kapitalmärkten, Transport und Logistik usw.), in denen Zeit der bestimmende Parameter ist.
Aber lassen Sie uns dieses Geständnis jetzt gleich los: TimescaleDB ist ein Markenname, der leicht mit Amazon Timestream verwechselt werden kann (OK, Timescale kam zuerst auf den Markt). Infolgedessen stolpern wir sehr oft über all dieses fast identische Branding und fanden uns im globalen Ersetzungsmodus wieder, um sicherzustellen, dass wir die richtigen Namen in die richtigen Sätze setzen.
Timescale ist eines dieser Quasi-Open-Source-Unternehmen, das seine eigene Lizenzvariante des Monats angewendet hat, um Kunden zum Spielen und Verbessern von Code zu ermutigen, aber zu verhindern, dass die AWSs der Welt Datenbank-Cloud-Dienste in seiner Community-Edition starten. Die Version 2.0, die vor einigen Monaten veröffentlicht wurde, hat die Lizenzierung leicht liberalisiert, um Kunden zu ermutigen, den Code zu optimieren.
Im Gegensatz zur bekannteren InfluxDB ist Timescale sehr stark im SQL-Modus, wie Amazon Timestream. Im Gegensatz zu Timestream ist TimescaleDB jedoch eine PostgreSQL-Variante. Somit schließt sich TimescaleDB einer buchstäblich großen Menge in der PostgreSQL-Community an, aber es ist einzigartig, da es eine der wenigen, wenn nicht die einzigen PostgreSQL-Varianten ist, die speziell für Zeitreihendaten entwickelt wurden.
Timescale hat die Version 2.0 bereits im Februar veröffentlicht und befindet sich seitdem in einem monatlichen Rhythmus mit mehreren Dot-Releases. Wenn die aktuellen Versionen ein gemeinsames Thema haben, geht es darum, die Plattform zu skalieren, die verteilte Bereitstellung zu unterstützen und am Horizont die Plattform zu erweitern, um Analysen zu unterstützen.
Während Analysen für Anwendungsfälle von Zeitreihendaten sehr nützlich sein sollten, sind die meisten Zeitreihendatenbanken nicht für tiefe oder komplexe Analysen ausgelegt. Ironischerweise ist dies auf die Größe der Rohdaten zurückzuführen, die einfließen. Die meisten Zeitreihendatenbanken skalieren alte Daten herunter (z. B. komprimieren oder archivieren), um die Speicherkosten im Zaum zu halten. Zu den kürzlich eingeführten Funktionen von TimescaleDB gehört die Möglichkeit, eingehende (unkomprimierte) Echtzeitdaten mit komprimierten historischen Daten zu analysieren. Mehr dazu gleich.
Das Highlight der neuen Funktionen ist die Unterstützung für verteilte Bereitstellung mit mehreren Knoten. Um es zu erklären, müssen wir unter die Decke gehen, um die einzigartige Architektur von TimescaleDB zu erklären. Viele operative Datenbanken basieren auf Sharding, bei dem verschiedene Teile derselben Tabelle auf mehrere Knoten verteilt werden. Obwohl es sich nicht um eine relationale Datenbank handelt, skaliert MongoDB auf diese Weise. TimescaleDB basiert jedoch auf einem etwas anderen Konstrukt, das es als “Chunk” bezeichnet.
Ein Chunk ist wie eine Nur-Append-Datenbank, da bei Zeitreihendaten bei weitem der größte Teil der Aktivität mit Schreib- oder Einfügevorgängen und nicht mit Änderungen erfolgt. Und die Schreibvorgänge erfolgen in der Regel in aufeinanderfolgenden Zeitintervallen, was im Gegensatz zu der eher zufälligen Verteilung steht, die bei den meisten Transaktionsdatenbanken üblich ist. Für Timescale ist ein Chunk im Wesentlichen ein Shard, der auch mehrere Zeitscheibenpartitionen hat. Wenn es Zeit ist, dem Chunk eine neue Zeitpartition hinzuzufügen, fügt das System sie einfach hinzu; Es ist nicht erforderlich, das System neu auszubalancieren oder neu zu laden, da die neue Partition zusammenhängend ist. Und all diese Chunks werden als eine einheitliche logische Tabelle gelesen, obwohl sie unter der Decke stark partitioniert und zersplittert ist. Eine Gruppe verknüpfter Chunks in TimescaleDB wird als Hypertabellen verwaltet, die die gesamte Assemblage wie eine physische Tabelle aussehen lassen.
Bisher konnten Hypertables nur auf einem einzigen Knoten ausgeführt werden. In der 2.x-Generation können sich Hypertables jedoch mit all ihren residenten Chunks auf mehrere Knoten verteilen. Das Ergebnis ist, dass TimescaleDB, das bisher Terabyte an Daten aufnehmen konnte, jetzt bis zu einem Petabyte-Bereich aufblähen kann.
Da Timescale nun horizontal skaliert werden kann, besteht der nächste logische Schritt darin, einen ganzen Tabellencluster für hohe Verfügbarkeit zu replizieren und die Mittel für die Neuverteilung älterer Blöcke im gesamten Cluster bereitzustellen. Dies basiert auf der Annahme, dass bei Zeitreihendaten nur die neuesten Zeitscheibenpartitionen aktiv sind. Beide Funktionen stehen auf der Roadmap.
Eine weitere kürzliche Verbesserung bezieht sich auch auf die Skalierung. Während Zeitreihendatenbanken schreibintensiv sind, müssen Abfragen ausgeführt werden. Bisher waren zum Auffinden eindeutiger Werte vollständige Tabellenscans des Index erforderlich. Andere relationale Datenbanken wie Oracle, MySQL, IBM Db2 und CockroachDB verfügen bereits über Funktionen, mit denen Scans irrelevante Werte in zusammengesetzten Indizes überspringen können (z. B. Indizes, die nach mehreren Spalten sortieren). Das hat PostgreSQL jedoch gefehlt, daher fügt TimescaleDB vorerst seine eigene Skip-Scan-Funktion hinzu. Wenn die PostgreSQL-Community diese Lücke schließt, würden wir erwarten, dass Timescale sie wahrscheinlich zurückportieren wird.
Die neueste Version von Releases hat auch die Komprimierung optimiert, sodass Sie in bereits komprimierte Blöcke schreiben können. Wie andere Zeitreihendatenbanken wendet Timescale die Komprimierung auf ältere Werte an – dies geschieht über eine Spaltenansicht, die vor einigen Jahren eingeführt wurde.
OK, greifen wir den Analytics-Thread noch einmal auf. Sie kündigen ein neues Projekt zum Hinzufügen einer analytischen Engine an – sie wird aus offensichtlichen Gründen getrennt von der bestehenden TimescaleDB-Operations-Engine verwaltet – analytische Abfragen verbrauchen Ressourcen anders als operative Transaktionen. Aber an dieser Stelle ist Analytik immer noch ein Anspruch; Timescale hat die Community um Reaktion und Anleitung gebeten. Wir hoffen, dass die neue Engine im Gegensatz zu Konkurrenten wie InfluxData auf derselben zugrunde liegenden Technologiebasis wie die bestehende basiert.
Big Data
Wo ist IBMs Hybrid Cloud-Launchpad? Sieben Möglichkeiten, Echtzeit-Technologie für Ihr Unternehmen real zu machen Maschinelles Lernen am Edge: TinyML wird groß Was kommt als nächstes für Cloudera? McDonald's möchte maschinelles Lernen für alle Benutzer im gesamten Betrieb “demokratisieren”
Verwandte Themen:
Datenmanagement Digitale Transformation Robotik Internet der Dinge Innovation Unternehmenssoftware 