s******e
发帖数: 3 | 1 免费，开源，简单，不需要大块头，可以移植到嵌入平台（这个不是必须），同时有比
较完善的生态。
用过的请简单评价一下。
谢谢先！ |
s******e
发帖数: 3 | |
h****e
发帖数: 2125 | 3 估计你的data偏传统型，估计只有based upon PostgreSQL的TimescaleDB了吧。
【在 s******e 的大作中提到】
: 用过，各种原因，不是很满意。其他还有吗。
|
s******e
发帖数: 3 | 4 大量的各种各样的传感器数据，希望可以部署到嵌入平台和云端
【在 h****e 的大作中提到】
: 估计你的data偏传统型，估计只有based upon PostgreSQL的TimescaleDB了吧。
|
g****t
发帖数: 31659 | 5 这个我有项目。300多个传感器。response时间1秒。
开源免费的real time DB我也没有用，那些项目看着太乱了.
另外real time DB这提法本身有很多问题。
问题转化成:
满足给定时间约束的，可以处理time series的application layer。case by case写代
码处理有时间约束的那些模块。
架构不便透露。不过如果知道时间约束是作用于什么地方
，应该是比较显然的。只要把那些地方处理好，就是real time系统了。
: 大量的各种各样的传感器数据，希望可以部署到嵌入平台和云端
【在 s******e 的大作中提到】
: 大量的各种各样的传感器数据，希望可以部署到嵌入平台和云端
|
T********i
发帖数: 2416 | 6 都没用过。除了influxdb，去年还有一个开源的tdengine。挺火的。不过明显github买
粉了。
我的Iot hub主要是本地存储。api都是我自己写的。设计和别人都不一样。我是强制
schema。动态压缩。 |
T********i
发帖数: 2416 | 7 顺便介绍一下我设计的IoT Data Architecture.
1. Time series data
2. Complex structured data with AVRO
https://librehome.com/doc/developers_doc/data_api/
这玩意儿，自制一个snowlake那样的data lake也不困难。 |
s******e
发帖数: 3 | 8 赞！
【在 T********i 的大作中提到】
: 顺便介绍一下我设计的IoT Data Architecture.
: 1. Time series data
: 2. Complex structured data with AVRO
: https://librehome.com/doc/developers_doc/data_api/
: 这玩意儿，自制一个snowlake那样的data lake也不困难。
|
T********i
发帖数: 2416 | 9 我个人认为。dB不重要。你看那些所谓的DB，都是在效率和灵活性之间纠结，而且永远
都没结果。
我的DB非常简单。就是一流水帐。timestamp必须有，剩下的就是anything。这个
anything在我的系统就是binary blob。然后我选择这个binary blob是avro encoded
json。这个压缩比已经接近最大了。
其实我不认为你数据能有很多。现在cpu和memory都不值钱。你自制一个query engine
也就是几千行的事情。我理想的query engine应该是基于json path，而且 support
aggregation。这就是一万能iot数据库了。
: 赞！
【在 s******e 的大作中提到】
: 赞！
|
s******e
发帖数: 3 | 10 难度对团队有点大，我个人精力也不允许。还是选个比较靠谱的，目前还是决定回到
influxdb
engine
【在 T********i 的大作中提到】
: 我个人认为。dB不重要。你看那些所谓的DB，都是在效率和灵活性之间纠结，而且永远
: 都没结果。
: 我的DB非常简单。就是一流水帐。timestamp必须有，剩下的就是anything。这个
: anything在我的系统就是binary blob。然后我选择这个binary blob是avro encoded
: json。这个压缩比已经接近最大了。
: 其实我不认为你数据能有很多。现在cpu和memory都不值钱。你自制一个query engine
: 也就是几千行的事情。我理想的query engine应该是基于json path，而且 support
: aggregation。这就是一万能iot数据库了。
:
:
: 赞！
|
|
|
T********i
发帖数: 2416 | 11 不错的选择。你又不做平台不做生态。咋省事选哪个就好。
老中的TDEngine也要反省一下为啥很多人不敢用它的？
【在 s******e 的大作中提到】
: 难度对团队有点大，我个人精力也不允许。还是选个比较靠谱的，目前还是决定回到
: influxdb
:
: engine
|
n******t
发帖数: 4406 | 12 influxdb肯定不好用，it的support fee擺在那裏的，free的能讓你用爽了，他也不用
賺錢了。
問題是，這世界上會寫這種東西的人就那麼多，either你自己寫一個，要不被人宰，有
什麼特別的辦法麼？
【在 s******e 的大作中提到】
: 难度对团队有点大，我个人精力也不允许。还是选个比较靠谱的，目前还是决定回到
: influxdb
:
: engine
|
s******e
发帖数: 3 | 13 我是支持收费的，自己是搞软件的，有同理心。
我们目前的项目都按这个开源模式走：，先开发，运维，都规模上去，收入允许，就开
始付费，收入不行了，再退回来。
当然碰到像oracle，ibm这种模式，只能敬而远之 |
T********i
发帖数: 2416 | 14 每个开源项目都有坑。但是靠谱的项目，都是几十行就能解决的。也就是99%人家都给
帮你做好了。给别人找麻烦也是给自己找麻烦。反正，迄今为止，我用过的开源项目，
没有100行以内解决不了的。
那些开源的，不管多少万行，在我这里都是透明的。我看到的是一个由架构和函数组成
的源代码portfolio。
【在 s******e 的大作中提到】
: 我是支持收费的，自己是搞软件的，有同理心。
: 我们目前的项目都按这个开源模式走：，先开发，运维，都规模上去，收入允许，就开
: 始付费，收入不行了，再退回来。
: 当然碰到像oracle，ibm这种模式，只能敬而远之
|
l*******m
发帖数: 1096 | 15 我好奇看了一眼tdegine, 有两个人说并发插入数据，表里数据count还会减少。估计追
求性能，一些基本的数据可靠性可能都有问题。快慢总可以解决，数据出错就是重大事故
：不错的选择。你又不做平台不做生态。咋省事选哪个就好。
： |
n******t
发帖数: 4406 | 16 我沒覺得oracle，ibm的收費和influxdb這種有什麼本質區別。至少不用你當免費測試
員。價格，都是一個字貴。
問題是你如果是搞軟件的，你意思是你會寫production level的代碼？那自己寫一個好
了，否則至少要知道怎麼改。99%的像influxdb這種僞開源的情況，比哭着求別人
support解決問題靠譜。
IBM的問題是，你不是大客戶都不會理你。所以你也不操心他靠不靠譜。
【在 s******e 的大作中提到】
: 我是支持收费的，自己是搞软件的，有同理心。
: 我们目前的项目都按这个开源模式走：，先开发，运维，都规模上去，收入允许，就开
: 始付费，收入不行了，再退回来。
: 当然碰到像oracle，ibm这种模式，只能敬而远之
|
n******t
发帖数: 4406 | 17 一個開源的東西如果全是benchmark說自己多塊，一定要小心。
尤其這種成品，如果成熟穩定，還快，同時還有各種功能了，爲什麼要開源？很大可能
就是特殊情況下的一些benchmark讓你上鉤，當免費測試員的。
事故
【在 l*******m 的大作中提到】
: 我好奇看了一眼tdegine, 有两个人说并发插入数据，表里数据count还会减少。估计追
: 求性能，一些基本的数据可靠性可能都有问题。快慢总可以解决，数据出错就是重大事故
:
: ：不错的选择。你又不做平台不做生态。咋省事选哪个就好。
: ：
|
s******e
发帖数: 3 | 18 15年前，所在公司用AIX系统，半夜一个问题，一条命令可以自己解决，但ibm合同规定
，必须通过他们，方式如下：打电话，印度大妈用咖喱味英语问情况，然后让我干等，
她在另外的线上找我们当地的engineer，搞不定，让他直接找我，问明情况，用我提供
的命令解决。每小时收费1500刀。
另有一个case，某电信公司，几年前的oracle weblogic 授权费用超过100M，support
基本为零，他们的jdbc bug，我们自己发现，自己绕过，补丁等好几个月。
influxdb oss under MIT，企业版和云平台收费。
【在 n******t 的大作中提到】
: 我沒覺得oracle，ibm的收費和influxdb這種有什麼本質區別。至少不用你當免費測試
: 員。價格，都是一個字貴。
: 問題是你如果是搞軟件的，你意思是你會寫production level的代碼？那自己寫一個好
: 了，否則至少要知道怎麼改。99%的像influxdb這種僞開源的情況，比哭着求別人
: support解決問題靠譜。
: IBM的問題是，你不是大客戶都不會理你。所以你也不操心他靠不靠譜。
|
s******e
发帖数: 3 | 19 我早想说了，某些开源，图个名气，文档、测试、更新、支持完全不在线，有选择还是
别选它
【在 T********i 的大作中提到】
: 不错的选择。你又不做平台不做生态。咋省事选哪个就好。
: 老中的TDEngine也要反省一下为啥很多人不敢用它的？
|
T********i
发帖数: 2416 | 20 开源做好了，是一个巨大的社会工程。
这方面，秦人差的还远。
我又仔细看了一下。InfluxDB的设计还是靠谱的。文档还是能够表现出诚意的。
【在 s******e 的大作中提到】
: 我早想说了，某些开源，图个名气，文档、测试、更新、支持完全不在线，有选择还是
: 别选它
|
|
|
n******t
发帖数: 4406 | 21 你說的這些我當然知道。有一件事你可能沒想明白，你說的情況不是oracle和ibm，而
是你的“所在公司“想要達成的效果。
這件事在美國公司的情況基本無解，influxdb也是一樣的。這麼說把，假如你在這種大
公司裏面是負責time series db的，你自己沒有開發修改源代碼的能力，你經過評選選
定了influxdb，現在有個小弟能夠把這個東西的bug給解決了，你讓他搞，幾天解決問
題，還是一年給800K給influxdb，讓他們不快不慢地搞，問題可能只解決一點點，明年
再給800K？
你應該很清楚你會怎麼做，那麼你也就應該知道並不是哪個vendor的事情，自由市場裏
面vendor的表現很大程度上是被client決定的。
support
【在 s******e 的大作中提到】
: 15年前，所在公司用AIX系统，半夜一个问题，一条命令可以自己解决，但ibm合同规定
: ，必须通过他们，方式如下：打电话，印度大妈用咖喱味英语问情况，然后让我干等，
: 她在另外的线上找我们当地的engineer，搞不定，让他直接找我，问明情况，用我提供
: 的命令解决。每小时收费1500刀。
: 另有一个case，某电信公司，几年前的oracle weblogic 授权费用超过100M，support
: 基本为零，他们的jdbc bug，我们自己发现，自己绕过，补丁等好几个月。
: influxdb oss under MIT，企业版和云平台收费。
|
s******e
发帖数: 3 | 22 同意你的观点。
但influxdb和elk的模式我觉得还行，社区支持还挺及时，主要用得人多。另外在上规
模之前免费，上规模后看情况，真搞大了，也有钱请的大拿自己弄。我记得很多大厂都
是这个路数起来的。
【在 n******t 的大作中提到】
: 你說的這些我當然知道。有一件事你可能沒想明白，你說的情況不是oracle和ibm，而
: 是你的“所在公司“想要達成的效果。
: 這件事在美國公司的情況基本無解，influxdb也是一樣的。這麼說把，假如你在這種大
: 公司裏面是負責time series db的，你自己沒有開發修改源代碼的能力，你經過評選選
: 定了influxdb，現在有個小弟能夠把這個東西的bug給解決了，你讓他搞，幾天解決問
: 題，還是一年給800K給influxdb，讓他們不快不慢地搞，問題可能只解決一點點，明年
: 再給800K？
: 你應該很清楚你會怎麼做，那麼你也就應該知道並不是哪個vendor的事情，自由市場裏
: 面vendor的表現很大程度上是被client決定的。
:
|
d*******r
发帖数: 3299 | 23 ELK以前用过, 真是难用...
所以对influxDB这种，也应该持谨慎态度, 虽然我还没用过它.
其实这些开源项目折腾多了，最后会感慨，确实是自己实现最好.
不过给人打工的话，就不太敢自己去实现.
打工的时候，其实选个"当前著名开源项目",
有点政治正确的意思在里面，而且马上能弄点东西出来交差,
但是这样搞的 tech debt 其实很大...
一言难尽 |
T********i
发帖数: 2416 | 24 大家应该多从楼主的角度看问题。
我认为目前楼主的目标就是把数据存好，管起来。
而且数据量根本不大。
给你一天时间，让你拿出一个方案出来。答案不是明摆着么？
所以楼主选择是最优的。这世界谁也不傻。
至于过来发帖求推荐，属于骑驴找马而已。
我认为，influxdb，对于楼主的要求，属于overkill，只要能稳定运行就好。这个要求
其实不高。我想楼主已经达到了。
一旦稳定运行，最大的风险，反倒是版本升级。同时也是成本。但那是另外的问题。
: ELK以前用过, 真是难用...
: 所以对influxDB这种，也应该持谨慎态度, 虽然我还没用过它.
: 其实这些开源项目折腾多了，最后会感慨，确实是自己实现最好.
: 不过给人打工的话，就不太敢自己去实现.
: 打工的时候，其实选个"当前著名开源项目",
: 有点政治正确的意思在里面，而且马上能弄点东西出来交差,
: 但是这样搞的 tech debt 其实很大...
: 一言难尽
【在 d*******r 的大作中提到】
: ELK以前用过, 真是难用...
: 所以对influxDB这种，也应该持谨慎态度, 虽然我还没用过它.
: 其实这些开源项目折腾多了，最后会感慨，确实是自己实现最好.
: 不过给人打工的话，就不太敢自己去实现.
: 打工的时候，其实选个"当前著名开源项目",
: 有点政治正确的意思在里面，而且马上能弄点东西出来交差,
: 但是这样搞的 tech debt 其实很大...
: 一言难尽
|
s******e
发帖数: 3 | 25 基本就是这样。另外如果自己写，这种类型的工作，基本就是我一个干，还要持续维护
，本人能力精力有限。
【在 T********i 的大作中提到】
: 大家应该多从楼主的角度看问题。
: 我认为目前楼主的目标就是把数据存好，管起来。
: 而且数据量根本不大。
: 给你一天时间，让你拿出一个方案出来。答案不是明摆着么？
: 所以楼主选择是最优的。这世界谁也不傻。
: 至于过来发帖求推荐，属于骑驴找马而已。
: 我认为，influxdb，对于楼主的要求，属于overkill，只要能稳定运行就好。这个要求
: 其实不高。我想楼主已经达到了。
: 一旦稳定运行，最大的风险，反倒是版本升级。同时也是成本。但那是另外的问题。
:
|
n******t
发帖数: 4406 | 26 influxDB的最大問題是查詢不是standard的sql，如果dev用了這個接口一旦上了規模想
換就要和一堆人打架。
至於上了規模這東西試試就知道了，肯定是不好用的。問題是規模小的時候，裝個
whatever database都行了.
【在 d*******r 的大作中提到】
: ELK以前用过, 真是难用...
: 所以对influxDB这种，也应该持谨慎态度, 虽然我还没用过它.
: 其实这些开源项目折腾多了，最后会感慨，确实是自己实现最好.
: 不过给人打工的话，就不太敢自己去实现.
: 打工的时候，其实选个"当前著名开源项目",
: 有点政治正确的意思在里面，而且马上能弄点东西出来交差,
: 但是这样搞的 tech debt 其实很大...
: 一言难尽
|
T********i
发帖数: 2416 | 27 就像我说的，DB根本不重要。这个数据库你想migrate到其它任何数据库上，就是一个
select all和bulk insert的问题。能有100行代码么？
等数据库重要的时候，你的business都不知道值多少钱了？到那时候，就更加不是事儿
了。即使烦恼也是幸福的烦恼。
这帮说这不好那不好的，敢说influxdb不能稳定运行么？能稳定运行设置后不用管，就
够了。
再说我的那个MySQL，费老大劲设置了一个双机backup。还要操心如果双机都死咋办？
MySQL remote backup简直不是人干的。貌似要搞好还要花钱。即使花钱，也是太麻烦。
花了3个钟头做了个flat file backup，就高枕无忧了。直接rsync都能backup。仰天大
笑。。。
【在 s******e 的大作中提到】
: 基本就是这样。另外如果自己写，这种类型的工作，基本就是我一个干，还要持续维护
: ，本人能力精力有限。
|
g****t
发帖数: 31659 | 28 如果是时间序列数据，做个monitoring dashborad画图什么的。inlufxDB社区活跃，找
个tutorial什么的容易。配套的Grafans什么的有现成的。细节不用自己处理。
【在 n******t 的大作中提到】
: influxDB的最大問題是查詢不是standard的sql，如果dev用了這個接口一旦上了規模想
: 換就要和一堆人打架。
: 至於上了規模這東西試試就知道了，肯定是不好用的。問題是規模小的時候，裝個
: whatever database都行了.
|
s******e
发帖数: 3 | 29 的确是这么考虑的。
【在 g****t 的大作中提到】
: 如果是时间序列数据，做个monitoring dashborad画图什么的。inlufxDB社区活跃，找
: 个tutorial什么的容易。配套的Grafans什么的有现成的。细节不用自己处理。
|
g****t
发帖数: 31659 | 30 如果时间不是很紧迫。我会考虑弄个简单的wrapper,和specific DB绑定稍微松一些，
也防止未来它和java的接口改了。开源项目有碰到过半年不到改版本，改接口的。
【在 s******e 的大作中提到】
: 的确是这么考虑的。
|
|
|
n******t
发帖数: 4406 | 31 對的，exactly influxdb的優勢在安裝畫圖這些事情上面。
但是如果是長期穩定的服務，這些工作量其實都是k/n+k的部分。（k是常數）.如果是
一竿子買賣我覺得還是用個mysql,postgres這種穩妥的。
至於社區活躍度其實沒用，influxdb的社區的人有個特點就是沒有開發能力，也對
influxdb代碼沒有影響力。所以你有什麼事情，除非是安裝配置之類的，都是一羣人在
哪裏求幫助,一個具體問題一堆人在哪裏哭喊了半天，沒人理一陣子就涼了。其實有時
候就是一行代碼的問題。
【在 g****t 的大作中提到】
: 如果是时间序列数据，做个monitoring dashborad画图什么的。inlufxDB社区活跃，找
: 个tutorial什么的容易。配套的Grafans什么的有现成的。细节不用自己处理。
|
n******t
发帖数: 4406 | 32 這個是應該搞的，如果一定要用influxdb這種東西。
但是我的個人經驗，這種本來用它就是爲了快糙猛的， 也不會花時間去幹這件事。
【在 g****t 的大作中提到】
: 如果时间不是很紧迫。我会考虑弄个简单的wrapper,和specific DB绑定稍微松一些，
: 也防止未来它和java的接口改了。开源项目有碰到过半年不到改版本，改接口的。
|
w********m
发帖数: 1137 | 33 influxdb应该不错的
就是那个query dsl太难看了
老陶的TDengine就比较聪明，直接用sql
不过现在用C写后台的年代已经过去了
现在做开源的话
time series DB是个好方向
市场很大 |
w********m
发帖数: 1137 | 34 云上的话，可以用elasticsearch
这是最成熟的方案，十几年了
楼上说难用
哪里难用 |
d*******r
发帖数: 3299 | 35 好用，难维护，没事儿就崩
【在 w********m 的大作中提到】
: 云上的话，可以用elasticsearch
: 这是最成熟的方案，十几年了
: 楼上说难用
: 哪里难用
|
w********m
发帖数: 1137 | 36 java程序都吃内存
你把内存管足
就没事了
【在 d*******r 的大作中提到】
: 好用，难维护，没事儿就崩
|
s******e
发帖数: 3 | 37 常规使用，几乎就是一个helm chart的部署，没啥工作，但要注意留出足够磁盘，否则
就会有点麻烦，另外做日志处理，需要定期清理。
高端使用，作为NoSql数据库和全文索引使用，里面道道还是很多的，用好了，性能和
内存、存储差别还是很大的。
【在 w********m 的大作中提到】
: java程序都吃内存
: 你把内存管足
: 就没事了
|
s*********y
发帖数: 6151 | 38 时序数据库InfluxDB或Prometheus (Numeric data only )
谁推荐Elastic的歇歇吧 不是时序数据库 是search engine (full text search) 应
用场景不一样 当然不会好用了 |
w********m
发帖数: 1137 | 39 tsdb跟一般数据库的区别就是
能不能设置retention policy
能不能做downsampling |
c*******v
发帖数: 2599 | 40 My two cents:
time series是EE的內容。所謂的tsdb概念上不成熟。應用有便利可以用。
其他情況，跳坑要慎重。
【在 w********m 的大作中提到】
: tsdb跟一般数据库的区别就是
: 能不能设置retention policy
: 能不能做downsampling
|
|
|
w******w
发帖数: 126 | 41 请教一下魏老师，对于数据库的备份。可否用现成的那种市场上 backup restore 文件
的产品。
直接去备份数据库相应的文件呢？
那样是不是更安全？
当然那个是需要花银子的 ， 但是不知道是否比数据库本身的backup 更便宜些。
记着这样的产品是按照备份的文件大小来收费的。
烦。
【在 T********i 的大作中提到】
: 就像我说的，DB根本不重要。这个数据库你想migrate到其它任何数据库上，就是一个
: select all和bulk insert的问题。能有100行代码么？
: 等数据库重要的时候，你的business都不知道值多少钱了？到那时候，就更加不是事儿
: 了。即使烦恼也是幸福的烦恼。
: 这帮说这不好那不好的，敢说influxdb不能稳定运行么？能稳定运行设置后不用管，就
: 够了。
: 再说我的那个MySQL，费老大劲设置了一个双机backup。还要操心如果双机都死咋办？
: MySQL remote backup简直不是人干的。貌似要搞好还要花钱。即使花钱，也是太麻烦。
: 花了3个钟头做了个flat file backup，就高枕无忧了。直接rsync都能backup。仰天大
: 笑。。。
|
T********i
发帖数: 2416 | 42 有现成的commercial tool，肯定要无脑用啊。尤其是公司。
问题是TSDB本来就是小众产品。哪里有migration tool？所以我说自己写一个，也不过
百八十行。
当然，migration是要有plan的，关键就是minimize servie disruption。那是细节问
题了。具体问题要具体分析。
【在 w******w 的大作中提到】
: 请教一下魏老师，对于数据库的备份。可否用现成的那种市场上 backup restore 文件
: 的产品。
: 直接去备份数据库相应的文件呢？
: 那样是不是更安全？
: 当然那个是需要花银子的 ， 但是不知道是否比数据库本身的backup 更便宜些。
: 记着这样的产品是按照备份的文件大小来收费的。
:
: 烦。
|
w******w
发帖数: 126 | 43 明白了，谢谢解答！
【在 T********i 的大作中提到】
: 有现成的commercial tool，肯定要无脑用啊。尤其是公司。
: 问题是TSDB本来就是小众产品。哪里有migration tool？所以我说自己写一个，也不过
: 百八十行。
: 当然，migration是要有plan的，关键就是minimize servie disruption。那是细节问
: 题了。具体问题要具体分析。
|
n******t
发帖数: 4406 | 44 我就問一下，你用過influxdb沒？
烦。
【在 T********i 的大作中提到】
: 就像我说的，DB根本不重要。这个数据库你想migrate到其它任何数据库上，就是一个
: select all和bulk insert的问题。能有100行代码么？
: 等数据库重要的时候，你的business都不知道值多少钱了？到那时候，就更加不是事儿
: 了。即使烦恼也是幸福的烦恼。
: 这帮说这不好那不好的，敢说influxdb不能稳定运行么？能稳定运行设置后不用管，就
: 够了。
: 再说我的那个MySQL，费老大劲设置了一个双机backup。还要操心如果双机都死咋办？
: MySQL remote backup简直不是人干的。貌似要搞好还要花钱。即使花钱，也是太麻烦。
: 花了3个钟头做了个flat file backup，就高枕无忧了。直接rsync都能backup。仰天大
: 笑。。。
|
n******t
发帖数: 4406 | 45 你知道別人在問什麼嗎？
還“具體問題具體分析“，你可以去當個售前，可以的。
文件
【在 T********i 的大作中提到】
: 有现成的commercial tool，肯定要无脑用啊。尤其是公司。
: 问题是TSDB本来就是小众产品。哪里有migration tool？所以我说自己写一个，也不过
: 百八十行。
: 当然，migration是要有plan的，关键就是minimize servie disruption。那是细节问
: 题了。具体问题要具体分析。
|
T********i
发帖数: 2416 | 46 你已经变成一个烂人了。pick up这种无趣的fight。
这样下去，你看看还有几个人搭理你？
【在 n******t 的大作中提到】
: 你知道別人在問什麼嗎？
: 還“具體問題具體分析“，你可以去當個售前，可以的。
:
: 文件
|
n******t
发帖数: 4406 | 47 對於大部分數據庫most likely直接備份數據庫文件是不work的，你基本上肯定會遇到
data corrpution。即使要用那種備份文件的tool，也最好先用數據庫自帶的export
data的tool先導出文件再用那些tool來備份。
不过
节问
【在 w******w 的大作中提到】
: 明白了，谢谢解答！
|
n******t
发帖数: 4406 | 48 別激動，就是看你瞎忽悠看不下去了而已。
【在 T********i 的大作中提到】
: 你已经变成一个烂人了。pick up这种无趣的fight。
: 这样下去，你看看还有几个人搭理你？
|
s******e
发帖数: 3 | 49 我来分享一点自己过往的经验，补全一点RDBMS数据库备份的各种情况：
1）数据库可以直接使用设备做存储的，完全不依赖文件系统，现在这种情况比较少了
，这个时候，备份其实就是备份那个设备里的全部数据。
2）备份有“物理/Raw”、“逻辑”备份的区别。物理备份就是你说的把数据库文件直
接备份，逻辑备份一般是人或程序可读的方式，比如Mysql的逻辑备份就是大量的SQL语
句。逻辑备份一般需要数据库运行，但也有停机后备份的例子。
3）备份有热备份，冷备份的区别，冷备份就是停机备份，不影响业务运行的备份就是
热备份。过去，当我们讲冷、热备份时，一般指物理备份。
无论使用设备文件还是普通OS文件做数据库存储，一般都是停机做冷备份，运行时做逻
辑备份。但是，企业级的数据库都支持联机热备份，并且能够保证数据库的完整性和一
致性。我知道MySQL、Oracle、PostgreSQL都可以，其他的了解不多，但凡是被大规模
应用的，都应该具备这个企业级功能。另外如果使用了SAN存储，很多数据库软件和SAN
有联动，可以在存储层使用snapshot等技术实现热备份。存储层的snapshot在冷备份里
也可以使用，可以极大缩短数据库停机时间。
数据备份不是只有上面讲的形式，还有其他方式，尤其在NoSQL领域，一些超大规模的
NoSQL数据,几百TB或上PB的数据，做常规备份是不现实的，就是是用最好的磁带机或
SSD也不可能在合理的时间内完成备份任务。所以就有一些备份的“替代方案”
1）主从复制 - 跨数据中心的主从复制，设置一个备份集群，把生产集群上的数据，尽
快复制到备份集群。比如Hbase的文档，就是建议建立备份集群做替代。
2）跨数据中心的分片复制集群（replica），还是以hbase为例，hbase可以指定
replica factor 为3，5，7...,并且利用rack awareness 技术，指定每个碎片必须分
布在不同的rack/host/data center。
但这些做法有一个问题，就是需要解决程序逻辑造成的数据恢复问题：有时需要回滚一
个表到过去某个时刻的状态。这个技术在NoSQL平台上是有实现的，一般通过table
snapshot实现。像snowflake等公司的平台，甚至可以保留历史数据，在select时，使
用时间戳就可以查询到那个时间的数据。这种情况下，再加上集群分片复制，有没有备
份其实意义不大了。
【在 w******w 的大作中提到】
: 明白了，谢谢解答！
|
s******e
发帖数: 3 | 50 再补充一点，利用存储层的snapshot在做人备份，一般适用于单价，或多机但单一存储
的情况。在集群分片数据库模式下，我个人没有使用过，不确定。
另外，像hbase，为追求性能，文档建议不要用LVM，那么存储层的snapshot就不可用。 |
