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
|
