1万属性，100亿数据，每秒10万吞吐，架构怎样计划？

(3)搜刮内核检索层，处事和索引数据陈设在统一台呆板上，处事启动时可以加载索引数据到内存，哀求会见时从内存中load数据，会见速率很快：

• 为了满意数据容量的扩展性，索引数据举办了程度切分，增进切分份数，就可以或许无穷扩展机能
• 为了满意一份数据的机能扩展性，统一份数据举办了冗余，理论上做到增进呆板就无穷扩展机能

体系时延，100亿级别帖子检索，包括哀求分合，拉链求交集，从聚合层均可以做到10ms返回。

画外音：进口层是Java研发的，聚合层与检索层都是C说话研发的。

帖子营业，同等性不是首要抵牾，E-search会按期全量重建索引，以担保纵然数据纷歧致，也不会一连很长的时刻。

五、总结

文章写了很长，最后做一个简朴总结，面临100亿数据量，1万列属性，10万吞吐量的营业需求，可以回收了元数据处事、属性处事、搜刮处事来办理：

• 一个办理存储题目
• 一个办理品类解耦题目
• 一个办理检索题目

任何伟大题目的办理，都是循规蹈矩的。

思绪比结论重要，但愿各人有收成。

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请接洽原作者】

戳这里，看该作者更多好文

【编辑保举】

1. 大噶?鲱易懂的Hbase架构道理理会
2. Istio分层架构？80%的人有误解
3. 14个Q&A，报告python与数据科学的“暧昧情事”
4. 【拭魅战理会】基于HBase的大数据存储在京东的应用场景
5. 以免在景区看人，我爬了5W条世界景点门票数据...

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!