Qu'est-ce qu'une bonne conception de base de données relationnelle pour les données boursières?

Question

Supposons qu'il existe deux types de messages, de devis et de commerce.Les deux ont des champs différents.Par exemple, le commerce n'a qu'un seul prix.La citation a à la fois une offre et un prix demandé.Je veux des messages de processus dans le temps afin de faire quelque chose comme ce qui suit:

if (QUOTE) {
...
}
if (TRADE) {
...
}

Mon problème est que les deux messages sont dans différents formats, donc je ne peux pas les obtenir dans la même table de base de données.Si je ne peux pas les obtenir dans la même table de base de données, comment puis-je traiter séquentiellement?Des idées pour un design approprié?

Answer 1

La réponse dépend entièrement de ce que vous faites et sur l'endroit où votre application se connecte dans les flux de données.

À un extrême, vous pourriez simplement répondre aux devis des clients que vous tirez depuis une API et implémente essentiellement un cache.Dans ce cas, deux tables vont bien.

à l'autre extrême, vous pouvez surveiller des citations en temps réel pour une plate-forme de trading à haute fréquence, auquel cas le débit exclut probablement à l'aide d'une base de données du tout (les choses construites autour de LISP, telles que l'allégographie, pourraient être plusapproprié), sauf pour collecter périodiquement les statistiques globales.

Answer 2

La réponse courte est: "Pas vraiment" pour le marché boursier et d'autres données de la série chronologique Une valeur de valeur clé comme Berkley DB ou Mongo est plutôt bonne.En outre, un format de données tel que NetCDF (http://en.wikipedia.org/wiki/netcdf) vous servira probablement mieux à long terme.Cela dépend également de quel type d'accès vous voulez et combien de temps vous voulez stocker.

Vous n'avez pas indiqué ce que vous faisiez avec les données, qui devraient éclairer vos choix de stockage plus que tout.Par exemple, une application de négociation à grande vitesse comportera différents compromis de stockage qu'un système de traitement des lots historique (où Hadoop + NetCDF serait génial).Ymmv

Answer 3

kdb + / q

est une très bonne option pour les données de tick.Utilisé par les grandes banques.

ici est l'information à ce sujet.

Vous pouvez installer une version de piste et jouer avec elle.