Nach Evaluierung verschiedener Datenbanktechnologien im IoT-Umfeld setzen wir in unser IIoT-Plattform da³vid auf die hybride Datenbank TimescaleDB des 2014 gegründeten Unternehmens Timescale Inc. Wie wir diese Technologie in da³vid umsetzen, können Sie hier nachlesen.
Wir wollten mehr über das Unternehmen Timescale lernen und erfahren, welche Features für die Zukunft geplant sind. Daher haben wir uns sehr gefreut, als wir die Chance bekommen haben, den Co-Founder und CTO von Timescale, Mike Freedman, interviewen zu dürfen. Er erklärt, wie Timescale gewachsen ist und ob der Fokus auf IoT bereits von Anfang an für deren Datenbank geplant war.
-> Das Interview im Original (Englisch) finden Sie hier.
Sie haben sehr schnell eine beeindruckende Gemeinschaft aufgebaut, und viele Ihrer Spezialisten arbeiten von überall auf der Welt aus. Wie kam es zur Gründung von TimescaleDB und wie haben Sie es geschafft, so schnell weltweit zu wachsen? War dies von Anfang an Ihr Ziel?
Als wir Timescale gründeten, hatten wir nicht vor, die führenden relationalen Datenbanken für Zeitreihendaten zu entwickeln. Wir haben zunächst eine Plattform für IoT-Daten gebaut – gleichzeitig sahen wir eine Zukunft, in der alle unsere Geräte miteinander verbunden sind, insbesondere industrielle Geräte, die große Mengen an Daten erzeugen. Entwickler haben zudem eine Möglichkeit gebraucht, diese Daten einfach zu erfassen, zu speichern und zu analysieren. Beim Aufbau dieser Plattform waren wir aber schnell unzufrieden mit den vorhandenen Optionen für Zeitseriendatenbanken. Sie boten nicht die Skalierbarkeit und Leistung, die wir brauchten, insbesondere für Daten mit hoher Kardinalität. Sie waren für unsere Bedürfnisse nicht ausreichend zuverlässig oder flexibel. Ihr SQL-Dialekt entsprach in wichtigen Punkten nicht unseren Anforderungen; so konnten wir beispielsweise unsere Gerätemetriken nicht mit zusätzlichen Informationen über die Geräte JOINen. Diese Liste setze sich fort.
Als wir mehr über die Architektur von IoT- und Zeitserien-Workloads nachdachten, fanden wir heraus, wie wir das, was wir brauchten, durch die Erweiterung von PostgreSQL erstellen konnten: Wir nehmen all die Vorzüge von PostgreSQL, aber erweitern es für Zeitreihendaten. Wir erkannten schnell, dass dieses Projekt, das wir zunächst intern zur Befriedigung unserer eigenen Bedürfnisse entwickelt hatten, einen viel größeren und breiteren Bedarf hatte. Also richteten wir das Unternehmen neu aus und veröffentlichten TimescaleDB Anfang 2017 als Open-Source.
Seitdem sind wir schnell gewachsen, sowohl in Bezug auf unsere Community als auch auf unser Unternehmen. Dass wir ein weit verteiltes Team sind, hat dabei sicherlich geholfen.
Die meiste Zeit unserer Geschichte haben mindestens 60 % unserer Mitarbeiter von verschiedenen Standorten aus gearbeitet, während die restlichen 40 % in einem unserer beiden Büros in New York und Stockholm tätig waren. Die COVID-19-Pandemie führte dann schließlich dazu, dass wir und alle Teams zu 100 % remote arbeiteten. (In unserem Blog berichten wir über unsere Erfahrungen beim Aufbau einer "remote-first"-Teamkultur).
Wir sind in den letzten Monaten erheblich gewachsen. Wir haben erkannt, dass wir, wenn wir die besten Talente anziehen wollen, es ihnen einfach machen müssen - und bestärken! – dort zu arbeiten, wo die Leute arbeiten möchten. Daher sind wir seit März 2020 ein vollständig dezentralisiertes Unternehmen mit Mitarbeitern auf allen Kontinenten (außer der Antarktis). Und, wenn Sie sich uns anschließen und das nächste große Datenbankunternehmen aufbauen möchten, wir stellen Mitarbeiter in allen Teams und Abteilungen ein!
Die meisten Zeitreihen-Datenbanken sind in der NoSQL-Bewegung angesiedelt. Sie haben sich entschieden, eine etablierte SQL-Datenbank mit Superkräften auszustatten. Was hat Sie dazu motiviert, diesen Ansatz zu wählen, und wo liegen Ihre Stärken?
Der Grund, warum die meisten Entwickler NoSQL-Zeitreihendatenbanken einsetzen, ist in der Regel die (meiner Meinung nach falsche) Vorstellung von Skalierbarkeit. Relationale Datenbanken haben zwar viele nützliche Funktionen, die die meisten NoSQL-Datenbanken nicht haben (z. B. umfangreiche Schemata und transaktionale Operationen, robuste sekundäre Indizierung, erweiterte Abfrageplanung, Unterstützung für komplexe Prädikate, eine umfangreiche Abfragesprache, JOINs und Fremdschlüssel, usw.), aber vor TimescaleDB wurden sie nicht speziell für Zeitreihen-Workloads entwickelt.
Wir haben immer geglaubt, dass relationale Datenbanken für Zeitreihendaten ziemlich leistungsfähig sein können, wenn sie sorgfältig für Zeitreihen-Workloads entwickelt werden. Als wir im April 2017 die erste Version von TimescaleDB auf den Markt brachten, bekamen wir viel positives Feedback, hörten aber auch von Skeptikern. Sie fanden es schwer zu glauben, dass es möglich ist, eine skalierbare Zeitseriendatenbank auf einer relationalen Datenbank aufzubauen. (Wir haben bewiesen, dass diese Skepsis unberechtigt ist; in mehreren Benchmark-Analysen übertrifft TimescaleDB die Leistung von NoSQL-Datenbanken für Zeitserien-Workloads.)
Wir haben uns entschieden, TimescaleDB auf PostgreSQL aufzubauen, weil wir wussten, dass wir somit auf einer soliden Grundlage aufbauen können und es den Entwicklern ermöglichen, die Fähigkeiten und Tools zu nutzen, die sie bereits kennen und lieben. Außerdem gefiel uns einfach die Zuverlässigkeit und Benutzerfreundlichkeit von PostgreSQL - und da sind wir nicht die Einzigen: PostgreSQL hat ein riesiges Ökosystem und gehört zu den besten Datenbanken.
Unsere Kunden sagen, dass die Unterstützung von vollständigem SQL in Kombination mit massiver Skalierung, unserem hybriden zeilen- und spaltenkomprimierten Speicher und kontinuierlichen Aggregaten die Hauptunterscheidungsmerkmale von TimescaleDB sind. Und, wie ich bereits erwähnt habe, übernimmt TimescaleDB die inhärente Zuverlässigkeit, Funktionalität und die Werkzeuge von PostgreSQL, da es auf PostgreSQL aufbaut. Mithilfe unserer horizontal skalierbaren Architektur in TimescaleDB 2.0, kombiniert mit unseren beeindruckenden 94% - 97% Kompressionsraten, können alle Vorzüge von PostgreSQL im Petabyte-Bereich erzielt werden.
Durch die Verwendung kontinuierlicher Aggregate können wir den Nutzern unserer IoT-Plattform eine beeindruckende Leistung bieten. Haben Sie sich von Anfang an auf die Nutzung Ihrer Datenbank im IoT konzentriert?
Es freut mich sehr, von eurem Erfolg mit kontinuierlichen Aggregaten zu hören. Sie sind eine leistungsstarke Funktion, die in IoT-Anwendungen sehr nützlich ist. Man definiert etwas, das wie eine materialisierte Sicht auf Daten aussieht, und die Datenbank pflegt sie inkrementell: Angenommen, Sie möchten die Mindest-, Höchst- und Durchschnittswerte jedes Geräts pro Stunde haben, sodass Sie schnell Längsschnittabfragen durchführen können, die Monate oder Jahre an Daten abfragen.
Aber lassen Sie mich auf zwei einzigartige Aspekte der kontinuierlichen Aggregation von TimescaleDB eingehen, mit denen wir besonders zufrieden sind. Erstens wird backfill korrekt, nahtlos und effizient gehandhabt. Nehmen wir an, einige Daten kommen spät in das System, und Sie haben bereits ein "Rollup" für diesen Zeitraum berechnet. Dieses ist jetzt nicht mehr genau. TimescaleDB verfolgt jedoch ordnungsgemäß "Ungültigkeitsdatensätze", sodass es transparent und asynchron nur die schmalen Bereiche, die verspätete Daten haben, neu berechnet.
Zweitens unterstützt es Echtzeit-Aggregate. Nehmen wir an, dass Sie historische Daten möchten, aber auch die neuesten Messwerte, und Sie möchten nicht, dass die Datenbank bei jedem Einfügen ständig die letzte Aggregation aktualisiert - das ist nicht effizient. Wenn Sie also ein kontinuierliches Aggregat abfragen, kombiniert die Datenbank-Engine die zuvor berechneten Regionen mit den neuesten Rohdaten - und das völlig transparent. Somit ist Ihre Abfrage immer aktuell, aber gleichzeitig schnell und einfach für die Nutzer.
In den kommenden Monaten werden wir weitere Anwendungsfälle mit kontinuierlichen Aggregaten ausbauen.
Wie ich bereits erwähnt habe, denken wir viel über IoT-Anwendungsfälle nach, da unsere Wurzeln bei Timescale im IoT liegen. Wir haben hunderttausende von Zeitreihendatenpunkten von IoT-Geräten gespeichert und benötigten eine Datenbank, um all diese Daten zu speichern. Damals verwendeten wir zwei Datenbanken: eine NoSQL-Datenbank zum Speichern von Zeitreihendaten und PostgreSQL zum Speichern unserer relationalen Daten. Dies hat zu Problemen geführt: Es fragmentierte unseren Datensatz in Silos, führte zu komplexen Verknüpfungen auf der Anwendungsebene und erforderte, dass wir zwei verschiedene Systeme pflegen und betreiben.
Wir waren mit dieser Einrichtung nicht zufrieden. Sie war operativ komplex, erlaubte uns nicht, die gewünschten Fragen zu stellen, und war nicht leistungsfähig.
Wir - und viele Entwickler - lieben und nutzen PostgreSQL aus vielen Gründen, und wir haben TimescaleDB entwickelt, um das Beste aus beiden Welten zu kombinieren: eine relationale Datenbank für Zeitreihendaten.
Wir haben zwar mit dem IoT begonnen, aber Zeitreihendaten sind allgegenwärtig, und in den letzten Jahren sind die Zeitreihen-Workloads aus vielen Gründen explodiert (z. B. Wachstum bei der IT-Überwachung, Produktanalyse, Finanzdaten und Kryptowährungen, Gaming, maschinelles Lernen, Logistik und vieles mehr).
Wie mein Mitbegründer Ajay in der Ankündigung unserer Serie-B-Finanzierung schrieb: "Jeder möchte schneller bessere datengestützte Entscheidungen treffen, was bedeutet, dass Daten mit der höchstmöglichen Genauigkeit erfasst werden müssen. Zeitreihen sind die zuverlässigsten Daten, die man erfassen kann, weil sie genau zeigen, wie sich die Dinge im Laufe der Zeit verändern. Während herkömmliche Datensätze statische Schnappschüsse liefern, bieten Zeitreihendaten den dynamischen Film dessen, was in Ihrem System passiert: z. B. Ihre Software, Ihr physisches Kraftwerk, Ihr Spiel, Ihre Kunden innerhalb Ihrer Anwendung."
Welche neuen Funktionen können wir in naher Zukunft erwarten, von denen die Nutzer unserer IoT-Plattform profitieren werden?
Wir haben viele neue Funktionen und Verbesserungen in Arbeit, sowohl für spezifische Funktionen - wie Hyperfunktionen und einfachere Analysen, kontinuierliche Aggregate, Komprimierung und Multi-Node - als auch auf Produktebene. Unsere Dokumente enthalten immer die vollständigen Release-Notes mit Details zu den neuesten Funktionen, Verbesserungen und unseren Zukunftsplänen.
