案例分享：如何规划海量EDI系统的日志存储？

早在2015年我们已经与物流行业A客户建立合作，依靠知行软件提供的EDI系统，打通与其客户的传输通道，加快了信息流传输。时隔多年，A公司随着业务的发展，逐步对接了近百家国际大客户，由于涉及 Dropship 等业务，数据量大，日交易高达7万，为应对突发暴增业务，以及对于国际大客户对于信息流同步的时间要求，A公司最终选择了使用Azure 云Linux服务器部署EDI高可用集群方案。

对于海量的业务数据，EDI系统的交易日志应该如何存储呢？起初A客户选择使用 Azure 自带的 SQLServer 数据库来保存EDI系统日志，相对于知行之桥自带的Derby数据库，这无疑是一个更稳妥的解决方案。Derby 数据库是一个文件型的微型数据库，只适合中小企业存储少量的交易日志，并且不可靠，且不支持HA（高可用）部署。如果企业使用EDI软件，建议还是选择 SQLserver/Mysql/PostgreSQL 数据库作为日志存储。

如何配置 SQLServer 作为log数据库呢？在知行之桥Linux 环境安装目录 \webapp\ arcesb.xml 配置如下：

即使配置了 SQLServer 数据库存放交易日志信息，随着日积月累日志的递增，数据库堆积了几千万的数据量，会导致一系列问题的出现：知行之桥UI访问变慢，数据库查询经常超时，产品版本升级效率低等等。 A客户日志数据库中的数据是自2021年1月1日到2022年8月份，累积达到4千多万条，在知行之桥“状态”页面根据文件名搜索会超时，切换工作区或者打开某个端口都需要几十秒甚至查询超时导致端口打不开。

解决方案

面对海量日志存储，知行之桥自带清理选项机制，默认保留近一个月的数据（时间周期可自行设置），1个月前的数据都会被自动删除。如果企业需要保留1个月以前的所有日志数据，建议客户将所需日志数据实时备份到另外一个数据库中，以便后期查询。 注意：建议时间周期最多不要超过三个月，避免知行EDI系统访问卡顿情况。

根据知行之桥EDI系统默认清理规则，理论上来说，日志数据库本只有近一个月的日志数据，但实际上为何积累了4千多万条数据呢？

这是因为知行之桥V2020版本每天零点清理日志数据库时默认有1分钟的超时限制，一旦数据库中当天的业务量比较大（比如5、6万条），在1分钟内查询超时，删除日志就会失败，这样数据就会一直被保留在数据库中，而知行之桥V2021版本已经在产品功能上解决了这一问题，删除数据不会有超时时间限制。

日志数据库超时导致数据堆积的问题该如何处理呢？

经与开发同事，以及客户多次讨论确认，提供了切割数据库，再对EDI产品做升级的方案，即当前日志数据库仅保留近3个月的数据，将之前的数据先备份到另外一张表，具体步骤如下：

1.在现有log数据库建立一张新表，表名为 app_transactions_new。
2.与客户确认UI上必须最少显示最近3个月的数据，以便查询。因此我们将5/25-8/25前一天的数据插入到这张新表 app_transactions_new。（切割的那天是8/25，由于EDI系统一直有业务文件的收发，我们先插入截止当天前一天的数据）

注意：在插入前需要设置该表允许插入：

set identity_insert [EDI_PROD_DB].[dbo].[app_transactions_new] ON

3.app_transactions_new 表添加索引。
4.停止知行之桥服务。
5.重命名数据库中的表名：

将 app_transactions 表作为备份表，重命名为 app_transactions_2021_2022，建议可按年备份； 将 app_transactions_new 表作为知行之桥的交易日志数据库表，重命名为 app_transactions

6.将8/25当天的数据插入到 app_transactions 表中，同样要先设置表允许插入。
7.创建 trigger，确保往 app_transactions 表中写数据的同时也会往 app_transactions_2021_2022 表中写数据备份。
8.检查数据一致性。
9.开启知行之桥服务。
10.UI上修改归档日志参数为90天。
11.和A客户确定升级知行之桥21版时间，并协助升级版本。

以上 log 数据库切割部分，主要时间花费在停服务之前，插入近3个月数据和创建索引大概需要20分钟，其他操作都只需要几秒钟，停服务之后的操作仅需要5分钟不到即可完成。切割数据库完成后， A 客户 EDI 负责人表示：感觉就像身上掉了一块大肥肉，一身轻松啊。并且我们观察到访问知行之桥UI肉眼可见的速度变快，因此我们希望对于业务量较大的企业，如果您遇到以上情况，希望这篇文章可以帮助到您。

除此之外，如果企业目前在使用知行EDI系统企业版，对接多个交易伙伴，同时业务量略大，建议提前考虑下高可用集群(High-availability cluster)方案的部署。

高可用集群(High-availability cluster)，简称HA，HA方案有以下几个优点：

• 高可用：故障转移，服务不掉线
• 高性能：负载均衡，降低延迟，提高并发
• 可扩展：弹性计算，可应对突发业务需求
• 安全性: 多层次安全防护，灵活高效

更多EDI信息，请参阅: EDI 是什么？

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。