导语
在此篇文章中,我想分享在处理带有大型数据库表的项目时所学到的一些经验教训。首先,让我们定义Mendix中大型表的意义。
大型表 = 超过一百万行
在我们的案例中,我们有1亿行。最重要的是,此表非常活跃。每天将近插入一百万行。一旦项目中的表格达到此大小,您就需要开始考虑以前无需担心的事情。很小的更改(例如添加新的布尔属性)可能会对应用程序的性能产生重大影响。以下是根据Mendix同事小伙伴的经验提供的五个提示,欢迎交流。
提示1:使用批量
这是显而易见的,甚至是Mendix推荐的。在单独的事务中运行批次也有帮助(请参阅开始和结束事务)。也不要忘记尝试批量大小。在我们的例子中,100是魔术数字。
提示2:用SnowflakeID替换UUID
通用唯一标识符(UUID)是一个128位数字,用于标识计算器系统中的信息。
https://en.wikipedia.org/wiki/Universally_unique_identifier
除了Mendix生成的内部ID外,UUID通常还用作对象的其他标识符。UUID的优点是它们可以由外部系统生成/发送。然后,这些UUID可以用于将对象软链接在一起或从外部系统引用对象。
不幸的是,与大多数数据库模式不同,Mendix不支持特殊的UUID类型。因此,UUID以字符串形式存储,这在内存方面不是很有效率。但是更重要的是,索引和检索字符串比等效的UUID类型(PostgreSQL)慢2-5倍。
我们寻求的解决方案是用SnowflakeID替换UUID。这些是类似于UUID的唯一ID,但只有64位(而不是UUID的128位)。这意味着它们可以存储在bigint(长整数)列中。这使得我们项目中的数据检索速度平均提高了10倍。
提示3:新实体+软链接可能比添加属性更好
向大型表添加新属性可能会出现问题。尤其是当要在主流程之外设置新属性以更新大型表中的行时,这可能导致数据库锁定问题和性能下降。通过使用软链接可以消除这种危险。
与受数据库约束支持的关联(硬链接)不同,软链接仅通过其名称和用法来实现。
http://beurive.com/dbview_def_fk.html
请记住,软链接使应用程序更加复杂,因为它们不支持通过关联进行检索。这尤其会影响页面设计,这将需要一些创造力和额外的数据视图/ NPE(非永续对象)来构建。请仅在需要时谨慎使用软链接。
提示4:枚举比布尔更好
布尔值在Mendix中是一种特殊的数据类型,因为它们是唯一没有空值的数据类型。将新的布尔列添加到大型表时,这将成为问题。表中的每一行都需要初始化为true或false,这可能需要很长的时间(小时)。解决方案是改用枚举,并使默认值与空值匹配。
提示5:Mendix Cloud中的数据库架构更新
不可避免地,您将不得不在Mendix中更改域模型或更新/迁移数据。当此更改影响大型表时,可能需要很长时间才能更新数据库。Mendix对应用程序启动设置了大约10分钟的限制,其中包括数据库架构更新以及启动后的微流。这意味着,如果数据库架构更新+启动微流后耗时超过10分钟,则您的应用将无法启动,甚至使您的数据库损坏。
因此,如果您希望启动过程花费的时间超过10分钟,请与Mendix支持人员联系,并要求他们暂时禁用超时。然后,您可以继续部署您的应用程序。
我们希望您喜欢阅读这篇文章,并且它可以帮助您构建出色的应用程序。
Go make it!
更多信息,请访问以下链接:
Mendix官网:https://www.mendix.com/zh/
Mendix行业解决方案:https://solutions.mendix.com/
Mendix平台指南:https://www.mendix.com/evaluation-guide/
Mendix动画展示:https://www.mendix.com/demos/