用户设置服务数据库设计答案

【问题标题】：User settings service database design用户设置服务数据库设计
【发布时间】：2019-07-15 14:36:55
【问题描述】：

我的任务是为用户设置服务构建新服务（也称为微服务）。

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

此服务的一些功能要求：

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

行业中是否有任何关于此类服务的良好做法/原则/示例？
关系 (SQL) 或非关系 (NoSQL) 数据库更适合这种情况吗？我已经阅读过这个relational design，我想知道 NoSQL 是否适合这个用例，因为大多数时候我们都在为设置存储键值对。
我可以考虑其他替代设计吗？
假设 NoSQL 适合解决这个问题，我应该选择哪个 NoSQL 数据库？我没有使用 NoSQL 的经验，市场上有很多数据库可供选择。

【问题讨论】：

【解决方案1】：

总体而言，您的问题有点过于宽泛和模糊，但我会尝试根据您提供的信息以及您提到这是一项微服务来解决它：

首先，公司是否正在使用其他微服务或其他计划？我认为必须有，因为构建单个微服务没有意义。因此，我会检查其他服务正在使用什么并选择一种兼容的技术（或者甚至相同的技术，除非由于某种原因它真的很糟糕）
对于您所描述的，大多数数据库都可以正常工作。存储用户设置并不是一项特别密集的任务，并且可能不会生成数十亿条记录。因此，首先查看公司已经在使用的其他东西，并检查您是否可以使用相同的东西（除非他们使用的是古老的东西，在这种情况下，看看是否有其他项目计划使用不同的数据库）
NoSQL 与 SQL；对于像你这样的微服务，它真的不会有什么不同。因此，选择您喜欢的任何东西。对于关系，我建议 MariaDB 或 Postgres，对于 NoSQL，可能是 MongoDB 或 ArangoDB。但这些都是个人喜好。网络上的每个人都会提出不同的建议。
您应该考虑替代设计吗？嗯，微服务今天风靡一时，所以你选择它是可以理解的。我认为这是一个很棒的架构，但你应该知道，随着微服务数量的增加，它的灵活性和可维护性是要付出代价的，那就是可追溯性。只要您充分了解它的优点和缺点，就没有真正的理由不使用它。我建议您阅读Microservices in Action 以获得很好的介绍。

【讨论】：

非常感谢！我想解决您的一个问题： - 当前设置是我们有不同的服务将处理不同的用户设置，因此数据分散在多个地方。这项新服务的目的是将所有这些数据聚合到一个地方，如果我们能够拥有单一的事实来源，它就更易于维护和追踪。