当前位置: 华文世界 > 科技

一个没做过归档需求的产品跟开发battle了起来

2024-02-10科技

产品经理是否需要写数据库备份的需求文档?关于这个问题,不同人可能会有不一样的看法。或许在进一步探讨写不写数据归档需求这个问题之前,产品经理还需要了解下数据库是什么以及为什么要数据备份归档。一起跟着作者来梳理清楚这个问题吧。

某个晚上七点,在下班的地铁上,一群友发出了如下的疑问:

「请教个问题,这数据库备份,各种表的删除和备份,这种需求文档也需要产品经理来写?难道不是技术人员的活儿?」

「什么产品功能都没有,就是因为数据库满了,内存可能不够了,要删除一些表,然后备份到别的地方。建议扩内存,开发也不听。我说我写不了,结果技术就让我看他们以前的留言和代码截图,还是英文的,我真的是服了!气炸了好吗!就算要写,也得把前因后果给我讲清楚啊!什么都不说就让我写,我怎么写?」

产品经理是否需要写数据库备份的需求文档 ,这在群里引发了一场激烈的讨论。

一、群友的看法

1. 不写派

不需要,除非你会技术、如果你懂的话,可以出,不懂就让技术弄;

不需要写,懂也不需要写;

技术会鄙视,不该你写的瞎写;

这种需求为啥还要产品来写,要开发干嘛;

产品的时间和精力都花在这上面,意味着更有价值的事情被搁置了,产品的本职工作也没做。

2. 论事派

这种行为看起来像是甩锅行为,开发在推卸责任。

根据描述,很明显是在给题主制造麻烦。退一步说,产品可以做到这种程度,但前提是对方也要做到这种程度:应该清楚地解释事情的前因后果,不要给截图,也不要给英文。

3. 要写派

B这是关于表数据归集的问题,需要考虑是按月、季度还是年进行归档。这些归档需求都需要产品经理来定义。在确定归档时间后,系统中的所有查询和统计逻辑都必须考虑到这个归档时间。数据归档通常需要拆分一个菜单或入口进行查询,因此查询页面和交互是不同的。

数据归档由技术人员负责,产品提供规则。例如,归档的频率、归档后的数据在哪里可以查询以及如何处理仪表盘的统计等。由于核心问题是 SQL 查询慢,这影响了许多实时逻辑,所以说升级数据库容量不是万能的。

归档的需求不仅需要产品提供良好的支持,而且对多个业务的影响范围可能大可能小。如果由于归档导致产品出现问题,比如查询不到订单等,产品需要进行设计以解决这些反馈。

二、懂点数据库基本概念

进一步探讨写不写数据归档需求这个问题之前,作为产品经理,有必要了解下数据库是什么以及为什么要数据备份归档,什么是磁盘容量、内存大小,不然像上文群友一样以为升级内存就完事了。

1. 数据库、表、数据

数据库就像一个图书馆,图书馆里面有很多个书架(数据表),存储着各种书籍(数据),每本书都有自己的编号(主键),可以通过编号快速找到对应的书籍。

2. 磁盘容量

磁盘容量就像图书馆的大小,可以容纳的书架数量以及书架大小,决定了能容纳多少本书。数据库的磁盘容量决定了它能存储多少数据。

3. 内存大小

内存就像图书馆的工作人员,负责帮助读者快速找到需要的书籍。内存越大,处理读者请求的能力越强,查询速度也越快。

例子:打工马喽

假设某一个人力资源集团有10个下属公司(10个数据库),每个公司分了10个部门(10张数据表),每个部门有10个马喽工位(因此该数据库总磁盘容量100GB),工位上记录着每个马喽的信息,包括姓名、工号、学历、技能等,意味着每个下属公司最多可以同时收纳100个马喽(存储100GB的数据,数据库会从磁盘读取数据,并加载到内存中进行处理)。

该人力集团由于没有建设信息化,所以给每个分公司设置了10块大黑板+10个匹配专工(数据库内存是10GB),让销售人员接待甲方人力需求的咨询和下单的时候用(系统可以使用这10GB内存来快速访问和操作数据库中的数据)。

集团主要的销售方式是电呼,当有甲方需要咨询外包需求时候,销售人员就会让专工根据客户需求去工位查询各个马喽的信息,并且把符合条件的马喽信息记录在大黑板上,以便跟客户进一步沟通。

最终如果某个马喽被外包成交了,最终要去工位修改马喽的外包信息,以免后面的销售判断错误。

所以说如果黑板够大够多,专工数量越多,动作越快,处理速度就会更快。也就是内存足够大,系统可以快速找到并返回所需信息。但如果内存不足,系统可能需要频繁地从磁盘读取数据,导致查询速度变慢。

当集团业务越来越好,招揽的马喽越来越多,但是黑板和专工也不可能无限放大(不符合资本性价比),因此,对马喽的工位和信息进行分类、归档、迁移,让专工可以根据不同的情况,针对性去不同的地方「找马喽」,就可以提高工作速度了。

三、产品归档需求怎么接

1. 不归档的坏处

一般来说,对于单表的数据量,800万(800W)到1000万(1000W)条数据是一个比较合适的范围。数据量太大的话,会有以下影响:

  • 性能下降 :随着数据量的增加,查询、插入、更新和删除操作的性能可能会受到影响。大量的数据可能导致数据库的响应时间变慢,尤其是在执行复杂查询或涉及大量数据的操作时。
  • 存储和内存需求加大 :大量的数据需要更多的存储空间和内存来存储和处理。这可能对硬件资源造成压力,并可能导致存储成本的增加。
  • 数据管理和维护困难 :处理大量的数据可能会使数据管理、备份和恢复变得更加复杂和耗时。
  • 索引和查询优化困难 :对于大型数据表,索引的维护和查询优化可能变得更具挑战性,需要更多的关注和优化工作。
  • 最直接的表象,就是用户在做各种 查询、统计、导出 操作的时候,会 巨慢、奇卡无比 ,甚至会操作失败。

    2. 归档需求怎么做提

    站在产品经理角度,归档先分两种情况。

    1)历史功能或是自身不熟悉的功能

    像上文那种情况,针对历史功能需要进行归档,笔者先站个观点:一个尽职的产品经理还是要把需求接下来,以推动工作的展开。

    但是,像这种历史功能,开发不是很配合,又有明显的推诿行为,那就需要跟开发沟通,让开发梳理出对应需要归档的表涉及到哪些依赖关系、有什么接口在调用,整理后书面发出来,然后大家再一起评估下有无遗漏,要注意的点之后,再继续推进。

    因为归档数据对业务影响可大可小,在不熟悉的情况下千万别贸然推进,搞不好成为背锅对象。

    2)新功能需求或自身很熟悉的功能

    自己很熟悉的功能,或者是规划新需求,可以先自行梳理后,再跟开发、测试、业务等人员多视角一起评估。

    确定分表策略:产品经理确定好数据库分表的策略,包括分表的依据字段、分表的规则,是按时间来归档,还是按某个数据状态来分表。初步拟定后需要与技术团队一起沟通评估。

    分表分析沟通:产品经理需要和技术团队对数据库分表的影响进行充分的分析,并与相关利益相关者进行沟通和确认,以确保分表的过程对系统的影响可控。

    输出分表需求:分表之后,归档的数据是否允许前端查看,如果需要查看,是分多个菜单,还是在原来的菜单,筛选条件是否针对性进行限制,比如只能按月筛选查看数据,或者按某个状态筛选查看筛选数据。并罗列清楚对应的修改点、修改功能有哪些,需要怎么修改,怎么取数等。

    通过合理的数据分表归档策略,能够更好地管理和利用数据,提高系统的性能和可维护性。期待与各位读者共同分享和探讨更多关于数据管理的经验和思考。

    本文由 @别字君 原创发布于人人都是产品经理。未经作者许可,禁止转载。

    题图来自Unsplash,基于CC0协议。

    该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。