2

我现在用 Mysql 得到了什么

这是我的数据库：

在此处输入图像描述

我使用边界框按位置搜索用户。

还有两个表：user_tag 和 tags。整个数据库大小约为1 Gb。

我已经用这些表实现了一个任意标签系统，所以当用户想要使用尚未创建的标签时，这个标签被插入到标签表中。

我还按标签搜索用户。

基准

除了主键上的索引外，我在这个数据库中没有索引。

正如你所看到的，有很多插入，它们需要很长时间。

这里的主要问题是耗时的插入和更新。

使用标签创建新事件（~150ms）：

http://pastebin.com/vyw6qhrN

更新事件（~200ms）：

http://pastebin.com/f28yvn9z

我不喜欢这个解决方案：

  1. 当我创建新用户时，我会插入 3 个表以将用户与他的标签链接起来。
  2. 更新用户信息时，我还需要在用户更改标签时进行 3 次更新和 1 次删除或插入。
  3. 通过标签搜索用户变得非常混乱（复杂查询）（如何实现标签系统）

我能用 NoSql 得到什么

我想使用面向文档的数据库。然后我只需要一个集合：

{
"name": "Dan",
"lat": 60
"lon": 30
"tags":["football", "fishing"]  
}

我将能够在标签和lat和lon上设置索引以加快搜索速度。

我的问题

  1. 我应该切换到 NoSql 还是我可以以某种方式改进我当前的实现。或者也许切换到不同的RDBMS？
  2. 如果我应该切换：在这种情况下哪个 NoSql 数据库是最好的？
  3. 如果我应该切换到MongoDb：它是否足够可靠和成熟？因为我读过很多关于人们离开MongoDb的帖子。例如：http ://www.reddit.com/search?q=mongodb
4

1 回答 1

2

这两种技术都可以解决您的问题。有些场景使用 RDBMS 更容易处理，而另一些场景则使用更专业的数据库。这取决于您的要求、您的经验和您的个人喜好的详细信息。

@mvp 评论了“SQL 的便利性”。就个人而言，我发现 SQL 是一个主要的痛点，因为面向对象和 SQL 不容易映射。人们经常使用他们的 ORM 庞然大物，我发现这是一种反模式——ORM 代码大小可能是你拥有的整个应用程序代码的 50 倍以上，所以有些东西很可疑。但这只是我的看法，SQL 可能仍然是最常见的数据存储。

就个人而言，我觉得你的问题很好地映射到 MongoDB，因为

  • 它具有地理索引并支持各种地理查询
  • 如果您需要的话，创建简单的标记非常容易
  • 这很容易，处理几 GB 的数据也很容易。
  • 这很容易管理。我不需要innodb_buffer_pool_size在那种规模上插手什么。
  • 连接被高估了。需要连接，因为您拆分了属于一起的数据以将其压缩到表中。如果您想找到诸如“喜欢足球并且住在 foo 中的用户也喜欢？”之类的问题的答案，聚合框架和缓存比巨大的连接更容易且更具可扩展性。

如果我是你，我会坐下来一两天试一试：你有一个合理大小的数据集，所以你可以用真实世界的数据进行测试，并且只改变几个查询应该很容易。这会很有趣，你会亲身体验到优点和缺点。

顺便说一句，reddit 上的三篇文章相互引用：pastebin 上的“不要使用 MongoDB”、news.ycombinator.com 上的 Eliot Horowitz 的回答和“MongoDB 的故事是个骗局”，所以不，MongoDB 没有'不仅仅是随机崩溃并且有无数的错误。但是，当然，它不是神奇地使缩放问题消失的灵丹妙药。

于 2013-02-08T11:18:24.060 回答