Architecture KDB +

Kdb + est une base de données performante et volumineuse conçue dès le départ pour gérer d'énormes volumes de données. Il est entièrement 64 bits et dispose d'un traitement multicœur et d'un multi-threading intégrés. La même architecture est utilisée pour les données en temps réel et historiques. La base de données intègre son propre langage de requête puissant,q, les analyses peuvent donc être exécutées directement sur les données.

kdb+tick est une architecture qui permet la capture, le traitement et l'interrogation de données historiques et en temps réel.

Architecture Kdb + / tick

L'illustration suivante fournit un aperçu général d'une architecture Kdb + / tick typique, suivie d'une brève explication des différents composants et du flux de données.

  • le Data Feeds sont des séries chronologiques de données qui sont principalement fournies par les fournisseurs de flux de données tels que Reuters, Bloomberg ou directement à partir d'échanges.

  • Pour obtenir les données pertinentes, les données du flux de données sont analysées par le feed handler.

  • Une fois que les données sont analysées par le gestionnaire de flux, elles sont transmises au ticker-plant.

  • Pour récupérer les données de tout échec, le téléscripteur met d'abord à jour / stocke les nouvelles données dans le fichier journal, puis met à jour ses propres tables.

  • Après la mise à jour des tables internes et des fichiers journaux, les données de boucle à temps sont envoyées / publiées en continu vers la base de données en temps réel et tous les abonnés chaînés qui ont demandé des données.

  • À la fin d'un jour ouvrable, le fichier journal est supprimé, un nouveau est créé et la base de données en temps réel est enregistrée dans la base de données historique. Une fois que toutes les données sont enregistrées dans la base de données historique, la base de données en temps réel purge ses tables.

Composants de l'architecture Kdb + Tick

Flux de données

Les flux de données peuvent être des données de marché ou d'autres séries chronologiques. Considérez les flux de données comme l'entrée brute du gestionnaire de flux. Les flux peuvent provenir directement de l'échange (données de diffusion en direct), des fournisseurs d'actualités / de données tels que Thomson-Reuters, Bloomberg ou toute autre agence externe.

Gestionnaire d'alimentation

Un gestionnaire de flux convertit le flux de données dans un format adapté à l'écriture dans kdb +. Il est connecté au flux de données et récupère et convertit les données du format spécifique au flux en un message Kdb + qui est publié dans le processus de téléscripteur. Généralement, un gestionnaire de flux est utilisé pour effectuer les opérations suivantes -

  • Capturez les données selon un ensemble de règles.
  • Traduisez (/ enrichissez) ces données d'un format à un autre.
  • Récupérez les valeurs les plus récentes.

Usine de ticker

Ticker Plant est le composant le plus important de l'architecture KDB +. C'est la centrale de téléscripteur avec laquelle la base de données en temps réel ou directement les abonnés (clients) sont connectés pour accéder aux données financières. Il fonctionne enpublish and subscribemécanisme. Une fois que vous avez obtenu un abonnement (licence), une publication tick (de routine) de l'éditeur (ticker plant) est définie. Il effectue les opérations suivantes -

  • Reçoit les données du gestionnaire de flux.

  • Immédiatement après que l'usine de téléscripteur ait reçu les données, elle stocke une copie sous forme de fichier journal et la met à jour une fois que l'usine de téléscripteur obtient une mise à jour afin qu'en cas de panne, nous ne devrions pas avoir de perte de données.

  • Les clients (abonné en temps réel) peuvent directement souscrire au ticker-plant.

  • À la fin de chaque jour ouvrable, c'est-à-dire une fois que la base de données en temps réel reçoit le dernier message, elle stocke toutes les données du jour dans la base de données historique et les transmet à tous les abonnés qui se sont abonnés aux données du jour. Ensuite, il réinitialise toutes ses tables. Le fichier journal est également supprimé une fois que les données sont stockées dans la base de données historique ou dans un autre abonné directement lié à la base de données en temps réel (rtdb).

  • En conséquence, le téléscripteur, la base de données en temps réel et la base de données historique sont opérationnels 24 heures sur 24, 7 jours sur 7.

Puisque le ticker-plant est une application Kdb +, ses tables peuvent être interrogées en utilisant qcomme toute autre base de données Kdb +. Tous les clients de l'usine de téléscripteur ne devraient avoir accès à la base de données qu'en tant qu'abonnés.

Base de données en temps réel

Une base de données en temps réel (rdb) stocke les données du jour. Il est directement connecté à l'usine de ticker. En règle générale, il serait stocké en mémoire pendant les heures de marché (un jour) et écrit dans la base de données historique (hdb) à la fin de la journée. Comme les données (données rdb) sont stockées en mémoire, le traitement est extrêmement rapide.

Comme kdb + recommande d'avoir une taille de RAM au moins égale à quatre fois la taille attendue des données par jour, la requête qui s'exécute sur rdb est très rapide et offre des performances supérieures. Étant donné qu'une base de données en temps réel ne contient que les données du jour, la colonne de date (paramètre) n'est pas requise.

Par exemple, nous pouvons avoir des requêtes rdb comme,

select from trade where sym = `ibm

OR

select from trade where sym = `ibm, price > 100

Base de données historique

Si nous devons calculer les estimations d'une entreprise, nous devons disposer de ses données historiques. Une base de données historique (hdb) contient les données des transactions effectuées dans le passé. L'enregistrement de chaque nouvelle journée serait ajouté au hdb à la fin de la journée. Les grandes tables dans le hdb sont soit stockées évasées (chaque colonne est stockée dans son propre fichier) soit elles sont stockées partitionnées par des données temporelles. De plus, certaines bases de données très volumineuses peuvent être davantage partitionnées en utilisantpar.txt (fichier).

Ces stratégies de stockage (évasé, partitionné, etc.) sont efficaces lors de la recherche ou de l'accès aux données à partir d'une grande table.

Une base de données historique peut également être utilisée à des fins de reporting interne et externe, c'est-à-dire à des fins d'analyse. Par exemple, supposons que nous souhaitons obtenir les transactions de la société IBM pour un jour particulier à partir du nom de la table des échanges (ou de tout autre nom), nous devons écrire une requête comme suit -

thisday: 2014.10.12

select from trade where date = thisday, sym =`ibm

Note - Nous écrirons toutes ces requêtes une fois que nous aurons un aperçu de la q Langue.