我应该为社交网络之类的应用程序选择关系数据库还是非关系数据库
我正在为我的应用程序选择数据库。我使用 MySQL 的时间最长，但对于我当前的应用程序来说，性能和可扩展性很重要，我知道 MySQL 有其局限性，并且我听说过很多有关键值存储、基于列的数据库和基于文档的数据库等的内容。我研究过：
- Cassandra
- MongoDB
- Redis
- CouchDB
它们似乎（或声称）比 MySQL 等关系数据库更快。
我正在使用 Ruby on Rails，并且以上所有内容都有客户端，因此这应该不是问题。
我的数据模型在很大程度上很简单，它以与照片、视频、帖子等不同项目相关的用户对象（具有丰富的个人资料和偏好）为中心，并且每个项目都有一个或多个标签。
事实上，这些数据库是新的，网上似乎没有很多资源。另外，它们在结构上有所不同，因此以后从一个切换到另一个并不容易。
我希望您能向我提供您认为最适合我的应用程序且具有良好性能和规模的数据库的意见。 谢谢，
谭
I'm in the process of choosing database for my application. I have been using MySQL for the longest time but for my current application Performance and Scalability is important and I know MySQL has its limitation and I have been hearing a lot about key-value stores, column-based DBs and document-based DBs and others. I have looked into:
- Cassandra
- MongoDB
- Redis
- CouchDB
They all seem (or claim) to be faster than relational DBs such as MySQL.
I'm using Ruby on Rails and there are clients for all the above so it shouldn't be a problem.
My data model is simple for the most part which is centered on a user object(with rich profile and preferences) related to different items such as photos, videos, posts...etc and each one of these has one tag or more.
The fact that these databases are new there doesn't seem to be a lot of resources for them online. Plus they are in a way structurally different so it will not be trivial to switch from one to another later.
I wish you can give me your input on what DB you think would be most suit my application that will have good performance and scale.
Thanks,
Tam
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
步骤 1) 使用您最擅长的任何技术创建您的设计。
步骤 2) 发布您的社交网络，开始研究非关系数据库并掌握您觉得最舒服的数据库。
步骤 3) 重构您的数据层，以便您可以使用新学到的数据库技术快速轻松地替换 MySQL。
步骤 4) 等待您的网站变得如此之大，以至于需要更换 MySQL 并开始堵塞漏洞。
我知道这看起来有点厚颜无耻，但实际上我的观点是发布你的软件并开始担心规模等，当它实际上成为一个问题时。
Step 1) Create your design using whatever technology you are strongest with.
Step 2) Release your social network, begin on researching non-relational databases and master whichever you feel most comfortable with.
Step 3) Refactor your data tier so you could potentially replace MySQL quickly and easily with your newly learned DB technology.
Step 4) Wait for your website to become so big that the need to replace MySQL comes around and begin to plug the holes.
I know this seems kind of cheeky, but really my point is just release your software and start to worry about scale etc. when it actually becomes a concern.
文档数据库之类的主要好处（至少对于您的应用程序而言）是您可以将整个用户信息块视为单个文档。您不必担心添加属性表、新功能或其他任何内容，而是可以将大部分内容保留在用户文档中并动态更新。
对于经常阅读、很少写作的人来说，这是一种享受。
现在您不需要“文档数据库”来执行此类操作。 MySQL 等可以使用主键和 CLOB（文本）/BLOB 字段来保存文档。
CouchDB（我在这个领域最熟悉的一个）之类的东西可以提供帮助，因为它很好地支持复制，并且可以直接创建有关文档的特定属性的视图（例如，您想要所有“premiere”）成员或其他）。
另外，由于 CouchDB 是 HTTP，因此它可以很好地与现代缓存等配合使用，这可以帮助您进行扩展，特别是在读取繁重的操作中。
其中很多更多的是关于整体架构而不是实际的工具，所以请确保您首先考虑这一点。
The primary benefit of something like a document database, at least for your app, is that you can treat the entire User glob of info as a single document. You don't have to worry about adding table for properties, or new features, or whatever, rather you can keep the bulk of it in the user document and update it dynamically.
For read often, write rarely, this works a treat.
Now you don't need a "document database" to do something like this. MySQL et al will work just fine with a primary key and a CLOB (text) / BLOB field to hold the document.
Where something like CouchDB (the one that I'm most familiar with in this space) can help is that it has well supported replication, and it's straightforward to create views on specific attributes of the documents (for example, you want all "premiere" members, or whatever).
Plus, since CouchDB is HTTP, it works well with the modern caches and such that are available, which can help you in scaling, especially in, again, read heavy operations.
A lot of this is more about overall architecture than actual tools, so make sure you consider that first.
还有一些大型网站使用的Tokyo Cabinet。
我还没有使用过，但我的理解是，当像 Twitter 这样的网站需要非常快速地处理大量消息时，RDBMS 的开销太大，并且开始显着减慢响应时间。
您需要做的是查看从 RDBMS 获得的优势，并根据其速度进行权衡，然后对 nosql 类型数据库执行相同的操作。
RDBMS 为您提供了一个标准，它们为您提供了安全性、完整性和基于集合的通用语言，使数据操作变得更加容易。但是，如果您不需要全部或任何该结构，那么您就会失去速度。
在 SQL 之前是 CODASYL 和网络数据库。 SQL 之所以被采用，是因为技能的可移植性和可转移性等。但我认为移动有线世界正在改变这一点，这值得研究。
There is also Tokyo Cabinet which is used by some large sites.
I have not yet used on but my understanding is that when site like Twitter need to turn large numbers of messages round very quickly the overhead of the RDBMS is just to great and starts to slow the response times down significantly.
What you would need to do is look at the advantages you get from an RDBMS and weigh that against it's speed then do the same in reverse for a nosql type database.
RDBMS's give you a standard, they give you security, integrity and a general purpose language based on sets to make data manipulation easier. However if you do not need all or any of that structure you are loosing out on speed.
Prior to SQL was CODASYL and network databases. SQL took ove because of portability and transferability of skills etc. But i think the mobile wired world is changing this and it would be worth investigating.