使用springboot从Mysql获取数百万数据[关闭]答案

【问题标题】：Fetching millions of Data From Mysql using springboot [closed]使用springboot从Mysql获取数百万数据[关闭]
【发布时间】：2019-11-06 06:36:04
【问题描述】：

我的情况是从 Mysql 获取大量数据到我的 springboot 应用程序。

那么有没有更好的方法来实现这个场景？

【问题讨论】：

为什么您的应用程序需要 1000 万条记录？
这些数据将在整个应用程序中使用。因此，获取它一次将减少对 mysql 的点击次数...
这对我来说听起来很不对劲。您是否期望实际使用所有行或接近所有行？如果不是，这将是巨大的浪费或资源。此外，如果您更改任何数据并想要将其写回，JPA 无论如何都会重新加载它，除非您在一个巨大的会话中做所有事情，这将是另一个巨大的 PITA 并使应用程序非常慢。如果您需要加快随机访问速度并且您的 MySql 数据库没有减少它，我会根据您的需要查看其他存储，例如内存数据库或文档数据库。请说明您的实际要求是什么。
如果要在表格中显示数据，可以使用Pageable object 进行分页，也可以实现 fetch type lazy。如果您将数据用于导出报告，则应使用 Spring Batch。

标签： mysql hibernate spring-boot jpa spring-data-jpa

【解决方案1】：

最大的问题是：您想用这 1000 万条记录做什么？ JPA 主要适用于加载有限的对象图，然后您可以对其进行操作并将其刷新回数据库。这仅适用于相当有限的数据量。处理大量数据时，开销会变得令人望而却步，而好处往往会消失。

如果没有任何进一步的知识，我建议您离开 JPA 并考虑使用更底层的方法来访问数据。尤其是 Springs JdbcTemplate 经常派上用场。如果适用，则使用RowCallbackHandler 的方法，因为它不假定您将ResultSet 转换为其他任何东西，而只是处理它，例如为了将数据写入某个文本文件。

处理大量数据时要注意的另一件事是Spring Batch。

【讨论】：

基于 1000 万条记录，只有剩余的应用程序可以工作。我们不知道它需要哪条记录。所以，一旦我们从 mysql 获取所有数据，我们就不必每次都访问 mysql 服务，然后我们可以在本地处理。就是这样，我正在搜索..
您是否在应用程序本身的首页处理 1000 万条记录？
@Shivakumar 它不适用于 UI 兄弟...
@vishnumurali 似乎您想将 jpa 用作内存缓存。通常，ORM 并不特别适合这项任务，因为它们速度慢并且占用大量内存。 RDBMS 旨在允许快速查找和检索数据。让mysql做它的设计，只在你需要的时候缓存数据。

【解决方案2】：

无法在 UI 中一次显示 1000 万条记录以供用户理解。我建议您通过 UI 导航保留与每页所需记录数相关的数字。
如果这 1000 万条记录要在 UI 中再次进行事务，我建议您在保存的同时将事务数据保留在这些行中，以便您无需再次迭代。
您可以识别唯一列并配置复合主键。这将减少查询时间。
最小化连接。如果要连接太多表，请减少连接数。不要过度规范化数据库。
如果您以某种格式将图像保存在数据库中，请将它们移动到文件系统，将文件系统路径和图像名称保存在数据库中。
减少列数。例如：在 100 列中，您可能只需要在任何时间点在 UI 中显示 5 或 10 列，将它们保存在一个表中，其余 95-90 列在另一个表中。观察查询的长度。
使用连接池机制。

【讨论】：

UI 不需要。为了处理输入，我需要这些数据。
获取数据库后不处理输入。在保存或更新时将处理后的数据保留在数据库中，以便您无需再次执行任何处理。点号2
@vishnumurali，有没有 cmets？
我刚刚发现有一个名为 Speedment 的工具，它是基于 Java8 的 ORM 工具，有助于以非常快速的方式检索数据。
好的。让我们知道它是否有效。但是，重要的是要确定您可能需要如此庞大数据的原因。这就是根源。

【解决方案3】：

如果加载 100 万行需要 2-3 秒，但加载 1000 万行需要 24 分钟，那么我认为这是内存问题。 JPA 维护了许多关于持久对象的额外 ino，因此只要对象在事务中，内存需求就可能比存储数据本身的实际需求高得多。

所以将数据在事务之外加载为较小的块（例如 100 万个），然后手动将它们组装到一个集合中。如果您需要这些记录来进行某种计算，那么仅此而已。如果您还需要对其进行更改，则需要手动处理修改并保存。

虽然我仍然相信如果您与我们分享原始问题，我们可以找到更好的解决方案...

【讨论】：