什么是存储设备配置信息的好机制
What's a good mechanism to store device config information
我有 10k 台设备，它们具有相同的配置属性但不同的值。配置文件包括名称、类型、型号、制造年份、温度、用途、状态。前 4 个值不变，后 3 个值每隔几秒不断变化。每个设备都连接了一台计算机。
以下两种存储配置的方式，哪种更好？
1）方式一：将配置信息放在一个json文件中，并将json文件存储在连接设备的电脑上；
2)方式二：将配置信息放入数据库table.
方式1的优点是延迟少，但数据难维护。方式 2 有更多的延迟，但更容易维护。我们可以创建一个 API 来从 table 中获取数据。如果设备越来越多，方式 2 也会出现 TPS 问题。例如，如果有 80k 台设备，并且每台设备都在同时向数据库写入配置数据table。
更新：正如Ciaran McHale所说，这三个变量是动态信息，所以我在问题中添加了以下信息：
这 3 个变量（温度、使用情况、状态）是动态信息，可以保存在内存中，但我们也希望将最终值保存在某个地方，以便在我们重新启动设备或应用程序时我们知道这些值。所以我的问题是关于保留这些最终值的良好机制。 （数据库 table 与本地 json/xml/txt 文件）。
在我看来，只有前 4 个变量（类型、型号、制造商和年份）属于配置文件。由于其他 3 个变量（温度、使用情况、状态）每隔几秒更改一次，它们实际上是应该保存在内存中的动态状态信息，您应该提供一个 API 以便可以检查此状态信息。 API 可能是，例如，通过客户端-服务器套接字连接，或通过共享内存。你可能会说，“我不能那样做，因为[某某]”，所以我建议你用这样的推理更新你的问题。这样做可能会帮助您获得更有用的答案。
根据更新问题中提供的额外信息进行编辑...
我即将提出的建议将适用于 Linux。我不知道其他操作系统。您可以执行 man shm_open 和 man mmap 来了解共享内存。共享内存段可以在进程重启后继续存在，并备份到文件（在磁盘上），因此它可以在机器重启后继续存在。我（可能不正确）的理解是，大多数时候，文件的内容将缓存在内核缓冲区中，虚拟内存会将这些内核缓冲区映射到进程的地址 space，因此 reading/writing 将是一个仅内存操作；因此你不会遭受频繁磁盘 I/O.
为简单起见，我将假设每个设备都需要存储相同类型的动态信息，并且可以用固定长度struct表示，例如：
struct DeviceData {
double temperature;
SomeEnum usage;
AnotherEnum status;
};
您可以拥有一个足够大的共享内存段来存储一个数组，比方说，100,000 个 DeviceData 结构。每个设备的静态配置文件将包含如下条目：
name="foo";
type="bar";
model="widget";
manufacture_year="2020";
shared_memory_id="/somename";
shared_memory_array_index="42";
静态配置文件中的最后两个条目指定进程应该连接到的共享内存段，以及它应该用来更新与进程关联的 DeviceData 的数组索引。
如果以上看起来适合您的需求，那么要应对的挑战是共享内存中 reading/updating 和 DeviceData 的高效同步。一篇名为 A scalable reader/writer scheme with optimistic retry 的博客文章讨论了一个很好的基本方法。该博客文章使用 C# 来说明这个概念。如果您使用的是 C++，那么我建议您阅读 C++ 并发操作 的第 5 章（C++ 内存模型和原子类型操作）安东尼·威廉姆斯。顺便说一句，如果您可以使用填充来确保 DeviceData（包括博客文章中使用的 m_version1 和 m_version2 的字段）与一个或多个缓存行的大小完全相同（在大多数 CPU 架构中，缓存行是 64 字节）那么您的实现将不会受到 虚假共享 的影响（这会不必要地降低性能）。
最后一步是避免向开发人员公开低级共享内存操作。因此，编写一个简单的包装器 API，其中包含四个操作：connect() 到共享内存段和 disconnect()，以及 readDeviceData() 和 updateDeviceData()。
我有 10k 台设备，它们具有相同的配置属性但不同的值。配置文件包括名称、类型、型号、制造年份、温度、用途、状态。前 4 个值不变，后 3 个值每隔几秒不断变化。每个设备都连接了一台计算机。
以下两种存储配置的方式，哪种更好？ 1）方式一：将配置信息放在一个json文件中，并将json文件存储在连接设备的电脑上； 2)方式二：将配置信息放入数据库table.
方式1的优点是延迟少，但数据难维护。方式 2 有更多的延迟，但更容易维护。我们可以创建一个 API 来从 table 中获取数据。如果设备越来越多，方式 2 也会出现 TPS 问题。例如，如果有 80k 台设备，并且每台设备都在同时向数据库写入配置数据table。
更新：正如Ciaran McHale所说，这三个变量是动态信息，所以我在问题中添加了以下信息：
这 3 个变量（温度、使用情况、状态）是动态信息，可以保存在内存中，但我们也希望将最终值保存在某个地方，以便在我们重新启动设备或应用程序时我们知道这些值。所以我的问题是关于保留这些最终值的良好机制。 （数据库 table 与本地 json/xml/txt 文件）。
在我看来，只有前 4 个变量（类型、型号、制造商和年份）属于配置文件。由于其他 3 个变量（温度、使用情况、状态）每隔几秒更改一次，它们实际上是应该保存在内存中的动态状态信息，您应该提供一个 API 以便可以检查此状态信息。 API 可能是，例如，通过客户端-服务器套接字连接，或通过共享内存。你可能会说，“我不能那样做，因为[某某]”，所以我建议你用这样的推理更新你的问题。这样做可能会帮助您获得更有用的答案。
根据更新问题中提供的额外信息进行编辑...
我即将提出的建议将适用于 Linux。我不知道其他操作系统。您可以执行 man shm_open 和 man mmap 来了解共享内存。共享内存段可以在进程重启后继续存在，并备份到文件（在磁盘上），因此它可以在机器重启后继续存在。我（可能不正确）的理解是，大多数时候，文件的内容将缓存在内核缓冲区中，虚拟内存会将这些内核缓冲区映射到进程的地址 space，因此 reading/writing 将是一个仅内存操作；因此你不会遭受频繁磁盘 I/O.
为简单起见，我将假设每个设备都需要存储相同类型的动态信息，并且可以用固定长度struct表示，例如：
struct DeviceData {
double temperature;
SomeEnum usage;
AnotherEnum status;
};
您可以拥有一个足够大的共享内存段来存储一个数组，比方说，100,000 个 DeviceData 结构。每个设备的静态配置文件将包含如下条目：
name="foo";
type="bar";
model="widget";
manufacture_year="2020";
shared_memory_id="/somename";
shared_memory_array_index="42";
静态配置文件中的最后两个条目指定进程应该连接到的共享内存段，以及它应该用来更新与进程关联的 DeviceData 的数组索引。
如果以上看起来适合您的需求，那么要应对的挑战是共享内存中 reading/updating 和 DeviceData 的高效同步。一篇名为 A scalable reader/writer scheme with optimistic retry 的博客文章讨论了一个很好的基本方法。该博客文章使用 C# 来说明这个概念。如果您使用的是 C++，那么我建议您阅读 C++ 并发操作 的第 5 章（C++ 内存模型和原子类型操作）安东尼·威廉姆斯。顺便说一句，如果您可以使用填充来确保 DeviceData（包括博客文章中使用的 m_version1 和 m_version2 的字段）与一个或多个缓存行的大小完全相同（在大多数 CPU 架构中，缓存行是 64 字节）那么您的实现将不会受到 虚假共享 的影响（这会不必要地降低性能）。
最后一步是避免向开发人员公开低级共享内存操作。因此，编写一个简单的包装器 API，其中包含四个操作：connect() 到共享内存段和 disconnect()，以及 readDeviceData() 和 updateDeviceData()。