javascript - 每当节点服务器上的数据发生变化时写入整个 SQL 表(很奇怪，请耐心等待)

Question

好的，让我首先说我知道这很奇怪。我愿意。

但这里有:

假设我有一个存储数据的 SQL 数据库。假设我在这方面别无选择，它必须是 SQL。我正在构建的应用程序的数据库中有大约 100,000 条记录，一旦应用程序的用户处理了每条记录，它们就会全部关闭并完全发送到不同的应用程序。所以在短时间内，这个应用程序将被使用，然后停止使用，直到明年同一时间。在使用应用程序时，根本不会有任何外部资源接触数据库。

当(节点)服务器启动时，它会将数据库中的所有内容加载到服务器上的对象文字中。

这个应用程序的客户端，在一个非常基本的层面上，发出请求(向服务器上的 API)请求数据，并在处理完记录后将更新版本的记录发送回服务器。

所以这就是奇怪的地方:假设我不希望客户端应用程序必须直接从数据库中检索记录，也不希望它能够写入它们。所以整个数据库的数据已经存在于服务器的内存中。服务器上有一个模块已经可以处理更改该数据的表示形式(同样，因为客户端应用程序只与服务器上的 API 交互，所以存在数据库模块来促进这一点)。

多个用户同时访问系统，但由于系统的工作方式，不可能向两个用户发送相同的记录，因此两个用户永远不会为相同的记录发回更新(记录是单独处理的，并依次)。

因此，假设我决定，因为我已经在服务器上的内存中管理所有这些数据，所以每次更改时，我都会将当前数据的完整更新版本发送回数据库。

问题是，这在疯狂的规模上排名在哪里？

写入整个数据库而不是单个记录的性能显然会受到影响。但是，在一个只读取一次的数据库中(在应用程序启动时)，这甚至是一个问题吗？如果除了“当任何东西发生变化时写入所有东西”之外的所有操作都发生在服务器的内存中，那么这些更新实际需要多长时间是否重要？如果在更新数据库的同时对数据库进行了新的更新，那么 SQL 肯定会解决这个问题吗？

感觉这样做的正确方法当然是让每个用户直接从数据库中获取他们的信息，并直接对数据库进行更新(或者至少与 API 端点交互以实现这一点)，但是，是只是……不这样做，完全疯了？

就像我说的，我知道这很奇怪，但除了“感觉有点不对劲”这一事实之外，我不确定我是否确信这实际上是完全错误的。所以我想这个地方会有意见。

我认为它目前的工作方式是:

每当 {in-memory DB} 发生更改时，都会更新 [SQL DB]
{in-memory DB} 根据对服务器的 API 调用以各种方式更新
发出数据请求，并发送数据更新，这两者都在内存数据库中处理

来自应用程序的多个请求可以同时发生，但多个用户看不到相同的记录，因为记录在发送之前已分配给给定用户

多个更新可以来自多个用户，每个更新最终都以将整个 SQL 数据库与内存数据库的内容一起保存到其中而结束。

(注意:我不是说“这是最好的方法吗”。我只是在问，如果不从除非需要重新启动服务器)

Answer 1

在这种情况下，我认为我会做的是为每个缓存记录添加一个属性，以指示该记录是“脏的”。换句话说，由于它最初是从数据库中读取的，因此有人对其进行了处理。

(您还可以添加一个属性来指示某人“有此特定记录'已 checkout '”，以便您可以确定两个用户不会同时更新同一记录。)

在某个方便的时刻，您可以浏览集合，将“脏”记录发回数据库。使用 SQL 事务，不仅是为了提高效率，也是为了确保对数据库的最终更新是原子的。

您需要非常注意竞争条件的可能性。一种可能的策略是使用 Unix 时间戳作为“脏”指标。只有当它的“脏时间”大于或等于上次运行提交过程时的时间戳时，才会选择一条记录以发布到数据库。

(而且，P.S.:“不，在我从事这个疯狂行业的所有疯狂岁月中，我见过比这更“奇怪”的事情......)