攻克“四座大山”，医药零售的数据库分布式升级策略

医药零售会员服务场景，专攻个性化和精准化服务

随着大数据、云计算等技术的飞速发展，如何高效管理会员数据，成为医药零售企业转型升级的关键。作为国内医药零售的先驱者，青岛雨诺网络信息股份有限公司（简称青岛雨诺）已深耕医药零售行业22载，也在数字化转型升级过程中面临挑战，最终也走上了放弃传统数据库，走向选择分布式数据库的道路，以应对传统数据库带来的诸多挑战。

我们公司的产品体系主要由三大核心板块构成：

• 一是企业管理软件，如ERP系统，助力企业高效运营；
• 二是新零售运营工具，涵盖会员管理系统CRM、订单管理中心OMS及私域商城，实现从公域引流到私域转化的全链路管理；
• 三是针对医药行业的特色解决方案，包括医保处方中心、云医馆、慢病服务系统及DTP药房服务，精准满足医药行业特定需求。

这三大体系共同构成了我们全面、专业且富有创新性的产品矩阵，为用户提供个性化、精准化服务。

同时，我们公司的会员服务场景随着医药零售行业的商业模式变革，同样经历了三个阶段的演变。

在1.0时代，商业模式以商品为中心，企业重点关注商品管理、品类管理、进销存流程，并确保符合医药行业的GSP监管要求。正是在这一阶段，ERP系统应运而生。随后，行业逐步迈入2.0时代。

2.0时代以门店为核心，企业不再仅仅关注商品本身。由于主要服务场景转移至药店内，企业需要吸引会员到店消费。因此，这一阶段更侧重于门店的选址策略和服务质量优化，这是2.0时代的主要特征。

如今，医药行业已步入3.0时代，其核心特点是以用户为中心。尽管非业内人士可能难以直观感受，但医药行业正经历着深刻变革。近年来，受医保政策调整及整体经济形势影响，医药行业面临重大挑战，销售增速放缓，部分药店的销售额、客单价及客流量均呈现下滑趋势。

在此背景下，企业愈发重视会员服务，致力于提供精细化运营与服务。这种转变催生了一个全渠道的新零售场景，要求企业不断优化会员体验，以应对市场变化。

在1.0和2.0时代，服务主要围绕线下药店展开。而进入3.0时代，服务时间与空间得到了显著拓展。除店内服务外，我们还通过线上渠道，如B2C平台、O2O平台、电商平台以及企业自建的私域商城，为会员提供全方位服务。以往，零售场景仅限于顾客到店时，而在3.0时代，离店后的服务场景同样重要，成为企业间差异化竞争与寻找第二增长曲线的关键。

在3.0时代的服务场景中，我们能够提供离店后的服务，关键在于建立了详尽的会员档案。会员档案中，我们详细记录了影响用户健康用药的所有关键信息，包括会员的年龄、性别、当前用药情况、过敏史、是否患有慢性病及其具体类型，以及慢性病患者当前的健康指标等。

基于会员档案和会员画像的深入分析，我们能在会员离店后，根据特定时间节点实时提供用药指导和提醒。

例如，当慢性病会员的健康指标出现异常时，系统会触发回访任务，及时提供干预和指导。对于需要复购药品的会员，我们会在其药品即将用完时发送复购提醒。这样，即使在离店后，会员也能继续享受我们的专业化服务。

除了专业化服务，我们还结合优惠券等营销策略，不仅确保治疗效果，也让会员获得实际优惠。这种新零售场景通过不断积累数据，形成了完善的会员标签画像体系，实现了服务的个性化和精准化。

除了专业化服务，我们还结合优惠券等营销策略，不仅确保治疗效果，也让会员获得实际优惠，实现了服务的个性化和精准化。基于会员标签画像体系，我们得以深入了解会员，从而提供精细化服务。无论是线下消费还是线上场景，包括会员购买的商品、关注的健康知识、阅读的公众号推文等，各维度的数据均被存储并分析，以构建全面的会员标签画像。这涵盖普通疾病标签、慢病标签、用户行为标签，以及店员在服务中记录的主观属性标签、会员活跃度、对企业的价值贡献模型等。

有了这些数据支撑，我们无论在线上还是线下都能为会员提供精准服务。线上主要体现在精准营销和服务，而线下则根据会员的用药情况和健康状况，提供能提高治疗效果的关联用药建议。这是我们的会员服务核心场景。随着数据不断积累，其精准度和数量级均大幅提升，会员数据达千万级，消费数据达亿级，用户行为数据也达千万级。然而，海量数据的查询和使用也带来了数据库方面的挑战和问题。

医药零售场景摆在数据库前面的“四座大山”

在医药零售会员服务场景，数据库面临的挑战主要集中在四个方面，这些问题在业界普遍存在。

• 首要挑战是性能问题。在复杂用户筛选场景下，查询可能变得缓慢甚至无法完成，这直接影响了数据处理的效率和用户体验。
• 其次是效率挑战，特别涉及大型数据表，如MySQL中的大表。业务变更时，对这些大表进行结构调整或数据迁移往往复杂且耗时，增加了维护成本和工作量。
• 然后是成本问题。随着数据量的不断增长，存储需求也随之增加，导致存储成本持续上升。这要求我们在保证数据完整性的同时，也要考虑如何有效控制存储成本。
• 最后是及时性挑战。现代企业对数据处理的时效性要求越来越高。业务变化后，需要迅速查看数据效果，以便及时调整运营决策。因此，确保数据的及时性和可用性成为了数据库管理中的一个重要问题。

当前，我们面临三大核心数据库问题：

问题1：数据库架构不够灵活，无法很好支撑企业SAAS应用。

MySQL数据架构的刚性设计限制了其灵活性，难以适应企业及中小企业SaaS服务的多变需求。中小企业规模差异显著，从数十家门店至数百家不等，而当前架构在资源分配上显得捉襟见肘，导致租户间数据冲突频发，严重影响了SaaS应用的稳定性与可靠性。

问题2：大型医药连锁会员、订单交易数据量增长迅速，查询性能不足。

尽管已构建会员标签画像系统以推动服务精细化，但在海量会员数据中精确筛选目标群体仍是一大难题。如何准确识别需跟踪用药效果的会员、需复购提醒的用户、需实时人工回访的高价值客户，以及如何精准推送健康知识给有需求的会员，这些问题亟待解决。为此，我们需综合运用会员的多维度数据，如属性、信息、标签、历史消费记录及商品等，以实现更精准的筛选与定位。

在这个过程中，查询性能不佳成为制约我们发展的一大瓶颈。在十月份拜访的一家知名药企客户时，他们明确提出要求，所有查询，尤其是复杂查询和报表生成，必须在5秒内完成。这一高标准对我们的产品提出了严峻挑战，也凸显了拥有高效数据库的重要性。

另一个瓶颈是数据范围跨度受限。为了做好企业会员分析和管理，通常需要至少两年的消费数据，理想情况下应达到三年。然而，受传统数据库性能限制，如我们之前服务的一个客户，因数据量庞大,查询效率严重受损。为满足查询需求，我们不得不妥协，仅提供一年的数据，这大大限制了数据范围和分析的深度。在更复杂的应用场景下，这类问题将更加突出，亟待解决。

问题3：数据量大，导致存储成本高。

作为SaaS产品提供商，我们随着客户数量的不断增长，面临着数据保留的挑战。许多长期订阅的客户，比如那些已经订阅四五年的客户，他们的数据我们都需要长期保存，以便进行行业趋势分析、用户同比环比等深入分析。因此，业务数据量持续增长，导致存储成本不断攀升，成为我们面临的典型问题之一。

针对上述这些问题，企业正在积极探讨解决方案。其中，数据库的选型是一个关键的考量维度，我们希望通过优化数据库选择来降低存储成本，同时确保数据的高效管理和分析。

数据库技术选型的考量：五大期望

首先，我们对数据库的能力有五大核心期望：

• 灵活性。数据库应确保SaaS应用中的租户间隔离，避免相互干扰。
• 稳定性。所有SaaS应用需稳定运行，以持续满足用户需求。
• 快速响应。大数据量查询应能迅速完成，确保用户体验流畅。
• 低成本。数据库应具备低成本特性，以提高经济效率。
• 一体化管理。需支持一体化操作，简化管理流程。

这些期望共同构成了我们对数据库能力的全面要求。

在2023年3月，我们通过一场技术分享会首次接触到OceanBase，并对其有了初步了解。随后，在同年5月至6月期间，我们对OceanBase的各项功能和性能场景进行了详细验证。由于OceanBase完全兼容MySQL，这消除了我们在技术层面上的诸多顾虑。到了9月和10月，我们开始在一些特定场景下正式使用OceanBase。至今，越来越多的业务开始应用OceanBase，其应用范围持续扩大。

起初，在从MySQL数据库迁移到OceanBase的过程中，我们遇到了一些挑战，但得益于OceanBase团队的大力支持，所有问题均得到了有效解决。

总结而言，主要问题集中在三个方面：兼容性、配置问题及性能优化。

• OceanBase当时不支持jdbc最新版本24，因此我们对版本进行了降级处理，降到了17。
• OceanBase的行存列存优化器在自动匹配时存在不够精准的情况，需要我们根据具体业务场景进行手动调整，例如，一个涉及多表联合查询，同时包含多个子查询和复杂的分组条件的报表查询，优化器可能无法准确选择最适合的存储模式，需要手动分析查询语句的特点，根据主要的查询列和操作类型，选择行存或列存来优化性能。
• 在启用列存模式时，某些并行优化区域需要手动开启，不是自动开启的，这是一个配置问题，设置了set global parallel_degree_policy = 'AUTO';。

OceanBase落地收益：架构灵活，效率翻倍

目前，我们已经应用OceanBase有一年之久，前文提到的三个问题是否有效得到了解决呢？

• 问题1：数据库架构不够灵活，无法很好支撑企业SAAS应用；
• 问题2：大型医药连锁会员、订单交易数据量增长迅速，查询性能不足；
• 问题3：数据量大，导致存储成本高。

答案是肯定的，下面分别阐述我们的解决方案。

1. 数据库架构灵活，已支撑企业SAAS应用稳定运行1年+

OceanBase采用集群三节点，包含Zone域，每个域内设有多个服务节点，每个节点下又设有对应的Unit资源管控单元。这一架构使我们能够灵活分配资源。

对于小型客户，我们分配较少资源。而对于中大型客户，则分配更多资源。租户间资源实现隔离，我们可根据客户规模精准调整资源分配量。对于大客户，我们提供资源独享服务；中小客户则可选择资源共享，以此降低成本。

2. 会员精准筛选复杂场景下，开启列存，查询效率提升20+倍

对于会员数据的精准筛选。以一家多组织集团化企业的客户为例，我们的筛选维度首先包括组织层级，每个组织下包含会员。针对会员，我们可以进一步筛选其在特定时间段内的消费情况，包括消费频次、消费金额以及购买的商品类型，同时排除近期已享受过特定服务的会员。

在此使用场景下，我们对比了MySQL与OceanBase两种系统的性能。MySQL系统查询该数据大约需要18秒，而OceanBase系统则能在0.7秒内完成查询，查询速度提升了近20倍，

3. 数据存储压缩率达60%，成本优势显著压缩率

我们有一个营销云-流向系统客户，采用OceanBase系统进行数据存储。由于要追踪商品的流向，数据量非常庞大。该企业利用OceanBase系统处理大数据量存储，并搭配PG系统使用，实现了显著的存储空间压缩和成本节约。具体来说，在相同数据量的条件下，OceanBase数据库的压缩率达到了60%

未来，将OceanBase应用于更多产品领域

对于OceanBase产品，我们抱有深厚的期望，并且已经制定了公司未来的发展规划，主要聚焦于四个方面。

第一， 当前我们主要将OceanBase应用于报表生成和复杂查询等场景。未来，我们期望能够进一步拓展OceanBase的应用范围，将其融入如营销方案制定、执行以及回访任务分配等实际业务场景中，以充分发挥其数据处理和分析能力。

第二， 在将OceanBase应用于实际业务过程中，我们期待能够获得更多与OceanBase团队交流开发的机会，共同探索和优化系统性能，同时也希望OceanBase能够持续为我们提供强有力的支持。

第三，我们将积极向更多客户企业推荐OceanBase产品。目前，扬子江药业、厦门鹭燕药房、 重药医药集团以及大量的雨诺Saas客户都在使用OceanBase，并取得了显著成效。未来， 我们期待能够吸引更多用户加入OceanBase的大家庭，共同见证其卓越的性能和稳定性。

第四，除了会员服务产品外，我们还计划在2025年将OceanBase应用于更多产品领域，如订单处理中心的OMS系统以及运营诊断系统等，以实现更全面的数据管理和分析。