在当前的技术条件下,对象存储是主流的归档平台方案。从我这边做的项目来看,针对这个问题,有三种不同的处理方案。第一种是保持现有的存储架构,新添加对象存储作为归档层,从而降低现有存储的存储压力,同时为了保证访问的连续
流数据处理平台的主要特点就是把原先需要经过数据采集、数据清洗、数据分析才能得出最终结果的批处理,变成数据产生以后可以直接产生结果的流处理。流数据的应用场景还挺多的,基本上可以分为三类,数据管道类应用,事件驱动
如果底层的存储技术是对象存储的话,可以通过多版本的方式来实现数据防误删除,或者也可以通过 WORM 的功能来防止误删除和恶意删除。在病毒预防方面,对象存储在存储文件的时候是打散到不同物理节点来存放的,所以病毒文件无
我这边做过的项目里,一般迁移方案分两种,第一种是由应用进行迁移,第二种是以迁移服务项目的方式进行迁移。基本的迁移思路是新数据写入到对象存储,老的存储只用于读取,这样整个迁移的数据集就是一个固定的数据集,这样便于并
这个还是需要结合具体的业务场景来看,有的业务场景下的数据时间特性很明显,可以根据时间特性来进行区分。有的业务场景数据的冷热比较明显,也就是有些数据会被频繁访问,这些可以根据访问计数来进行区分。我这边也接触到有
一般情况下,我这边的经验是百万量级的文件。但是具体还是要看企业内部对未来IT技术路线的看法和企业的实际情况。从目前市面上成熟的存储技术来看,在海量非结构化数据的长久保存这个场景,基本上就是对象存储这个选择,因为
对象存储主要面向的是海量非结构化数据的管理,由于数量量大,导致的备份、恢复问题以及长久保存导致的数据安全性问题,对象存储都能够解决。相对于传统存储而言,数据量越大,对象存储的优势体现的越明显。从某些层面讲,对对象
总体而言,建设思路需要根据业务发展的需求、企业内部的人员知识储备、架构发展方向等综合来看。目前我看到比较多的企业采用的做法是资源池化,在基础架构层面尽量通过池化、标准化来构建存储资源池,来降低运维的难度和复
数据迁移的速度受限于源存储系统、迁移程序、网络和目标存储系统。一般情况下源存储系统会成为瓶颈,同时要保证业务能够继续对外提供服务,迁移不能对源存储系统造成压力,所以迁移的窗口都会非常长。常见的处理方法是通过
如果是将条件限定在 Hadoop 生态的话,可以考虑用下 HBASE 。但是成本不一定低,因为普遍是多副本的保护方式,所以利用率很低。我这边碰到一些客户是要从 hbase 迁移到对象存储,所以有过一些了解。当然还要考虑到运维人员的
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30