c********a 发帖数: 244 | 1 relational database not efficient.
大家有用hbase opentsdb 的吗?
先说说我们现在的方法:
我们把序列数据放到数据库binary field 里。
太不方便了。
能不能讨论大家是怎末解决这问题的? |
J*****n 发帖数: 4859 | 2 why, binary file should be the best way, considering time cost. |
Y******u 发帖数: 1912 | 3 binary怎么读中间一小段?或者update中间的数据?
【在 J*****n 的大作中提到】 : why, binary file should be the best way, considering time cost.
|
c********a 发帖数: 244 | 4 We update the whole history for that particular id...
【在 Y******u 的大作中提到】 : binary怎么读中间一小段?或者update中间的数据?
|
c********a 发帖数: 244 | 5 hbase opentsdb looks interesting. I am curious if anyone has had experience
that he feels like sharing.
【在 J*****n 的大作中提到】 : why, binary file should be the best way, considering time cost.
|
k***g 发帖数: 7244 | 6 column based db, such as kdb or R+mmap+indexing.
kdb is the industry standard for electronic trading.
【在 c********a 的大作中提到】 : relational database not efficient. : 大家有用hbase opentsdb 的吗? : 先说说我们现在的方法: : 我们把序列数据放到数据库binary field 里。 : 太不方便了。 : 能不能讨论大家是怎末解决这问题的?
|
c********a 发帖数: 244 | 7 kdb is a great choice. Thanks kzeng.
Would you elaborate a little bit more on R+mmap+indexing?
I think I understand the R+mmap part. How do I add index in that picture?
Thanks again.
【在 k***g 的大作中提到】 : column based db, such as kdb or R+mmap+indexing. : kdb is the industry standard for electronic trading.
|
J*****n 发帖数: 4859 | 8
Frankly speaking, Onetick is more friendly use and speed is even faster than
kdb.
【在 k***g 的大作中提到】 : column based db, such as kdb or R+mmap+indexing. : kdb is the industry standard for electronic trading.
|
c********a 发帖数: 244 | 9 谢谢长得帅。
onetick 除了贵, 有啥别的缺点吗?
than
【在 J*****n 的大作中提到】 : : Frankly speaking, Onetick is more friendly use and speed is even faster than : kdb.
|
k*******d 发帖数: 1340 | 10 每个entry都一样长度的话还是可以的,直接seek。
HDF5估计不行
【在 Y******u 的大作中提到】 : binary怎么读中间一小段?或者update中间的数据?
|
|
|
J*****n 发帖数: 4859 | 11
似乎没有。不过我也不是数据专家。
只是觉得kdb其实很难用。似乎有些大公司开始转用onetick了。
现在是云时代,只要你能把任务分的够独立,用啥语言,工具都差不多。
【在 c********a 的大作中提到】 : 谢谢长得帅。 : onetick 除了贵, 有啥别的缺点吗? : : than
|
c********a 发帖数: 244 | 12 谢谢指点。
【在 J*****n 的大作中提到】 : : 似乎没有。不过我也不是数据专家。 : 只是觉得kdb其实很难用。似乎有些大公司开始转用onetick了。 : 现在是云时代,只要你能把任务分的够独立,用啥语言,工具都差不多。
|
n****n 发帖数: 59 | 13 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现
有要求,并(最好)能前瞻将来的需要。
我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如
relational database (存储+一些挺好的轮子)+ OO (user defined types/methods
,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人
,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是
高频,主要目标是backtest的灵活和透明。
我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用
需求,要想利其器,还得靠自己DIY. |
c********a 发帖数: 244 | 14 谢谢指点。
>database (存储+一些挺好的轮子)
这个能展开说说吗?
methods
【在 n****n 的大作中提到】 : 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现 : 有要求,并(最好)能前瞻将来的需要。 : 我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如 : relational database (存储+一些挺好的轮子)+ OO (user defined types/methods : ,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人 : ,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是 : 高频,主要目标是backtest的灵活和透明。 : 我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用 : 需求,要想利其器,还得靠自己DIY.
|
k*******d 发帖数: 1340 | 15 Onetick/KDB不是通用的,而是专门为tick market data设计的,相比之下relational
db才是通用的。SQL只适合存低频的数据
methods
【在 n****n 的大作中提到】 : 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现 : 有要求,并(最好)能前瞻将来的需要。 : 我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如 : relational database (存储+一些挺好的轮子)+ OO (user defined types/methods : ,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人 : ,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是 : 高频,主要目标是backtest的灵活和透明。 : 我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用 : 需求,要想利其器,还得靠自己DIY.
|
w**********y 发帖数: 1691 | 16 有没有懂行的来说说mmap 看介绍很强大
relational
【在 k*******d 的大作中提到】 : Onetick/KDB不是通用的,而是专门为tick market data设计的,相比之下relational : db才是通用的。SQL只适合存低频的数据 : : methods
|
k*******d 发帖数: 1340 | 17 memory map file? 用途很多,本身不能作为数据库用,但是有数据库用了它,据说性
能挺好的。
【在 w**********y 的大作中提到】 : 有没有懂行的来说说mmap 看介绍很强大 : : relational
|
n******t 发帖数: 4406 | 18 对于不会写程序的人来说,是个多快好省访问文件的办法。
【在 w**********y 的大作中提到】 : 有没有懂行的来说说mmap 看介绍很强大 : : relational
|
w**********y 发帖数: 1691 | 19 喝喝.那正符合我的要求
【在 n******t 的大作中提到】 : 对于不会写程序的人来说,是个多快好省访问文件的办法。
|
n****n 发帖数: 59 | 20 存储其实还是 table normalisation,data integrity等。
在用之前还是先读取转换成便于使用的时间序列格式。
轮子就是自带的
index and performance tuning tool;
row/table locking updating;
some built-in functions
column store 应该也是蛮有用的,不过还没深入了解.
【在 c********a 的大作中提到】 : 谢谢指点。 : >database (存储+一些挺好的轮子) : 这个能展开说说吗? : : methods
|
|
|
c********a 发帖数: 244 | 21 谢了。 这个用 table, normalized or not, 来储存序列数据, 对我总感觉别扭。
不过还是谢谢你的指点。
【在 n****n 的大作中提到】 : 存储其实还是 table normalisation,data integrity等。 : 在用之前还是先读取转换成便于使用的时间序列格式。 : 轮子就是自带的 : index and performance tuning tool; : row/table locking updating; : some built-in functions : column store 应该也是蛮有用的,不过还没深入了解.
|
c********a 发帖数: 244 | 22 relational database not efficient.
大家有用hbase opentsdb 的吗?
先说说我们现在的方法:
我们把序列数据放到数据库binary field 里。
太不方便了。
能不能讨论大家是怎末解决这问题的? |
J*****n 发帖数: 4859 | 23 why, binary file should be the best way, considering time cost. |
Y******u 发帖数: 1912 | 24 binary怎么读中间一小段?或者update中间的数据?
【在 J*****n 的大作中提到】 : why, binary file should be the best way, considering time cost.
|
c********a 发帖数: 244 | 25 We update the whole history for that particular id...
【在 Y******u 的大作中提到】 : binary怎么读中间一小段?或者update中间的数据?
|
c********a 发帖数: 244 | 26 hbase opentsdb looks interesting. I am curious if anyone has had experience
that he feels like sharing.
【在 J*****n 的大作中提到】 : why, binary file should be the best way, considering time cost.
|
k***g 发帖数: 7244 | 27 column based db, such as kdb or R+mmap+indexing.
kdb is the industry standard for electronic trading.
【在 c********a 的大作中提到】 : relational database not efficient. : 大家有用hbase opentsdb 的吗? : 先说说我们现在的方法: : 我们把序列数据放到数据库binary field 里。 : 太不方便了。 : 能不能讨论大家是怎末解决这问题的?
|
c********a 发帖数: 244 | 28 kdb is a great choice. Thanks kzeng.
Would you elaborate a little bit more on R+mmap+indexing?
I think I understand the R+mmap part. How do I add index in that picture?
Thanks again.
【在 k***g 的大作中提到】 : column based db, such as kdb or R+mmap+indexing. : kdb is the industry standard for electronic trading.
|
J*****n 发帖数: 4859 | 29
Frankly speaking, Onetick is more friendly use and speed is even faster than
kdb.
【在 k***g 的大作中提到】 : column based db, such as kdb or R+mmap+indexing. : kdb is the industry standard for electronic trading.
|
c********a 发帖数: 244 | 30 谢谢长得帅。
onetick 除了贵, 有啥别的缺点吗?
than
【在 J*****n 的大作中提到】 : : Frankly speaking, Onetick is more friendly use and speed is even faster than : kdb.
|
|
|
k*******d 发帖数: 1340 | 31 每个entry都一样长度的话还是可以的,直接seek。
HDF5估计不行
【在 Y******u 的大作中提到】 : binary怎么读中间一小段?或者update中间的数据?
|
J*****n 发帖数: 4859 | 32
似乎没有。不过我也不是数据专家。
只是觉得kdb其实很难用。似乎有些大公司开始转用onetick了。
现在是云时代,只要你能把任务分的够独立,用啥语言,工具都差不多。
【在 c********a 的大作中提到】 : 谢谢长得帅。 : onetick 除了贵, 有啥别的缺点吗? : : than
|
c********a 发帖数: 244 | 33 谢谢指点。
【在 J*****n 的大作中提到】 : : 似乎没有。不过我也不是数据专家。 : 只是觉得kdb其实很难用。似乎有些大公司开始转用onetick了。 : 现在是云时代,只要你能把任务分的够独立,用啥语言,工具都差不多。
|
n****n 发帖数: 59 | 34 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现
有要求,并(最好)能前瞻将来的需要。
我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如
relational database (存储+一些挺好的轮子)+ OO (user defined types/methods
,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人
,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是
高频,主要目标是backtest的灵活和透明。
我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用
需求,要想利其器,还得靠自己DIY. |
c********a 发帖数: 244 | 35 谢谢指点。
>database (存储+一些挺好的轮子)
这个能展开说说吗?
methods
【在 n****n 的大作中提到】 : 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现 : 有要求,并(最好)能前瞻将来的需要。 : 我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如 : relational database (存储+一些挺好的轮子)+ OO (user defined types/methods : ,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人 : ,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是 : 高频,主要目标是backtest的灵活和透明。 : 我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用 : 需求,要想利其器,还得靠自己DIY.
|
k*******d 发帖数: 1340 | 36 Onetick/KDB不是通用的,而是专门为tick market data设计的,相比之下relational
db才是通用的。SQL只适合存低频的数据
methods
【在 n****n 的大作中提到】 : 抛块砖吧。在我看来这是个IT/data架构的问题,所以先要分析需求。(尽量)满足现 : 有要求,并(最好)能前瞻将来的需要。 : 我们是用商用软件做二次开发。也就是把优秀的思想嫁接起来自己搞一套。比如 : relational database (存储+一些挺好的轮子)+ OO (user defined types/methods : ,透明,便于维护)+ vectorised stuff (类似R的东东, performance).说得唬人 : ,其实只要想通了,开发还是挺简单的。当然也许是我们要求简单,产品单一,也不是 : 高频,主要目标是backtest的灵活和透明。 : 我没接触过onetick,Kdb等,所以井底之见啦。我觉得off shelf的东西多数照顾通用 : 需求,要想利其器,还得靠自己DIY.
|
w**********y 发帖数: 1691 | 37 有没有懂行的来说说mmap 看介绍很强大
relational
【在 k*******d 的大作中提到】 : Onetick/KDB不是通用的,而是专门为tick market data设计的,相比之下relational : db才是通用的。SQL只适合存低频的数据 : : methods
|
k*******d 发帖数: 1340 | 38 memory map file? 用途很多,本身不能作为数据库用,但是有数据库用了它,据说性
能挺好的。
【在 w**********y 的大作中提到】 : 有没有懂行的来说说mmap 看介绍很强大 : : relational
|
n******t 发帖数: 4406 | 39 对于不会写程序的人来说,是个多快好省访问文件的办法。
【在 w**********y 的大作中提到】 : 有没有懂行的来说说mmap 看介绍很强大 : : relational
|
w**********y 发帖数: 1691 | 40 喝喝.那正符合我的要求
【在 n******t 的大作中提到】 : 对于不会写程序的人来说,是个多快好省访问文件的办法。
|
|
|
n****n 发帖数: 59 | 41 存储其实还是 table normalisation,data integrity等。
在用之前还是先读取转换成便于使用的时间序列格式。
轮子就是自带的
index and performance tuning tool;
row/table locking updating;
some built-in functions
column store 应该也是蛮有用的,不过还没深入了解.
【在 c********a 的大作中提到】 : 谢谢指点。 : >database (存储+一些挺好的轮子) : 这个能展开说说吗? : : methods
|
c********a 发帖数: 244 | 42 谢了。 这个用 table, normalized or not, 来储存序列数据, 对我总感觉别扭。
不过还是谢谢你的指点。
【在 n****n 的大作中提到】 : 存储其实还是 table normalisation,data integrity等。 : 在用之前还是先读取转换成便于使用的时间序列格式。 : 轮子就是自带的 : index and performance tuning tool; : row/table locking updating; : some built-in functions : column store 应该也是蛮有用的,不过还没深入了解.
|
l********g 发帖数: 18 | |
e*****r 发帖数: 700 | 44 看了Cassandra,貌似存time series也不错。
★ 发自iPhone App: ChineseWeb 8.6
【在 l********g 的大作中提到】 : use pandas in python
|