内容简介:MongoDB实战: Appsee使用基于MongoDB的实时分析服务描绘移动技术革命
原文链接:https://www.mongodb.com/blog/post/appsee-shapes-the-mobile-revolution-with-real-time-analytics-service-powered-by-mongodb
200亿文档,15TB数据存储于云上的 MongoDB 集群。新增App每月增加10亿+数据点。
在一些国家总共上网时间中90%以上是花费在移动设备上,提供完备的app体验变得非常必要。Appsee是一家新一代的移动行为分析公司,它向业务主体提供关于用户行为的深度洞察,使它们能够获得更高的参与度,转化率和营收。它们的客户包括eBay,AVIS,Virgin,Samsung,Argos,Upwork等等。Appsee在Google的 Fabric平台 中也十分受欢迎。仰仗MongoDB的能力,Appsee首先大量录入从移动App收集到的时序会话数据,然后设法找出其中的真意。
我与Yoni Douek,Appsee的CTO和联合创始人,进行了一次会谈以了解详细情况。
可以告诉我们一些关于贵公司的情况吗?
Appsee是一个实时移动App分析平台,它向客户提供我们称作“定性分析”的服务。我们的目标是通过一系列 工具 帮助公司理解用户是如何使用他们的App的,然后公司可以知道如何改进。传统的分析工具只帮助你看到数字——我们还提供了这些数字背后的原因。
Appsee的其中一个关键的定性工具是会话记录和重放,它能帮助我们的客户精确地了解和描绘他们的用户真实的使用体验。同时我们也提供触控热点地图,它向客户高亮显示了用户在每一屏是具体与哪个区域互动的,以及在哪里用户经历了使用性问题。此外我们的平台也提供了实时的分析,用户流,用户体验洞察,崩溃统计,和其他很多可以帮助公司优化他们的App的洞察信息。
请介绍一下你们是如何使用MongoDB的
我们的服务有两种不同的数据存储需求,它们都是由MongoDB完成的。
会话数据库:存储每个用户与移动应用互动时产生的动作数据。会话数据被作为时序数据流抓取并存入MongoDB,包括用户访问了哪一屏,多长时间,轻击或挥动了什么元素,崩溃情况,等等。这份原始的数据被建模到单个文档中,典型大小是6KB。完事的用户会话可以通过这个MongoDB文档来重建,这样App专家可以以视频形式查看这次会话,进而了解如何优化他们的App体验。
实时移动分析数据库:会话数据被聚合并存储在MongoDB中以提供深层用户行为分析。通过50多个表格和图表,App拥有者可以跟踪一系列的关键指标,包括:总安装数,App版本分布情况,用户留存率,以及更多。
我们大规模使用了 MongoDB聚合框架 ,基于它实现对原始数据的匹配、分组、投影和排序,再配合使用大量的聚合函数和数组操作表达式来转换和分析数据。MongoDB的二级索引允许我们高效地从不同维度和查询模式访问数据。我们的每个集合上通常都有3到4个二级索引。
为什么选择了MongoDB?
当我们开始开发Appsee服务的时候,我们对数据库有一个非常长的需求列表:
* 弹性伸缩,要能为用户和数据增长提供几乎无限制的扩展能力。
* 时序数据要求非常高的插入效率,同时又需要非常低的读延迟以便提供分析能力。
* 可靠的数据存储以确保永远不会丢失任何的用户会话。
* 灵活的数据模型以便持久化高度复杂的,迅速改变的,由新一代移动应用所产生的数据。
* 对开发友好,以便最大化团队的开发效率,以及缩短投入市场所需的时间——那时我们只有2个开发人员。
* 拥有丰富的数据库内建分析能力以便我们可以为App拥有者提供实时的洞察信息,而不需要把数据移动到单独的分析结点或数据仓库中。
由于我们都来自于关系数据库背景,我们一开始考虑过MySQL。但受制于关系数据模型的约束,并且不可能将写操作扩展到一个结点之外,导致我们认识到它不能满足我们的需求。
我们比较了很多NoSQL替代品,很快就意识到能满足我们需求的最好的泛目的数据库是MongoDB。它的快速处理高速时序数据流的能力,和原地分析的能力是其中的关键。而且这个数据库由一个充满活力和乐于助人的社区所支持,同时又有详尽的文档能够帮助我们平缓学习曲线。
能描述一下你们的MongoDB集群是什么样子的吗?
我们目前正运行着一个5个分片的MongoDB集群,每个分片由3个结点的复制集来提供服务,提供了自愈能力。我们的集群运行在CPU优化型的AWS Linux实例上。
我们使用MongoDB 3.2,使用 Python 和C#驱动,正计划今年晚些时候升级到最新的 MongoDB 3.4 。这会帮助我们用上新版本支持的并行chunk迁移,以便我们在进行弹性扩展时能够更快地进行集群均衡。
能够分享一下MongoDB性能表现怎么样吗?
MongoDB目前存储着200亿文档,大约15TB数据,我们计划在未来12个月内翻倍。集群目前每秒处理约50000次操作,读写比例大约是1:1。通过压力测试,我们知道目前的集群还能承受2倍的数据增长。
能分享一下水平扩展的最佳实践吗?
我的第一条建议是在你实际需要分片前就建好分片——这能保证在面对突然的需求增长时你能够拥有足够的处理能力。别等到目前的配置快达到最大使用率的时候才想到分片。
为了让我们的水平扩展听起来不那么抽象,每个使用了Appsee并且上线的App几乎都能在上线之初的每一个月向我们发送10亿+的数据点。每隔几周我们就跑一次压力测试来模拟处理我们目前2倍的数据。根据那些测试结果,我们调整分片,集合和服务器以便我们始终可以应对2倍的压力。
你们如何监控集群?
我们使用 Cloud Manager 来监控MongoDB,而我们自己其他的应用监控系统是基于Grafana,Telegraf和Kapacitor构建的。
你是如何测量MongoDB对你们业务的影响的?
从市场响应速度,功能多样性,用户体验和平台效率。
使用MongoDB我们可以更快地构建新的特性和功能。当我们聘用新的开发工程师时, MongoDB University 培训和 文档 能让他们在几天内快速进入状态。
MongoDB简化了我们的数据构架。它是一个真正意义上的泛目的平台——支持时序数据的高速消化,同时整合了对这些数据的丰富的分析能力,而且还不需要用到数据库以外的其他技术。
我们的服务能够维持很高的可用时间。使用 MongoDB的分布式,自愈性复制集架构 ,我们在AWS上的不同的可用区和区域部署集群以获得错误容忍和升级0当机能力。
每一代MongoDB都带来更高的效率。例如,升级到 WiredTiger存储引擎 帮助我们一夜之间节省了30%的存储花销。
MongoDB研发是开放和合作的——给予了我们帮助MongoDB团队摸索产品定位的机会。通过MongoDB的 JIRA项目 ,我们直接与MongoDB工程师团队互动,提出功能请求和缺陷报告,就好像MongoDB工程师是我们团队的一部分一样!
Yoni,感谢你花费宝贵的时间分享公司经验。
关于在AWS上部署和运行MongoDB的更多最佳实践,请下载我们的 指南 。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 书单丨5 本经典著作描绘 C++ 学习路线图
- 听神策数据 CTO 曹犟描绘数据分析行业的无限可能
- 蓝海讯通牵头描绘 IT 服务工具图谱,引领中国 IT 行业走向未来
- 算法描绘的“人造生命”,运动流畅自然,如同显微镜下的实景 | Demo·代码
- 对话 CTO〡听神策数据 CTO 曹犟描绘数据分析行业的无限可能
- 「Flask实战」鱼书项目实战一
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。