用户设置服务数据库设计

Question

我的任务是为用户设置服务构建一个新服务(即一个微服务)。

此服务的目的是在系统中存储用户的设置。设置大多以user_id的键值对的形式出现.

此服务的某些功能要求：

• 服务的设计应该使其在读取时具有可伸缩性。
• 服务的设计应该使其易于插件和可扩展。假设将来我们希望在系统中引入更多类型的用户设置，只要付出最少的额外努力，它就很容易完成。

目前，我正处于这项服务的数据库设计和建模阶段，我有一些问题想问：

• 业界是否有关于这类服务的良好做法/原则/例子？
• 关系数据库(SQL)或非关系数据库(NoSQL)是否更适合这种情况？我已经读过关于这个关系设计的文章了，我想知道NoSQL是否适合这个用例，因为大多数时候我们都在为这个设置存储键值对。
• 我还可以考虑另一种设计方案吗？
• 假设NoSQL适合解决这个问题，我应该选择哪个NoSQL数据库？我没有使用NoSQL的经验，市场上有很多数据库可供选择。

Answer 1

你的问题在总体上有点过于宽泛和模糊，但我将根据你提供的信息，并考虑到你提到这是一项微观服务，设法解决这个问题：

• 首先，该公司是否还在使用其他微型服务或其他计划中的服务？我认为这是必须的，因为建立一个单一的微型服务是没有意义的。因此，我会检查其他服务正在使用什么，并选择一种兼容的技术(或者甚至是相同的技术，除非出于某种原因，它确实很糟糕)。
• 对于您所描述的，大多数DB都会做得很好。存储用户设置并不是一项特别密集的任务，而且可能不会产生数十亿条记录。因此，先看看公司还在使用什么，然后检查是否可以使用相同的东西(除非他们使用的是一些古老的东西，在这种情况下，看看是否还有其他项目计划使用不同的DB)。
• 对于像您这样的微服务来说，NoSQL和SQL没有什么区别。因此，选择任何你觉得舒服的东西。对于关系关系，我建议使用MariaDB或Postgres，对于NoSQL，可能是MongoDB或ArangoDB。但这些都是个人喜好。网络上的每个人都会提出不同的建议。
• 你应该考虑另一种设计吗？嗯，微观服务今天风靡一时，所以你选择了这一点是可以理解的。我认为它是一个很好的体系结构，但是您应该知道，随着微服务数量的增加，它的灵活性和可维护性要付出代价，这就是可追溯性。只要你知道它的优点和缺点，就没有真正的理由不使用它。我建议您阅读行动中的微型服务，以获得一个很好的介绍。