用云表运行大数据时处理效率如何？
2016-7-14 15:42:07
7445
1
| 本帖最后由 dick 于 2016-7-19 12:59 编辑
针对这个问题如果说 肯定没问题，但是相信很多人心里还是有疑问，运行多大的没有问题呢？有没有真实的案例可以让我们知道是否真的如所说那样OK呢？
如下分享一个在乐图云表会中讨论案例分享：（
同时非常感谢冯总以自己的例子给大家解答这个问题）
下面这张图是说明数据的密集程度的：在下面这张图中显示的是单据的生成时间，可以清晰的看到每一秒种都会生成很多单据，多的时候会几十张。如果是一天运行下来又将是多少数据呢？算是大数据吧？
通过上面的例子很多人也在想，仅从上面的保存数据的时间不能说明问题，如果一个单据非常简单只有两个字段一个编号一个名称，每秒保存几十张那么几百张也无法说明问题，在真实的系统运行时不会那么简单，肯定会做很多处理，做填表公式（快捷填写表单），业务公式修改其他表单的内容，数据接口，获取其他表单的数据等等……
那么冯总的这张单里面做了哪些操作呢？如下图，我们可以清晰的看到这个表中有大概15个左右的业务公式，修改的对象有销售订单，采购订单，货运地址，单据操作记录，新应收单，单品库存等等，至少6张其他表单的内容，这些业务公式中有的更改的主表的信息，有的是更改的明细表的信息。而且这只是业务公式的一角，还有数据接口和填表公式没有展示出来。
再看看下面这张图片就更让人感受到业务逻辑的复杂性。刚才看到的只是一个状态改变事件中的业务公式，这里有至少11个状态改变事件。那么总共业务公式有多少个大家自己猜猜。
这么复杂的系统，数据量不小，那么占用的硬盘空间也不少，下面就是使用系统后4个月的数据的存储量-数据库的大小。
这么复杂的系统要什么要的硬件支持呢？看如下图：16核 32G内存
下面是整个系统的功能的概况：
这么庞大的数据，数据库备份肯定是不能少的。
总结：
云表运行大数据时处理的效率即系统的速度快慢和设计是有很大关系的。就像做饭一样提供的食材和配料再好口味再好，没有掌握烹饪技巧也做不出一桌让人垂涎欲滴的佳肴。
|
+1
0
