elasticsearch可以代替NoSQL吗
创新互联是一家以网站设计,开发核心业务的专业网站建设公司，创新互联为客户提供：软文发稿、创新网站解决方案。我们的目标是提高客户网站项目的专业度，以创新和互联的思维增加用户体验并有效提高潜在客户。
优点：
1.高并发。实测es单机分配10g内存单实例，写入能力1200qps，60g内存、12核CPU起3个实例预计可达到6000qps。
2.同机房单条数据写入平均3ms（比mysql慢，mg不清楚）
3.容错能力比mg强。比如1主多从，主片挂了从片会自动顶上
4.满足大数据下实时读写需求，无需分库（不存在库的概念）。
5.易扩展。实例间做下配置即可扩展并发性和容积，自动分配的写入机制，无需操心传统db中多主同步的诟病
6.支持较复杂的条件查询，group by、排序都不是问题
7.具有一定的关系性，但不用担心大字段的问题
人群圈选，也叫人群定向。在业界有中广泛的业务场景。
业界比较优秀的方案有百度基于doris来实现海量用户的圈选，可以实现千万级人群秒级圈选。但是这种方案比较复杂：
1、需要数仓同学加工二值化tag，构建用户二值化tag到用户bitmap集合的倒排索引
2、需要通过构建哈希分桶列，解决超大bitmap基数交并集问题
3、需要数仓同学构建全局字典，防止不连续id带来的roaring bitmap性能问题
4、需要通过to_bitmap函数解决动态标签与静态标签的组合圈选问题
5、需要团队有doris的运维能力
本博文介绍一种基于spark的轻量级圈选，可以实现千万级人群分钟级（5分钟以内）圈选。
业界还有基于ES、MR、离线+服务bitmap等方案（我们选型时，doris还不火，故不在此列）。
ES：大人群的滚动导出会给集群带来很大压力的；另外就是如果构建一个大而全画像宽表的话，这个表会很稀疏，所以我们会按业务主题构建多个es表，这样就会涉及到多个表之间join的问题，而es是不支持join语义的。
MR：老方案了，性能不大行
es+bitmap方案：这个方案扩展起来有点doris的味道。但是自己开发的话，其实比较复杂，而且没有居多性能优化手段的话，性能没那么理想，大都是比不上spark的。
因此，最后我们选择了spark做为人群圈选的方案。
我们构建了用户画像相关的一站式平台，前端平台包括人群管理、标签管理、画像分析等相关功能。
中间层服务对应包含人群管理中心、人群任务调度、人群解析引擎（负责前端json到Spark SQL的转化）、标签管理中心的模块；当然也包含权限、安全、流控、人群监控等辅助模块。
存储层，我们主要基于spark进行人群定向，依托Hbase/Redis做用户单到点查询，用Mysql做配置信息存储。
我们选取两个主题的画像进行交集圈选，圈选结果千万级，测试结果如下：
优点： 1.高并发。实测es单机分配10g内存单实例，写入能力1200qps，60g内存、12核CPU起3个实例预计可达到6000qps。 2.同机房单条数据写入平均3ms（比mysql慢，mg不清楚） 3.容错能力比mg强。
