我正在做一个项目，我必须保存朋友列表。经过深思熟虑并在网上搜索最佳方法后，似乎将用户 ID 和朋友 ID 保存在一个表中。 但可以肯定的是，如果项目期望达到大规模，这种方法似乎不太好。 Google、Facebook、Twitter 等大多数大型公司也将其功能转移到了 nosql 数据库上。 那么，我们似乎不应该从这些 NoSQL 数据库开始我们的项目吗？
但与此同时，我读到 NoSQL 中有很多编码工作，因为这里没有提供关系数据库中的许多默认服务（如果我错了，请纠正我）
也许一种方法可以从关系开始，因为它在小规模上具有非常好的功能，然后转向 NoSQL，但为此你必须编写非常好的可移植代码，其中 ORM 可以发挥或不发挥良好作用?
想听听其他人对什么是正确的做法的看法？
【问题讨论】：
标签： database-design nosql scalability
远离 ORM，尤其是 ActiveRecord。
他们通常会创建一个“开发债务”，这意味着它使项目的开始看起来很容易。
当您投资了与 ORM 的完全集成并完成了 80% 的项目时，
您开始看到您的 ORM 失败的所有边界情况。
除此之外，大多数 ORM 进行次优查询并且从不利用引擎特定的功能。
对于 SQL 与 noSQL：我建议从 SQL 数据库开始，然后当应用程序增长时，开始使用一些缓存策略（memcached，或者可能是 redis）。并且仅当该解决方案用尽时 - 开始寻找不需要关系的数据库逻辑部分。
noSQL 数据库提供一系列非常具体的用例，并不适合普通应用程序。
【讨论】：
使用 SQL 数据库。
当您开始每天获得数百万用户时，请开始使用某种 NoSQL 数据库。
【讨论】：
编辑 我看到其他人建议从 SQL 开始。我想改变我的主张并说 - 尝试小规模项目，如“小型推特克隆”或“用录像带存储”。将数据库保存在许多节点上并编写脚本，这将使您充满数据。使用 Riak/Cassandra，然后使用一些 SQL 解决方案。你会发现自己更容易和更快。 /编辑
我会使用 NoSQL（这就是我现在正在做的事情。以前我在大型项目中使用 MySQL）。为什么？它使用起来要简单得多，因此您可以更多地关注其他重要的事情（NoSQL 可以解决大多数数据存储问题）：
您不必定义架构，这也意味着您不必升级它。在 MySQL 中，由于系统升级，我有很长的停机时间。添加单列/索引需要很多时间。表只有几百万行。
您可以在几分钟内获得运行的分布式环境。在 MySQL 中，您必须在几台机器之间手动拆分数据（除非您将所有内容都放在一台机器上，这不是一个好主意）。
您可以获得更好的性能。用 MySQL 性能真的很差。如果没有 memcached，它就无法工作。 Memcached 是一个分布式键值存储（简单的 NoSQL 数据库）。显然，使用 memcached 会花费您在优化查询上花费的额外时间
您不必考虑规范化/非规范化
查询很简单（至少在键值存储中）。您只是不关心以下内容：我应该使用“where UserId = 12345”还是“where UserId = '12345'”（在 MySQL 中，其中一个不会使用索引！）。
如果一台使用 NoSQL 的机器出现故障，您不必关心应用程序中的问题。查询将在另一个副本上执行（您不必执行此操作！）
使用 NoSQL 也有缺点
你没有得到酸。在大多数情况下，您只是不需要它！
还有更多的开发人员熟悉 SQL 解决方案。另一方面，NoSQL 解决方案要简单得多（至少根据我的经验），因此您不需要经过认证的数据库管理员（解决您的数据库问题的魔术师，只有他知道它为什么起作用）
您不能执行某些查询 - 例如不存在联接，但如果您不规范化数据，那么联接将毫无用处（而且您无需考虑规范化，从而节省时间） .
好文章： http://labs.mudynamics.com/2010/04/01/why-nosql-is-bad-for-startups/
我的建议是从 NoSQL 开始并坚持下去。您应该查看基于 Dynamo 的数据库，例如 Riak 和 Cassandra。也可以试试 CouchDB (CoachBase)。这适用于大部分数据。对于朋友关系图数据库是不错的选择。
【讨论】：
我认为 ORM 不会对您有太大帮助，nosql 数据库的理念与关系数据库的理念完全不同。因此，一旦您从关系开始并在模式中投入大量精力并使用它的好东西（如外键），您将不得不努力将其移至 nosql。反之亦然。
您提到的大公司正在使用 nosql，因为它提供了高吞吐量和数据库模式的简单性，同时考虑到它缺乏关系数据库提供的一些高级功能。
对于他们的会计，他们使用的是关系数据库，我敢肯定 :-)
最后，这将取决于您的架构的复杂性：如果足够简单，请尝试 nosql：设置起来要容易得多，实际上您根本不需要定义架构，您只需将记录设置为（或文档为他们中的一些人称之为）并保存它。如果您对表结构改变主意，则无需更改表：只需保存数据即可。简单：这就是它今天如此流行的原因。
但是没有参照完整性，也有一些关于事务的限制，并不是所有的都支持。因此，如果您在数据库架构、数据完整性、事务方面需要更多信息，请选择关系数据库。
【讨论】：
我在生产环境中使用 MongoDB、Riak 和其他一些 NoSQL 解决方案已有一段时间了。 我认为从一开始就使用 NoSQL 解决方案的最大好处是思维过程，您不受他们在大学教授的关系数据模型的限制，这使您更倾向于使数据适合您的需求，而不是调整您的应用程序以适应您的数据表示。
也就是说，我认为过早扩展可能不是一件好事，如果您正在构建一个新的 Web 应用程序（或一些大数据应用程序），通常需要一些时间才能达到任何需要 NoSQL（带宽，内存，性能...）
我能给你的最好的建议是使用数据模型（不是 ORM）的抽象来构建你的应用程序，例如，如果你想从 user_id 获取朋友列表，我会为“朋友存储”构建一个接口它将具有fetch_friends(user_id):friend_ids 的方法，通过保持良好的抽象，您可以在需要时更换底层实现。
我自己在存储用户数据方面也使用了这种方法。从 MongoDB 开始（我的数据是无模式的），当单个服务器的负载变得太大（在 MongoDB 进行适当的分片之前）转移到 Riak 并且需要为客户端提供更好的 SLA 时（Riak 并不是那么可靠）转向一些适当的解决方案。 每一步都需要大量的开发和集成时间开销，但到那时我们已经有足够的资源进行这样的移动了。
恕我直言，如果我是你，我会从 MySQL 开始，这样我就不需要考虑持久性、一致性或持久性，并且在遇到问题时将其换掉。
【讨论】：
SQL 与 NoSQL 对比：http://www.sigmod.org/publications/sigmod-record/1012/pdfs/04.surveys.cattell.pdf
“因此，与 NoSQL 数据存储相比，可扩展 RDBMS 具有优势，因为您拥有高级 SQL 语言和 ACID 属性的便利性，但您只需为它们跨越节点时付出代价。”
【讨论】：
playOrm 允许您将关系数据存储在 noSQL 存储中，并且仍然允许这些数据随着系统的增长而扩展，因此两全其美。
【讨论】：