Influxdb用于财务应用程序

时间:2018-05-23 15:58:45

标签: javascript node.js influxdb stock financial

我正在将我的财务分析应用程序数据从MongoDB迁移到InfluxDB,因为数据和分析呈指数级增长。

我目前的情况是:

1)每隔一秒从交易所获取一次,并将其存储在名为“tick”的测量中;

2)每隔10秒运行一次连续查询,将这个“滴答”数据按分钟分组到一个名为“ohlc”(烛台数据)的测量中;

这就是我的怀疑..当我使用Mongo作为我的数据库时,在我得到滴答声的那一刻我已经用烛台数据转换它并计算一些指标(MACD,EMA,BB,RSI)并存储它

我看到InfluxDB有Kapacitor作为数据处理器,有一种方法可以在Kapacitor中编写一些脚本来计算这些指标,还是应该将数据流式传输到NodeJS并自己计算?

如果我必须流式传输数据,那么最佳做法是什么?

2 个答案:

答案 0 :(得分:2)

当您使用InfluxDB时,有几个选项。使用Kapacitor,您可以将任何语言中的用户定义函数合并到具有协议缓冲区支持的语言中,或者您可以编写TICKscript来执行数据转换。

您也可以使用数据库的连续查询功能,尽管根据查询和间隔,它们有时可能是昂贵的查询。

如果你想在NodeJS中编写自己的函数,你基本上只需编写一些侦听unix域套接字的代码,Kapacitor连接到该套接字,然后可以通过该套接字连接写入数据(完整文档{{3 }})。

如果你想写一个TICKscript,这里有几个例子:

// {alert_name}

// metric: {alert_metric}
// available_fields: [[other_telegraf_fields]]

// TELEGRAF CONFIGURATION
// [inputs.{plugin}]
//   # full configuration

// DEFINE: kapacitor define {alert_name} -type batch -tick 
//{plugin}/{alert_name}.tick -dbrp telegraf.autogen
// ENABLE: kapacitor enable {alert_name}

// Parameters
var info = {info_level} 
var warn = {warn_level}
var crit = {crit_level}
var infoSig = 2.5
var warnSig = 3
var critSig = 3.5
var period = 10s
var every = 10s

// Dataframe
var data = stream
  |from()
    .database('telegraf')
    .retentionPolicy('autogen')
    .measurement({plugin})
    .groupBy('host')
  |window()
    .period(period)
    .every(every)
  |mean({alert_metric})
    .as("stat")

// Thresholds
var alert = data
  |eval(lambda: sigma("stat"))
    .as('sigma')
    .keep()
  |alert()
    .id('{{ index .Tags "host"}}/{alert_metric}')
    .message('{{ .ID }}:{{ index .Fields "stat" }}')
    .info(lambda: "stat" > info OR "sigma" > infoSig)
    .warn(lambda: "stat" > warn OR "sigma" > warnSig)
    .crit(lambda: "stat" > crit OR "sigma" > critSig)

// Alert
alert
  .log('/tmp/{alert_name}_log.txt')

我希望有所帮助!

答案 1 :(得分:1)

问: InfluxDB将Kapacitor作为其数据处理器,通过编写tick脚本进行操作,将其与编写简单的NodeJS应用程序进行比较,在那里进行计算并将结果写回{ {1}}。哪个更好?

A:取决于。

这一切都归结为预计计算的复杂程度,数据量以及您是否有足够的冒险来学习influxdb脚本。

简而言之,Kapacitor绝对是一种可行的方式,因为它旨在处理复杂的计算,具有规模。它的缺点是;

  1. tick脚本具有陡峭的学习曲线
  2. 它仍然是一项相对较新的技术,如果您的计算涉及Kapacitor不支持的某些想法,那么您将需要构建自己的tick
  3. 更有可能击中未知错误
  4. 当您使用UDF时,您基本上使用其管道样式框架进行数据处理。什么是“管道”风格的东西?我不会深入研究它,但简而言之,您在Kapacitor脚本中定义的每个node都是一个连续的数据处理节点链。在执行期间,数据将以不间断的方式(对于大多数节点)同时流经单个站点以完成任务。

    这个框架也是tick如此之快的原因。

    另一方面,

    kapacitor。如果您已经熟悉它,那么基本上零时间投入学习它。 NodeJS非常简单。与Javascript脚本不同的大量引用。

    Tick最不利的是NodeJS是单线程的。也就是说,一次只能处理一个数据点或1个数据桶。如果您的计算涉及一些昂贵的计算过程,则不建议使用Javascript

    但是,如果计算是直接的单步类型,例如。 NodeJS然后你应该没事。

    NodeJS与否。我认为如果你的计算很简单,那么快速而肮脏的if X is True then: write back to influxdb as Y就应该这样做。还节省了Javascript脚本令人头疼的时间。但是请注意,如果您打算在后期进行一些疯狂的计算,那么您的tick应用程序可能无法很好地扩展。您最终可能会回到NodeJS