 |
1
qihao Jan 31, 2021 via iPhone
关注
|
 |
2
ooh Jan 31, 2021
我记得我以前过关于 FQDN Issue 里面的吐槽，总结就是问题多多
|
 |
3
Finch Jan 31, 2021 via iPhone
创始人在微博挺活跃的，陶建辉
|
|
4
ooh Jan 31, 2021
|
 |
5
tairan2006 OP @ooh 怕了怕了…
|
 |
6
DoctorCat Feb 1, 2021
es 做 tsdb 有点浪费存储
|
 |
7
vinsa Feb 1, 2021
最初开源时候用过开源版，crash 多多，data 目录删过好多回。要是开源版+生产环境，慎用。
团队比较热情，联系后能上来查问题。保持良好沟通，能够避免踩坑。 不过已经若干个月过去，开源版可能已经进步巨大了。 |
 |
8
cloudhuang Feb 1, 2021
@ooh 看这个 ticket，第一感觉是这还没有到可用的地步啊 [汗]
|
|
9
tairan2006 OP @DoctorCat clickhouse 感觉不错，但是看官网希望是批量写入或者每秒一次，大量点位同时写入单条数据好像不太合适。
|
 |
10
WayneCmd Feb 1, 2021
不舍得掏钱给 influxdb，差不多就只能选择 es 了。除非你换种模式用 prometheus 。
|
|
11
tairan2006 OP @shenlanAZ influxDb 这种一个节点上万刀的真的用不起😆
|
 |
12
masterclock Feb 1, 2021
TDengine 的数据模型比较奇特，感觉没法用。
TimescaleDB 很不错，基于 pg 构建 |
 |
13
cstj0505 Feb 1, 2021
表大了 OLAP 的性能很堪忧
======= 这玩意根本就不是做 olap 的，只是用来存储时序数据 |
 |
14
Eds1995 Feb 1, 2021 via Android
试试 timescaledb 2.0 开源版包含了所有企业版特性，插入性能比 influx 高
|
|
15
tairan2006 OP |
 |
16
datafeng Feb 1, 2021
唉我部署起来也是想用 go 连的，但怎么都没跑通。
|
|
17
tairan2006 OP 我研究了一下，还是用 ES 搞了。
如果新成立的项目还是 PG+timescaledb 比较合适；我们这种已经用了 MySQL 的，还是 ES 比较合适，就是有点费钱，哈 |
Select Language