Skip to content

U
unidocs-zh

程序yang / unidocs-zh
与 Fork 源项目一致

Fork自 DCloud / unidocs-zh

通知 1
Star 1
Fork 0
U
unidocs-zh
提交 88ce7eda 编写于 作者: VK1688's avatar VK1688
浏览文件
操作

update uni-stat-v2.md 新增uni统计2.0费用评测

上级 ee783622
隐藏空白更改
内联 并排
Showing with 280 addition and 5 deletion
docs/uni-stat-v2.md
浏览文件 @ 88ce7eda
......@@ -722,6 +722,17 @@ uni统计的sourceMap功能可以解决这一问题，在统计后台可以清
│ │── page-res # 受访页
│ │ │── page-res.vue
│ │ └── fieldsMap.js
│ │── pay-order # 支付统计
│ │── funnel # 支付/漏斗分析
│ │ │── funnel.vue
│ │ └── fieldsMap.js
│ │── list # 支付/订单明细
│ │ │── list.vue
│ │── overview # 支付/订单概况
│ │ │── overview.vue
│ │ └── fieldsMap.js
│ └── ranking # 支付/用户价值排行
│ └── ranking.vue
│ │── scene # 场景值（小程序）
│ │ │── scene.vue
│ │ └── fieldsMap.js
......@@ -784,6 +795,8 @@ uni统计的sourceMap功能可以解决这一问题，在统计后台可以清
│ │ │── index.js # 入口文件，提供对外访问模块
│ │ └── uni-crypto.js # 数据加密类文件，提供AES/MD5加密
│ │── mod # 数据模型，提供具体业务实现。
│ │ │── uni-pay # 支付统计目录
│ │ │ └── payResult.js # 支付统计模型，跑批支付统计数据。
│ │ │── activeDevices.js # 活跃设备模型，给周月维度的设备基础统计和留存统计提供数据，每日跑批合并，仅添加本周/本月首次访问的设备。
│ │ │── activeUsers.js # 活跃用户模型，给周月维度的用户基础统计和留存统计提供数据，每日跑批合并，仅添加本周/本月首次访问的用户。
│ │ │── appCrashLogs.js # 原生应用崩溃日志模型，记录原生应用的崩溃日志
......@@ -881,7 +894,8 @@ uni统计配置项存放于uniCloud配置中心（`uni-config-center`）下的 `
- `clean`：错误数据统计，统计维度包括：
- 日志清理，默认`每天上午5点（30分钟）`触发，清理过期的日志数据
- `pay-result`：支付数据结果统计，统计维度包括：
- 实时统计，默认`每小时（10分钟）`触发，统计上一小时的基础数据（实时统计时，会自动统计小时、天、周、月、季度、年度维度的数据，无需再配置其他维度统计）
#### 错误检测配置说明
......@@ -1012,17 +1026,278 @@ exports.main = async (event, context) => {
};
```
## 如何降低uniCloud费用@savemoney
由于统计业务对数据库的操作会相当频繁，所以当用户量较大时可能会增加不小的开销。我们可以通过以下几种方式来减少`uni统计2.0`功能的数据库操作次数，从而达到降低uniCloud费用的目的
## uni统计2.0费用评测
### 前言
近期，uniCloud阿里云版开始正式商用，部分开发者对基于uniCloud的`uni统计`等云端一体业务，开始纠结，不清楚这些业务预计会花费多少钱，不清楚相比传统服务器而言，何种方案性价比更好。
本文尝试算细账、算总账，以阿里云[按量计费](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)为例，详细预测`uni统计`在不同用户规模下的资源消耗及对应费用，帮助大家明智选择，无忧开发。
本文主要分为三个部分：
- `uni统计`消耗的资源费用测算
- `uni统计`给你带来的收益
- 综合考虑，你该如何选择
**uni统计 消耗的资源费用测算**
`uni统计`涉及费用的部分主要分为：
- 云函数：`uni统计`云函数，云函数有2个
+ uni-stat-receiver 客户端数据上报函数（添加统计数据源）
+ uni-stat-cron 数据跑批处理函数（生成统计数据）
- 云数据库：`uni-stat-`为前缀的表
- 前端网站托管：部署`uni-admin`，管理员发布新版本
接下来，我们对不同资源，分别进行费用评估。
### 云函数
#### uni-stat-receiver
启用`uni统计`后，你的每一个在线用户默认每10秒会请求一次`uni-stat-receiver`云函数（如果你的日活在1万以上，可以改成60秒，可以减少费用。时间间隔可在manifest.json内设置，如果用户一直停留在一个页面，那么此时不会重复上报）
我们按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)列出的按量计费规则，计算一下云函数的资源消耗。
|资源分类 |资源细项 |售价（元） |
|:-------: |:----------------: |:-------: |
|云函数 |资源使用量（GBs） |0.000110592|
| |调用次数（万次） |0.0133 |
| |出网流量（GB） |0.8 |
|云数据库 |容量（GB/天） |0.07 |
| |读操作数（万次） |0.015 |
| |写操作数（万次） |0.05 |
|云存储 |容量（GB/天） |0.0043 |
| |下载操作次数（万次） |0.01 |
| |上传操作次数（万次） |0.01 |
| |CDN 流量（GB） |0.18 |
|前端网站托管 |容量（GB/天） |0.0043 |
| |流量（GB） |0.18 |
我们可以简单得出如下公式：
`云函数/云对象费用 = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8`
其中：
- 资源使用量 = 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数
- 调用次数 = 应用日活 * 每日活用户平均每天上报次数
我们假设如下数据模型：
- 云函数运行内存：128M，即0.125G（云函数内存默认为512M，用户可以自定义设置，最低可设置为128M）
- 每日活用户平均每天上报次数：10 次
- 云函数平均单次执行时长：100毫秒，即0.1秒
- 单次请求出网流量：0.7 KB
按照如上公式，若有100个日活用户，其`uni统计`的`uni-stat-receiver`云函数每天的费用为：
```
云函数费用（天） = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量（单位GB） * 0.8
= 0.125 * 0.1 * (100 * 10) * 0.000110592 + (100 * 10) * 0.0133/10000 + (100 * 10) * (0.7 / 1024 / 1024) * 0.8
= 0.001382 + 0.00133 + 0.000534
≈ 0.0032（元）
```
即：你的App日活为100，使用`uni统计`商业版后，`uni-stat-receiver`云函数每天大概消耗0.0032元。
据此，可计算其每月的费用为：0.0032 * 30 ≈ 0.1，即日活为100时，每月`uni-stat-receiver`云函数只需0.1元。
同理，我们可推导出日活为1000、10000、10万的App，其`uni-stat-receiver`云函数每月费用如下表：
| 日活 | 资源使用量计费（元/日） | 调用次数计费（元/日） | 出网流量计费（元/日） | 日合计（元/日） | 月合计（元/月） |
| :----:| :-----------------: |:-------------------:|:--------------------: |:----------: |:---------: |
| 100 | 0.001382 | 0.00133 | 0.000534 | 0.0032 | 0.10 |
| 1000 | 0.01382 | 0.0133 | 0.00534 | 0.0325 | 0.98 |
| 10000 | 0.1382 | 0.133 | 0.0534 | 0.3246 | 9.74 |
|100000 | 1.382 | 1.33 | 0.534 | 3.2460 | 97.38 |
#### uni-stat-cron
`uni统计`还有一个云函数`uni-stat-cron`，它是定时数据跑批任务，用来将上报的数据进行统计，生成统计报表。
我们假设如下数据模型：
- 云函数内存：512M，即0.5G（跑批云函数建议设置为512M，因为它每天只运行24次，内存越大，性能越强）
- 云函数平均单次执行时长：1秒（随着数据源越多，运行时间越长）
- 每日执行次数：24次（固定每小时运行1次）
- 出网流量：没有返回给客户端，固定为0
其`uni统计`的`uni-stat-cron`云函数每天的费用为：
```
云函数费用（天） = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 0.5 * 1 * 24 * 0.000110592 + 24 * 0.0133/10000 + 0
= 0.001327104 + 0.00003192 + 0
≈ 0.0014（元）
```
即：你的App日活为100，使用`uni统计`商业版后，`uni-stat-receiver`云函数每天大概消耗0.0014元。
据此，可计算其每月的费用为：0.0014 * 30 ≈ 0.04，即日活为100时，每月`uni-stat-receiver`云函数只需0.04元。
同理，我们可推导出日活为1000、10000、10万的App，其`uni-stat-receiver`云函数每月费用如下表：
| 日活 | 平均耗时（秒） | 资源使用量计费（元/日） | 调用次数计费（元/日） | 出网流量计费（元/日） | 日合计（元/日） | 月合计（元/月） |
| :----:| :------: |:-------------------: |:-------------------: |:-------------------: |:---------: | :--------: |
| 100 | 1 | 0.001327 | 0.00003192 | 0 | 0.0014 | 0.04 |
| 1000 | 3 | 0.003981 | 0.00003192 | 0 | 0.0040 | 0.12 |
| 10000 | 30 | 0.039813 | 0.00003192 | 0 | 0.0398 | 1.19 |
|100000 | 90 | 0.119439 | 0.00003192 | 0 | 0.1195 | 3.59 |
由于`uni-stat-cron`云函数不管多少日活，每日均只运行24次，故日活对其费用的影响很小（只影响了每次运行的时长）。
### 云数据库
按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)介绍，云数据库费用 = `容量费用 + 读操作次数费用 + 写操作次数费用`，其中：
- 容量费用：数据库存储容量（单位为G） * 0.07
- 读操作次数费用：读操作次数（万次） * 0.015
- 写操作次数：写操作次数（万次） * 0.05
`uni统计`会产生大量的日志数据，但默认会有自动清除历史日志的策略，如：会话日志`31天前`的数据会被删除。
由于`uni统计`涉及数据库的情况非常复杂，我们通过对官方统计示例项目的实际运行数据得出以下结果：
日活为100的应用，`uni统计`数据库资源用量如下：
- 每日活用户平均每天上报次数：10 次
- 平均每次上报，需读取2次数据库，写入2次数据库（平均新增1.1条，修改0.9条），故新增插入1.1条记录，约0.54KB（注意：很多情况下上报可能没有数据新增，仅仅只是修改下会话日志数据。）
以上数据由官方统计示例项目计算得出。
故可得出以下数据模型：
- 日均云数据库容量：0.00052G（= 100 * 10 * 0.54 / 1024 / 1024）
- 日均云数据库读取次数：2000次（= 100 * 10 * 2）
- 日均云数据库写入次数：2000次（= 100 * 10 * 2）
因为数据源只保留31天，故稳定运行后，数据量容量一直会保持在31天的量。故下方公式中云数据库容量需要乘31
```
数据库费用（天） = 云数据库容量 * 31 * 0.07 + 读操作次数 * 0.015 / 10000 + 写操作次数 * 0.05/10000
= 0.00052 * 31 * 0.07 + 2000 * 0.015/10000 + 2000 * 0.05/10000
= 0.0011284 + 0.003 + 0.01
≈ 0.0141（元）
```
即：如果你的`uni统计`业务日活为100，使用阿里云商业版云服务空间后，对应数据库每天大概消耗0.0141元。
据此，可计算其每月的费用为：0.0141 * 30 ≈ 0.42，即日活为100时每月云数据库只需0.42元。
|日活 |容量费（G） |读操作次数费用（元/日） |写操作次数费用（元/日） |日合计（元/日） |月合计（元/月） |
| :--------:| :------: |:---------------: |:---------------: |:----------: |:----------: |
| 100 |0.0011284 | 0.003 | 0.01 | 0.0141 | 0.42 |
| 1000 |0.011284 | 0.03 | 0.10 | 0.1413 | 4.24 |
| 10000 |0.11284 | 0.30 | 1.00 | 1.4128 | 42.38 |
|100000 |1.1284 | 3.00 | 10.00 | 14.1284 |423.85 |
#### 云数据库搭配redis后费用对比
redis只影响数据库的读操作，通过官方统计示例项目使用redis的前后对比可知redis大概可以减少2/3的数据库读操作次数（等于减少2/3的数据库读次数费用）。
|日活 |读操作次数费用（元/月）（未开启redis） |读操作次数费用（元/月）（开启redis） |开启redis后每月减少的费用（元） |
| :--------:|:------------------------------: |:---------------------------: |:-------------------: |
| 100 | 0.09 | 0.03 | 0.06 |
| 1000 | 0.90 | 0.30 | 0.60 |
| 10000 | 9.00 | 3.00 | 6.00 |
|100000 | 90.00 | 30.00 | 60.00 |
由此可见，当日活低于10万时，redis减少的费用还不太明显。但当日活大于10万时，redis的作用越来越明显。
### 前端网页托管
`uni统计`需要和`uni-admin`配合使用，`uni-admin`需要部署在前端网页托管中。`uni-admin`主要是管理员使用，使用频次较少，流量也较低。
按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)介绍，前端网页托管费用 = `容量费 + 流量费`。
#### 容量费
`uni-admin`编译后为4.7M，按照官网每GB每天0.0043元的规则，`uni-admin`的月度容量费为：`4.7 / 1024 * 0.0043 * 30 = 0.00059`，不到1分钱，可忽略。
#### 流量费
管理员登录`uni-admin`，到`uni统计`管理页面浏览统计数据，所需流量不超过3M，即使每月发布2次更新，流量费预估为：`3 / 1024 * 0.18 * 2 = 0.00105`，也不到1分钱，也可忽略。
#### 前端网页托管总结
每月费用不到1分钱，可忽略。
### 费用合并
细项对比完了，我们来合并看看，使用`uni统计`，每月到底需要花多少钱。
|日活 |云函数（元/月） |云数据库（元/月） |前端网页托管 （元/月） | 月合计（元/月） |
| :--------:| :--------: |:-----------: |:-----------------: |:---------------:|
| 100 | 0.14 | 0.42 |可忽略不计 | 0.56 |
| 1000 | 1.10 | 4.24 |可忽略不计 | 5.34 |
| 10000 | 10.93 | 42.38 |可忽略不计 | 53.31 |
|100000 | 100.97 | 423.85 |可忽略不计 | 524.82 |
### uni统计 给你带来的收益
使用`uni统计`，免费获取、一键安装，你将获得：
**1. 全端**
全端流量统计，一张报表可查看所有端（iOS、Android、Web 及各家小程序）的运营数据。
无需在各端接不同的sdk、无需在不同报表看数据。目前市面已知唯一一个一张报表看遍业务全景的方案。
**2. 开源、免费、自由定制**
代码全部开源。采集什么数据可以自定义；跑批频率可以自定义（搞活动时实时统计都可以做到）；展示报表可以自定义。
**3. 私有部署、数据自控**
使用传统saas类统计产品，所有数据都上报给统计服务厂商。
`uni统计2.0`基于`uniCloud`实现，云函数、统计数据全部托管在开发者自己的服务空间（阿里云或腾讯云自选）中，开发者对自己的统计数据拥有完整的控制权。
**4. 有效的错误分析**
传统App统计平台，都没有js错误统计。开发者无法了解到自己的js代码在哪些设备上会报错。
uni统计的错误信息更全面，包括 js前端错误和 App 原生层的崩溃。
因为uni-app是编译后运行，传统web和小程序的统计平台，其js报错无法回溯到uni-app的编译前源码，报错看不懂。
uni统计支持sourcemap，可直观了解到底哪行代码写的有问题。[详见](https://uniapp.dcloud.net.cn/uni-stat-v2.html#sourcemap-parse-error)
**真实案例**
> [一个半月全端获客400万的真实例子](https://mp.weixin.qq.com/s?__biz=MzU3NTU5NDc0NA==&mid=2247491214&idx=1&sn=7e334d079146d9e31cea407f45bd8624&chksm=fd219719ca561e0f9a85b30017618eaf9551b46cdd6ecdf856bc4e47aee4ca93767fcf23147f&mpshare=1&scene=1&srcid=0713VwAOIuRllzMB6syoQssb&key=15a2b72b2464b4fe73325967f733ac332583d5db37f1812c63613c083a8f5921bca2ada2140d45e07657b062dc451f27cc48fe4fd298f6456f300895a90bd471480afdc2c8dc5a45254fb1dc48d3b79a&ascene=1&uin=MTkzNjMxMzU%3D&devicetype=Windows+10&version=62060833&lang=zh_CN&pass_ticket=xW6dPp%2F565g5S8hl1lz%2F8FLQBEzW6KUHyyqyHPdT2nk%3D)
### 总结
再次说回`uni统计`，通过上面的费用测算可得知，以日活1万来说，每个日活产生的一年的费用大概是6分钱到7分钱之间，这个费用已经是比较便宜的了。
目前市面上的统计如友盟统计也是收费的，在日活达到1万时，每年费用需要3109元/年（且这还只是web统计的费用，APP统计另算费用）。同时它还不是源码版本，代码不开源，无法随意定制。
而`uni统计`是全平台统计、代码开源、随意定制，这是三方统计平台做不到的。
再看回刚才的计算表，以日活1万来说，`uni统计`每年费用只需53.31*12=639.72元/年。
|日活 |云函数（元/月） |云数据库（元/月） |前端网页托管 （元/月） | 月合计（元/月） |
| :--------:| :--------: |:-----------: |:-----------------: |:---------------:|
| 100 | 0.14 | 0.42 |可忽略不计 | 0.56 |
| 1000 | 1.10 | 4.24 |可忽略不计 | 5.34 |
| 10000 | 10.93 | 42.38 |可忽略不计 | 53.31 |
|100000 | 100.97 | 423.85 |可忽略不计 | 524.82 |
不重复制造轮子，聚焦业务，快速验证模式，实现商业增长，才应该是聪明工程师的追求。
本篇评测共大家参考。
### 如何降低费用@savemoney
- 1.适当增大前端数据上报周期
因为默认是10秒上报一次。改成10分钟一次就可以降低60倍的访问量。具体调整方式可参考上文[数据上报逻辑](#report-time)中有关前端数据上报周期的说明。
因为默认是10秒上报一次。改成60秒一次就可以降低6倍的访问量。具体调整方式可参考上文[数据上报逻辑](#report-time)中有关前端数据上报周期的说明。
- 2.开启redis缓存
这也是目前降低`uni统计2.0`数据库查询次数最有效的方法。因为redis是按容量计费，读写次数再多也不会多花钱。redis开启方法可参上文[开启redis缓存](#开启redis缓存)。
- 3.关闭实时统计
实时统计指云端实时运算统计报表。但现实中大多数人只关心昨天的统计报表。只有今天要搞促销时才会实时关注数据报表。可以在日常配置为按天统计，在搞活动时再调整配置为实时统计。修改方法：将实时统计的配置项设置为关闭状态，然后重新上传配置中心（`uni-config-center`）到关联的服务空间即可。配置项说明可查看上文[公共模块配置项说明](#公共模块配置项说明)。
## 常见问题
**1. 启动uni统计后，何时可以查看报表数据？**
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或