应用程序功能 持久性替代方案 - NoSQL 还是 RDBMS？
我正在制作一个具有社交网络某些功能的系统。我想知道您对最适合某些功能的持久性技术有何看法。
让我们以系统的三个基本功能为例：
- 用户流 - 应用程序中的所有用户活动都会被记录，然后显示在用户个人资料上，这就像 Facebook 墙一样。这将是应用程序的主要焦点之一，并且需要具有尽可能最佳的性能。
- 应用程序和安全日志 - 这是存储应用程序错误以及其他用户相关数据的位置，例如：IP、地理空间位置、历史日志等。这部分将用作附加的安全层。
- 应用程序、用户和其上显示的广告的统计信息。
针对上述每一项特征，理想的持久性技术是什么？如果某些答案是关系数据库，为什么最好选择关系数据库而不是 NoSQL？如果答案是 NoSQL，那么最推荐的 NoSQL 是什么？
抱歉有很多问题，但我正在研究我可以采取的选择，并希望听到那些已经了解该主题的人的意见，这样我就不会做出仓促的决定。
注意：如果您可以改进问题的标题，请随时这样做。
I'm making a system with some features of a social network. And I want to know what your thoughts on the persistence technologies that best apply to certain features.
Let's take three basic features of the system:
- User Stream - All user activity in the application will be recorded, and then displayed on the user profile, it would be something like the Facebook wall. This will be one of the major focus of the application, and it need to have the best performance possible.
- Application and security logs - Here is where the application errors were stored, and other user-related data such as: IP, geo-spatial location, history log, etc. This part would be used as an additional layer of security.
- Statistics of the application, users and ads displayed on it.
What would be the ideal persistence technology for each one of the above characteristics? If some of the answers is a relational database, why would be best to choose a relational database over a NoSQL? And if the answer is a NoSQL, what would be the most recommended NoSQL?
Sorry for many questions, but I'm studying the choices that I can take, and would like to hear from those who already understand the subject so I do not take precipitated decisions.
Note: If you can improve the title of the question, please feel free to do so.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在进入用例之前，NoSQL 可以解决几个问题。无论您在这里得到什么答案，请考虑以下问题：
现在介绍您的用例：
User Stream=>NoSQL绝对可以解决这个问题，因为这里没有100%的一致性要求。话虽如此，有趣的是你提到了 Facebook，因为他们依靠庞大的 MySQL 农场来解决这个问题:)
应用程序和安全日志=>NoSQL 非常擅长存储日志，事实上，一些 NoSQL 解决方案构建在之上的许多数据结构都是类似日志的结构：
Log-Structured Merge-Tree即/用于 Google BigTabe、Cassandra 等。另外，日志可能会变得非常巨大，因此使用 NoSQL 可以更轻松地扩展大小应用程序统计=>您在这里没有提供太多细节，但是 NoSQL 绝对可以解决
显示统计信息。现在回答您的问题：是否您应该采用 NoSQL。说实话：
如果大多数 NoSQL 专家摘下面具，他们都会同意开发人员日常解决的大部分问题可以通过 SQL 解决方案来解决，例如PostgreSQL、MySQL 等。在其之上有一些很酷的 Redis 缓存层。只有一小部分问题能真正从 NoSQL 中受益。
如果您决定使用NoSQL，我会推荐基于Erlang的解决方案（Riak、CouchDB），因为NoSQL、容错数据库应该具有极其强大、灵活和自然分布式的基础=>例如 Erlang OTP。再加上简单就是王道。当然，他们有大多数语言的客户端，所以如果你不想的话，你甚至不需要知道如何拼写 Erlang。
Before going into use cases, NoSQL is there to solve several problems. No matter what answer(s) you get here, think about these questions:
Now to your use cases:
User Stream=>NoSQL can definitely solve this problem, since there is no 100% consistency requirement here. Having said that, it is funny that you mentioned Facebook, as they rely on huge MySQL farm to solve this problem :)
Application and security logs=>NoSQL is great at storing logs, in fact many data structures that some of NoSQL solutions are built on top of are log like structures:
Log-Structured Merge-Treethat is/was used in Google BigTabe, Cassandra, and others. Plus logs can grow to be quite huge, hence being able to scale in size is easier with NoSQLStatistics of the application=>You did not provide much details here, but NoSQL can definitely solve
displaying stats.Now to your question of should you go NoSQL. The truth be told:
If most of NoSQL gurus take their masks off, they will all agree that MOST of the problems that developers solve day to day, can and rather be solved with a SQL solution, such as PostgreSQL, MySQL, etc.. with some cool Redis cache layer on top of it. And only a small subset of problems would REALLY benefit from NoSQL.
In case you decide to go with NoSQL, I would recommend an Erlang based solutions (Riak, CouchDB), since a NoSQL, fault tolerant DB should have an extremely strong, flexible and naturally distributed foundation => such as Erlang OTP. Plus simplicity is king. They, of course, have clients for most languages, so you would not need to even know how to spell Erlang if you don't want to.