KDB+, ein Produkt des Unternehmens — ist eine in Fachkreisen weithin bekannte, extrem schnelle Spalten-Datenbank, die für die Speicherung von Zeitreihen und die darauf basierenden analytischen Berechnungen konzipiert wurde. Ursprünglich fand sie (und findet nach wie vor) große Beliebtheit in der Finanzbranche – alle Top-10-Investmentbanken sowie viele renommierte Hedgefonds, Börsen und andere Organisationen nutzen sie. In letzter Zeit hat KX beschlossen, seine Kundenbasis zu erweitern und bietet jetzt Lösungen in anderen Bereichen an, in denen große Mengen von zeit- oder anders strukturierten Daten vorhanden sind – Telekommunikation, Bioinformatik, Fertigung usw. Sie sind unter anderem Partner des Aston Martin Red Bull Racing Teams in der Formel 1, wo sie dabei helfen, Daten von den Sensoren der Fahrzeuge zu sammeln und Tests im Windkanal zu analysieren. In diesem Artikel möchte ich erläutern, welche Eigenschaften KDB+ zu einer überaus leistungsfähigen Lösung machen, warum Unternehmen bereit sind, große Summen dafür auszugeben, und letztendlich, warum es sich dabei tatsächlich nicht um eine klassische Datenbank handelt.
In diesem Artikel werde ich insgesamt versuchen, die KDB+ vorzustellen, welche Möglichkeiten und Einschränkungen sie hat und welchen Nutzen sie für Unternehmen bietet, die große Datenmengen verarbeiten möchten. Ich werde nicht auf die Implementierungsdetails von KDB+ und deren Programmiersprache Q eingehen. Beide Themen sind sehr umfangreich und verdienen gesonderte Artikel. Viele Informationen zu diesen Themen finden Sie auf der Website code.kx.com, darunter auch das Buch zu Q – Q For Mortals (siehe Link unten).
Einige Begriffe
- In-Memory-Datenbank. Eine Datenbank, die Daten im Arbeitsspeicher speichert, um den Zugriff zu beschleunigen. Die Vorteile einer solchen Datenbank sind offensichtlich, während die Nachteile die Möglichkeit eines Datenverlusts und die Notwendigkeit, viel Speicherplatz auf dem Server zu haben, umfassen.
- Spaltenorientierte Datenbank. Eine Datenbank, in der Daten spaltenweise und nicht zeilenweise gespeichert werden. Der Hauptvorteil einer solchen Datenbank besteht darin, dass die Daten einer Spalte gemeinsam auf der Festplatte und im Speicher gespeichert werden, was den Zugriff erheblich beschleunigt. Es ist nicht notwendig, Spalten zu laden, die im Abfrage nicht verwendet werden. Der größte Nachteil ist die Schwierigkeit, Datensätze zu modifizieren und zu löschen.
- Zeitreihe. Daten mit Datum- oder Zeitspalten. In der Regel ist bei solchen Daten die zeitliche Anordnung wichtig, um leicht feststellen zu können, welcher Eintrag dem aktuellen vorangeht oder folgt, oder um Funktionen anzuwenden, deren Ergebnis von der Reihenfolge der Einträge abhängt. Klassische Datenbanken basieren auf einem völlig anderen Prinzip – der Darstellung einer Gesamtheit von Einträgen als Menge, bei der die Reihenfolge der Einträge prinzipiell nicht definiert ist.
- Vektor. Im Kontext von KDB+ ist dies eine Liste von Elementen eines atomaren Typs, beispielsweise Zahlen. Mit anderen Worten, ein Array von Elementen. Arrays können im Gegensatz zu Listen kompakt gespeichert und mit Vektor-Instruktionen des Prozessors verarbeitet werden.
Historischer Hintergrund
Die Firma KX wurde 1993 von Arthur Whitney gegründet, der zuvor bei Morgan Stanley im Bereich der A+-Sprache arbeitete, einem Nachfolger von APL – einer sehr originellen und einst beliebten Sprache in der Finanzwelt. Selbstverständlich setzte Arthur bei KX diesen Ansatz fort und entwickelte die vektorfunktionale Sprache K, die von den Ideen des radikalen Minimalismus inspiriert ist. Programme in K erscheinen als chaotische Ansammlungen von Satzzeichen und speziellen Symbolen; die Bedeutung der Zeichen und Funktionen hängt vom Kontext ab, und jede Operation trägt weit mehr Bedeutung als in gewöhnlichen Programmiersprachen. Dadurch nimmt ein Programm in K minimalen Platz in Anspruch – mehrere Zeilen können Seiten an Text in einem ausufernden Sprache wie Java ersetzen – und stellen eine hochkonzentrierte Umsetzung eines Algorithmus dar.
Eine Funktion in K, die den Großteil des LL1-Parser-Generators gemäß einer vorgegebenen Grammatik implementiert:
1. pp:{q:{(x;p3(),y)};r:$[-11=@x;$x;11=@x;q[`N;$*x];10=abs@@x;q[`N;x]
2. ($)~*x;(`P;p3 x 1);(1=#x)&11=@*x;pp[{(1#x;$[2=#x;;,:]1_x)}@*x]
3. (?)~*x;(`Q;pp[x 1]);(*)~*x;(`M;pp[x 1]);(+)~*x;(`MP;pp[x 1]);(!)~*x;(`Y;p3 x 1)
4. (2=#x)&(@x 1)in 100 101 107 7 -7h;($[(@x 1)in 100 101 107h;`Ff;`Fi];p3 x 1;pp[*x])
5. (|)~*x;`S,(pp'1_x);2=#x;`C,{@[@[x;-1+#x;{x,")"}];0;"(",]}({$[".s.C"~4#x;6_-2_x;x]}'pp'x);'`pp];
6. $[@r;r;($[1<#r;".s.";""],$*r),$[1<#r;"[",(";"/:1_r),"]";""]]}
Diese Philosophie der extremen Effizienz mit minimalem Aufwand hat Arthur auch in KDB+ verkörpert, das 2003 entstand (ich denke, jetzt sollte klar sein, woher das K im Namen stammt). Es handelt sich um einen Interpreter der vierten Version der K-Sprache. Über K wurde eine benutzerfreundlichere Version namens Q hinzugefügt. Q bietet ebenfalls Unterstützung für einen speziellen SQL-Dialekt – QSQL – und in den Interpreter wurden Funktionen für Tabellen als Datentyp, In-Memory-Tabellen und deren Verwaltung etc. integriert.
KDB+ ist im Grunde genommen ein Interpreter für die Q-Sprache, der Tabellen und SQL-ähnliche Ausdrücke im Stil von LINQ aus C# unterstützt. Dies ist das entscheidende Unterscheidungsmerkmal von KDB+ im Vergleich zu anderen Datenbanken und ihr Hauptvorteil, der oft übersehen wird. Es handelt sich nicht um eine Datenbank mit einer schwachen unterstützenden Sprache, sondern um eine vollwertige, leistungsstarke Programmiersprache mit integrierter Unterstützung für Datenbankfunktionen. Diese Unterscheidung wird eine wichtige Rolle bei der Aufzählung aller Vorteile von KDB+ spielen. Zum Beispiel…
Größe
Gemessen an modernen Standards hat KDB+ eine echtes mikroskopisches Volumen. Es handelt sich hierbei buchstäblich um eine ausführbare Datei, die weniger als ein Megabyte groß ist, sowie eine kleine Textdatei mit einigen systemeigenen Funktionen. Tatsächlich ist es weniger als ein Megabyte, und Unternehmen zahlen dafür jährlich Zehntausende von Dollar für einen Prozessor auf einem Server.
- Diese geringe Größe ermöglicht es KDB+, auf jeder Hardware hervorragend zu laufen – von einem Mikrocomputer wie dem Pi bis hin zu Servern mit Terabytes an Speicher. Die Funktionalität wird dadurch nicht beeinträchtigt; tatsächlich startet Q in Sekundenschnelle, was es unter anderem als Skriptsprache nutzbar macht.
- Bei dieser Größe wird der Q-Interpreter vollständig im Cache des Prozessors untergebracht, was die Ausführung von Programmen beschleunigt.
- Bei dieser Größe nimmt die ausführbare Q-Datei nur minimalen Speicherplatz ein, sodass Sie Hunderte davon gleichzeitig starten können. Bei Bedarf kann Q jedoch auch mit Dutzenden oder Hunderten von Gigabyte Speicher innerhalb eines Prozesses umgehen.
Universalisierung
Q eignet sich hervorragend für eine Vielzahl von Aufgaben. Der Q-Prozess kann als historische Datenbank fungieren und schnellen Zugriff auf Terabytes von Informationen bieten. Beispielsweise haben wir Dutzende historischer Datenbanken, von denen einige an einem unkomprimierten Tag Daten von mehr als 100 Gigabyte enthalten. Dennoch wird eine Anfrage an die Datenbank unter vernünftigen Einschränkungen in Dutzenden bis Hunderten von Millisekunden bearbeitet. Generell haben wir einen universellen Timeout für Benutzeranfragen von 30 Sekunden, der sehr selten ausgelöst wird.
Mit der gleichen Leichtigkeit kann Q als In-Memory-Datenbank fungieren. Das Hinzufügen neuer Daten zu den Tabellen im Arbeitsspeicher erfolgt so schnell, dass die Benutzeranfragen der limitierende Faktor sind. Die Daten in den Tabellen werden spaltenweise gespeichert, was bedeutet, dass jede operation auf einer Spalte den Prozessor-Cache voll ausnutzt. Darüber hinaus hat KX versucht, alle grundlegenden Operationen, wie arithmetische Berechnungen, durch vektorisierte Prozessoranweisungen zu implementieren, um deren Geschwindigkeit zu maximieren. Q kann auch Aufgaben ausführen, die nicht typisch für Datenbanken sind – zum Beispiel das Verarbeiten von Streaming-Daten und die Berechnung von "Echtzeit"-Aggregationsfunktionen für Finanzinstrumente über verschiedene Zeitintervalle hinweg oder die Modellierung des Einflusses eines durchgeführten Handels auf den Markt, gefolgt von einer fast sofortigen Profilierung nach der Durchführung. Bei solchen Aufgaben ist meist nicht Q die Hauptursache für Verzögerungen, sondern die Notwendigkeit, Daten aus verschiedenen Quellen zu synchronisieren. Hohe Geschwindigkeiten werden erreicht, weil sich die Daten und die Funktionen, die sie verarbeiten, in demselben Prozess befinden, und die Verarbeitung auf die Ausführung mehrerer QSQL-Ausdrücke und Joins beschränkt ist, die nicht interpretiert, sondern im Binärcode ausgeführt werden.
Schließlich können in Q auch alle Serviceprozesse implementiert werden. Zum Beispiel Gateway-Prozesse, die Benutzeranfragen automatisch den entsprechenden Datenbanken und Servern zuordnen. Der Programmierer hat die volle Freiheit, jeden Algorithmus zur Lastverteilung, Priorisierung, Fehlertoleranz, Zugriffsrechten, Quoten und allgemein zur Umsetzung beliebiger Ideen zu realisieren. Das Hauptproblem dabei ist, dass man alles selbst implementieren muss.
Als Beispiel werde ich die Typen von Prozessen auflisten, die wir haben. Alle werden aktiv genutzt und arbeiten zusammen, um Dutzende verschiedener Datenbanken zu integrieren, Daten aus zahlreichen Quellen zu verarbeiten und Hunderte von Nutzern und Anwendungen zu bedienen.
- Connectoren (feedhandler) zu Datenquellen. Diese Prozesse verwenden in der Regel externe Bibliotheken, die in Q geladen werden. Die C-Schnittstelle in Q ist äußerst einfach und ermöglicht es, problemlos Proxy-Funktionen für jede C/C++-Bibliothek zu erstellen. Q ist schnell genug, um beispielsweise die Verarbeitung von FIX-Nachrichtenströmen von allen europäischen Börsen gleichzeitig zu bewältigen.
- Datendistributoren (tickerplant), die als Bindeglied zwischen den Connectoren und den Verbrauchern dienen. Gleichzeitig schreiben sie die eingehenden Daten in ein spezielles binäres Protokoll, um den Verbrauchern Stabilität gegenüber Verbindungsverlusten oder Neustarts zu bieten.
- In-Memory-Datenbanken (rdb). Diese Datenbanken ermöglichen den schnellsten Zugriff auf frisch erfasste Rohdaten, indem sie diese im Speicher halten. In der Regel sammeln sie die Daten tagsüber in Tabellen und setzen diese nachts zurück.
- Persistente Datenbanken (pdb). Diese Datenbanken sichern die heutigen Daten in einer historischen Datenbank. Im Gegensatz zu rdb speichern sie die Daten in der Regel nicht im Speicher, sondern verwenden einen speziellen Cache auf der Festplatte tagsüber und kopieren die Daten um Mitternacht in die historische Datenbank.
- Historische Datenbanken (hdb). Diese Datenbanken bieten Zugriff auf Informationen aus vergangenen Tagen, Monaten und Jahren. Die Größe (in Tagen) ist lediglich durch die Kapazität der Festplatten begrenzt. Die Daten können an beliebigen Orten gespeichert werden, insbesondere auf verschiedenen Festplatten, um den Zugriff zu beschleunigen. Es besteht die Möglichkeit, Daten mithilfe verschiedener algorithmen zu komprimieren. Die Struktur der Datenbank ist gut dokumentiert und einfach, die Daten werden in normalen Dateien strukturiert gespeichert, sodass sie auch mit den Mitteln des Betriebssystems verarbeitet werden können.
- Datenbanken mit aggregierten Informationen. Sie speichern verschiedene Aggregationen, in der Regel gruppiert nach dem Namen des Instruments und dem Zeitintervall. In-memory-Datenbanken aktualisieren ihren Zustand mit jeder eingehenden Nachricht, während historische Datenbanken vorab berechnete Daten speichern, um den Zugriff auf historische Daten zu beschleunigen.
- Letztendlich Gateway-Prozesse, die Anwendungen und Benutzer bedienen. Q ermöglicht eine vollständig asynchrone Verarbeitung eingehender Nachrichten, deren Verteilung auf Datenbanken, Zugriffsberechtigungsprüfungen usw. Ich möchte darauf hinweisen, dass die Nachrichten nicht nur SQL-Anweisungen umfassen und häufig keine sind, wie es bei anderen Datenbanken der Fall ist. Häufig ist die SQL-Anweisung in einer speziellen Funktion verborgen und wird basierend auf den vom Benutzer angeforderten Parametern konstruiert – es erfolgt eine Zeitkonvertierung, Filterung, die Daten werden normiert (z. B. wird der Aktienpreis angepasst, wenn Dividenden ausgezahlt wurden) usw.
Typische Architektur für einen Datentyp:
Geschwindigkeit
Obwohl Q eine interpretierte Sprache ist, handelt es sich gleichzeitig um eine Vektorsprache. Das bedeutet, dass viele integrierte Funktionen, insbesondere arithmetische, Argumente jeder Form akzeptieren — seien es Zahlen, Vektoren, Matrizen oder Listen. Von den Entwicklern wird erwartet, dass sie Programme als Operationen auf Arrays implementieren. In einer solchen Sprache spielt es keine Rolle, wenn Sie zwei Vektoren mit einer Million Elementen addieren, dass die Sprache interpretiert ist; die Addition erfolgt durch eine superoptimierte Binärfunktion. Da der Großteil der Zeit in Programmen in Q für Operationen mit Tabellen verwendet wird, die diese grundlegenden vektorisierte Funktionen nutzen, erzielt man eine sehr ordentliche Geschwindigkeit, die es ermöglicht, auch große Datenmengen in einem Prozess zu verarbeiten. Dies ist vergleichbar mit mathematischen Bibliotheken in Python — obwohl Python selbst eine eher langsame Sprache ist, bietet sie viele hervorragende Bibliotheken wie numpy, die es ermöglichen, numerische Daten mit der Geschwindigkeit einer kompilierenden Sprache zu verarbeiten (übrigens ist numpy ideologisch Q sehr nahe).
Darüber hinaus hat KX großen Wert auf das Design von Tabellen und die Optimierung ihrer Nutzung gelegt. Erstens werden mehrere Arten von Indizes unterstützt, die durch integrierte Funktionen bereitgestellt werden und nicht nur auf Spalten, sondern auch auf verschiedene Vektoren angewendet werden können – wie Gruppierung, Sortierung, Einzigartigkeit und spezielle Gruppierungen für historische Datenbanken. Indizes werden einfach erstellt und automatisch angepasst, wenn Elemente zu einer Spalte oder einem Vektor hinzugefügt werden. Sie können sowohl auf Tabellen, die im Speicher als auch auf der Festplatte liegen, erfolgreich angewendet werden. Bei der Ausführung von QSQL-Anfragen werden die Indizes automatisch genutzt, wenn dies möglich ist. Zweitens wird der Zugriff auf historische Daten über das Mechanismus der Dateiansicht des Betriebssystems (memory map) realisiert. Große Tabellen werden niemals vollständig in den Speicher geladen; stattdessen werden nur die benötigten Spalten direkt in den Speicher angezeigt, und es wird tatsächlich nur der Teil geladen, der erforderlich ist (hierbei helfen unter anderem die Indizes). Für Programmierer spielt es keine Rolle, ob die Daten im Speicher sind oder nicht; der Umgang mit mmap ist vollständig im Kern von Q verborgen.
KDB+ ist eine nicht-relationale Datenbank, in der Tabellen beliebige Daten enthalten können, wobei die Reihenfolge der Zeilen in der Tabelle beim Hinzufügen neuer Elemente unverändert bleibt und bei der Abfrage verwendet werden kann und sollte. Dieses Merkmal ist besonders wichtig für die Verarbeitung von Zeitreihen (Daten von Börsen, Telemetrie, Event-Logs), da, wenn die Daten zeitlich sortiert sind, der Benutzer keine SQL-Tricks anwenden muss, um die erste oder letzte Zeile nach Zeit oder N Zeilen in der Tabelle zu finden oder zu bestimmen, welche Zeile auf die N-te Zeile folgt usw. Joins zwischen Tabellen werden dadurch noch einfacher, beispielsweise dauert es etwa eine Sekunde auf der Festplatte und ein Dutzend Millisekunden im Speicher, die letzte Notierung für 16.000 Transaktionen von VOD.L (Vodafone) aus einer Tabelle mit 500 Millionen Elementen zu finden.
Ein Beispiel für einen zeitbasierten Join — die Quotentabelle wird in den Speicher geladen, daher ist es nicht erforderlich, VOD.L in der Where-Klausel anzugeben; es wird implizit der Index auf der Spalte sym sowie die Tatsache genutzt, dass die Daten zeitlich sortiert sind. Fast alle Joins in Q sind normale Funktionen und kein Teil des Select-Ausdrucks:
1. aj[`sym`time;select from trade where date=2019.03.26, sym=`VOD.L;select from quote where date=2019.03.26]
Es ist wichtig zu erwähnen, dass die Ingenieure bei KX, beginnend mit Arthur Whitney, wirklich auf Effizienz fokussiert sind und alle Anstrengungen unternehmen, um das Beste aus den Standardfunktionen von Q herauszuholen und die häufigsten Nutzungsmuster zu optimieren.
Zusammenfassung
KDB+ ist besonders bei Unternehmen beliebt, vor allem wegen ihrer außergewöhnlichen Vielseitigkeit – sie fungiert sowohl als In-Memory-Datenbank als auch als Speicher für Terabytes historischer Daten und als Plattform für Datenanalysen. Dank der direkten Datenverarbeitung in der Datenbank werden hohe Geschwindigkeiten und Ressourcenschonung erzielt. Eine vollwertige Programmiersprache, die mit den Funktionen der Datenbank integriert ist, ermöglicht es, auf einer Plattform den gesamten Prozessstapel zu realisieren – vom Datenerhalt bis zur Verarbeitung von Benutzeranfragen.
Weitere Informationen
Nachteile
Ein wesentlicher Nachteil von KDB+/Q ist die hohe Einstiegshürde. Die Sprache hat eine ungewöhnliche Syntax, einige Funktionen sind stark überladen (wie 'value', das etwa 11 Verwendungsmöglichkeiten hat). Am wichtigsten ist, dass sie einen radikal anderen Ansatz beim Programmieren erfordert. In der Vektorsprache muss man ständig in Bezug auf Array-Transformationen denken und alle Schleifen über verschiedene Varianten der Funktionen map/reduce (die in Q als Adverbs bezeichnet werden) umsetzen, und niemals versuchen, durch die Verwendung atomarer Operationen Vektoroperationen einzusparen. Zum Beispiel sollte man für die Suche nach dem Index des N-ten Vorkommens eines Elements in einem Array Folgendes schreiben:
1. (where element=vector)[N]
Obwohl dies nach Maßstäben von C/Java schrecklich ineffizient aussieht (es wird ein boolescher Vektor erstellt, wobei 'where' die Indizes der 'true'-Elemente zurückgibt). Doch solch eine Schreibweise macht die Bedeutung des Ausdrucks klarer und man nutzt schnelle Vektoroperationen anstelle langsamer atomarer. Der konzeptionelle Unterschied zwischen der Vektorsprache und anderen ist vergleichbar mit dem Unterschied zwischen imperativen und funktionalen Programmieransätzen, und darauf sollte man vorbereitet sein.
Einige Benutzer sind auch mit QSQL unzufrieden. Es ist zwar SQL ähnlich, aber in Wirklichkeit ist es lediglich ein Interpreter für SQL-ähnliche Ausdrücke, der keine Abfrageoptimierung unterstützt. Der Benutzer muss selbst optimale Abfragen schreiben, und zwar in Q, wozu viele nicht bereit sind. Auf der anderen Seite kann man natürlich immer selbst eine optimale Anfrage schreiben, anstatt sich auf einen Black-Box-Optimierer zu verlassen.
Ein Vorteil ist, dass das Buch über Q – Q For Mortals kostenlos erhältlich ist auf , wo auch viele andere nützliche Materialien gesammelt sind.
Ein weiterer großer Nachteil ist die Lizenzkosten. Diese betragen Zehntausende von Dollar pro Jahr für einen CPU. Nur große Unternehmen können sich solche Ausgaben leisten. In letzter Zeit hat KX die Lizenzpolitik flexibler gestaltet und bietet die Möglichkeit, nur für die Nutzungszeit zu zahlen oder KDB+ in den Clouds von Google und Amazon zu mieten. Zudem bietet KX zum Download an (32-Bit-Version oder 64-Bit-Version auf Anfrage).
Wettbewerber
Es gibt eine Vielzahl von spezialisierten Datenbanken, die auf ähnlichen Prinzipien basieren — spaltenorientierte, in-memory und auf sehr große Datenmengen ausgerichtete Systeme. Das Problem dabei ist, dass es sich um spezialisierte Datenbanken handelt. Ein markantes Beispiel ist Clickhouse. Diese Datenbank verwendet ein ähnliches Prinzip wie KDB+ zur Speicherung von Daten auf der Festplatte und zum Aufbau von Indizes. Einige Abfragen führt sie sogar schneller als KDB+ aus, wenn auch nur geringfügig. Doch selbst als Datenbank ist Clickhouse spezialisierter als KDB+ — Web-Analyse im Vergleich zu beliebigen Zeitreihen (diese Unterscheidung ist sehr wichtig — zum Beispiel kann Clickhouse keine Ordnung der Datensätze nutzen). Das Hauptproblem bleibt jedoch, dass Clickhouse nicht die Vielseitigkeit von KDB+ bietet, einer Sprache, die es ermöglicht, Daten direkt in der Datenbank zu verarbeiten, anstatt sie vorab in eine separate Anwendung zu laden, beliebige SQL-Ausdrücke zu erstellen, beliebige Funktionen in Abfragen anzuwenden und Prozesse zu erstellen, die nicht mit der Ausführung von Funktionen der historischen Datenbank verbunden sind. Daher ist ein Vergleich von KDB+ mit anderen Datenbanken schwierig; diese können in bestimmten Nutzungsszenarien besser sein oder einfach besser, wenn es um klassische Datenbankaufgaben geht. Mir ist jedoch kein anderes so effizientes und vielseitiges Werkzeug zur Verarbeitung von Zeitdaten bekannt.
Integration mit Python
Um die Arbeit mit KDB+ für Personen, die mit der Technologie nicht vertraut sind, zu vereinfachen, hat KX Bibliotheken entwickelt, die eine enge Integration mit Python in einem Prozess ermöglichen. Es ist möglich, jede Python-Funktion aus Q aufzurufen und umgekehrt – jede Q-Funktion aus Python (insbesondere QSQL-Ausdrücke). Die Bibliotheken konvertieren die Daten, wenn nötig (aus Effizienzgründen nicht immer), von einem Format in das andere. Dadurch leben Q und Python in solch einer engen Symbiose, dass die Grenzen zwischen ihnen verschwommen werden. Der Programmierer hat somit einerseits vollen Zugang zu zahlreichen nützlichen Python-Bibliotheken und erhält andererseits eine in Python integrierte, schnelle Datenbank für die Verarbeitung großer Datenmengen, was insbesondere für diejenigen von Vorteil ist, die sich mit maschinellem Lernen oder Modelling beschäftigen.
Arbeiten mit Q in Python:
1. >>> q()
2. q)trade:([]date:();sym:();qty:())
3. q)
4. >>> q.insert('trade', (date(2006,10,6), 'IBM', 200))
5. k(',0')
6. >>> q.insert('trade', (date(2006,10,6), 'MSFT', 100))
7. k(',1')
Links
Unternehmenswebsite —
Entwicklerwebsite —
Buch Q For Mortals (auf Englisch) —
Artikel zur Anwendung von KDB+/Q von Mitarbeitern von kx —
Quelle: habr.com
