Hypertable系统涉及的日志为CommitLog和SplitLog等，日志写本地文件系统的策略约束了SplitLog的故障恢复。

    Hypertable系统设计SplitLog的初衷在于保证导入数据的速率。Range Server上的Range在分裂时，数据可以无阻塞地写入SplitLog（它必须写到分布式文件系统上，因为它保存的是实际数据），Range分裂完成后SplitLog文件可能被其他的Range Server重放。CommitLog中记录了SplitLog的位置，系统恢复时日志重放会涉及SplitLog日志的重放，如果SplitLog写在本地，那么故障恢复时就无法读取该日志。

    HBase系统中并未涉及SplitLog机制，在Range分裂时数据不能继续导入。

    解决：解决方案有两种，一种是本着稳定性和可靠性优先于性能的原则，为了保证日志的可靠性和使得自动恢复机制更简单，取消SplitLog机制，修改后的Hypertable系统在Range分裂过程不涉及SplitLog相关操作；另一种是将SplitLog写入更加可靠的共享存储中，能够让Range Server远程访问，这相当于引入了第三方系统。



优化Hypertable系统随机性能 图

Hypertable内存优化 图

Hypertable的安全停机策略

Hypertable集群故障处理

Hypertable高可用改进架构 图

Hypertable与HBase业务应用比对 图
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。