在Mendix中使用大型数据库表的五个技巧

​

导语

在此篇文章中，我想分享在处理带有大型数据库表的项目时所学到的一些经验教训。首先，让我们定义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://forum.mendix.tencent-cloud.com/

Mendix行业解决方案：https://solutions.mendix.com/

Mendix平台指南：https://www.mendix.com/evaluation-guide/

Mendix动画展示：https://www.mendix.com/demos/

感谢阅读！