我应该为类似社交网络的应用程序选择关系数据库还是非关系数据库答案

【问题标题】：Should I choose relational or non-relation database for social-network like app我应该为类似社交网络的应用程序选择关系数据库还是非关系数据库
【发布时间】：2010-02-20 18:35:52
【问题描述】：

我正在为我的应用程序选择数据库。我使用 MySQL 的时间最长，但对于我当前的应用程序来说，性能和可扩展性很重要，我知道 MySQL 有其局限性，我听说过很多关于键值存储、基于列的数据库和基于文档的数据库等.我调查过：

卡桑德拉
MongoDB
Redis
沙发数据库

它们似乎（或声称）都比 MySQL 等关系数据库更快。
我正在使用 Ruby on Rails，上面有所有客户端，所以这应该不是问题。

我的数据模型大部分都很简单，它以与照片、视频、帖子等不同项目相关的用户对象（具有丰富的个人资料和偏好）为中心，并且每一个都有一个标签或更多。

事实上，这些数据库是新的，网上似乎没有很多资源可供他们使用。此外，它们在结构上有所不同，因此稍后从一个切换到另一个并非易事。

我希望您能就您认为最适合我的应用程序的具有良好性能和规模的数据库提供您的意见。谢谢，

谭

【问题讨论】：

您能否详细说明性能和可扩展性？ Wikipedia 与 MySQL 后端配合得很好。对了，你有没有想过写一些原型？
感谢 Tadeusz。我的意思只是一般的性能和可扩展性。我使用的对象模型与 Wikipedia 对象模型不同，所以我想知道对于我的特定应用程序来说，最好的选择是什么，因为从我读到的内容来看，无论是关系数据库还是非关系数据库，都没有本质上的好/坏哪个更适合某些应用程序的问题。
一般性能和可扩展性是一个需求收集错误。也是一个昂贵的。

标签： database database-design recommendation-engine

【解决方案1】：

第 1 步）使用您最擅长的任何技术创建您的设计。

第 2 步）发布您的社交网络，开始研究非关系数据库并掌握您觉得最舒服的数据库。

第 3 步）重构您的数据层，以便您可以使用新学习的数据库技术快速轻松地替换 MySQL。

第 4 步）等待您的网站变得如此之大，以至于需要更换 MySQL 并开始填补漏洞。

我知道这似乎有点厚颜无耻，但实际上我的意思是发布您的软件并开始担心规模等问题。

【讨论】：

+1 尤其适用于 1) 和 2)。运输是比可扩展性更重要的功能。
把这种方法走得太远是软件糟糕的原因。
而恰恰相反的是为什么软件项目会失败、超出预算或时间用完。没有完美的解决方案。

【解决方案2】：

文档数据库之类的东西的主要好处是，至少对于您的应用而言，您可以将整个用户信息组视为单个文档。您不必担心为属性、新功能或其他任何内容添加表格，而是可以将大部分内容保存在用户文档中并动态更新。

经常阅读，少写，这是一种享受。

现在您不需要“文档数据库”来执行此类操作。 MySQL et al 可以使用主键和 CLOB（文本）/BLOB 字段来保存文档。

CouchDB（我在这个领域中我最熟悉的那个）之类的东西可以提供帮助的地方是它具有良好的复制支持，并且可以直接在文档的特定属性上创建视图（例如，您想要所有“首映”成员，或其他）。

另外，由于 CouchDB 是 HTTP，它可以很好地与现代缓存等可用的缓存配合使用，这可以帮助您进行扩展，尤其是在读取繁重的操作时。

其中很多是关于整体架构而不是实际工具，因此请务必先考虑这一点。

【讨论】：

【解决方案3】：

还有Tokyo Cabinet被一些大型网站使用。

我还没有使用过，但我的理解是，当 Twitter 等网站需要快速处理大量消息时，RDBMS 的开销非常大，并且开始显着减慢响应时间。

您需要做的是查看您从 RDBMS 获得的优势，并将其与速度进行权衡，然后对 nosql 类型的数据库执行相同的操作。

RDBMS 为您提供标准，它们为您提供安全性、完整性和基于集合的通用语言，使数据操作更容易。但是，如果您不需要该结构的全部或任何部分，您将失去速度。

在 SQL 之前是 CODASYL 和网络数据库。由于技能的可移植性和可转移性等原因，SQL 接手了。但我认为移动有线世界正在改变这一点，值得研究。

【讨论】：