NoSQL 指的是非关系数据存储,它打破了关系数据库的历史和 ACID 保证。流行的开源 NoSQL 数据存储包括:
我想了解您(SO 读者)使用数据存储解决的具体问题以及您使用的 NoSQL 数据存储。
问题:
我正在寻找第一手经验,所以除非你有,否则请不要回答。
我已经将一个小型子项目从 MySQL 切换到 CouchDB,以便能够处理负载。结果是惊人的。
大约 2 年前,我们在http://www.ubuntuusers.de/(这可能是德国最大的 Linux 社区网站)上发布了一个自写软件。该站点是用 Python 编写的,我们添加了一个 WSGI 中间件,它能够捕获所有异常并将它们发送到另一个小型 MySQL 驱动的网站。这个小网站使用哈希来确定不同的错误,并存储出现的次数和最后一次出现的次数。
不幸的是,在发布后不久,traceback-logger 网站不再响应。我们的主站点的生产数据库存在一些锁定问题,几乎每个请求都会抛出异常,以及其他几个我们在测试阶段尚未探索的错误。我们主站点的服务器集群,每秒调用 traceback-logger 提交页面数 k 次。这对于托管回溯记录器的小型服务器来说太过分了(它已经是一台旧服务器,仅用于开发目的)。
当时 CouchDB 相当流行,所以我决定尝试一下,并用它编写一个小的 traceback-logger。新的记录器只包含一个 python 文件,它提供了一个带有排序和过滤选项的错误列表以及一个提交页面。在后台,我启动了一个 CouchDB 进程。新软件对所有请求的响应速度非常快,我们能够查看大量的自动错误报告。
一个有趣的事情是,之前的解决方案是在旧的专用服务器上运行的,而另一方面,基于 CouchDB 的新站点仅在资源非常有限的共享 xen 实例上运行。而且我什至没有使用键值存储的优势来横向扩展。CouchDB / Erlang OTP 在不锁定任何内容的情况下处理并发请求的能力已经足以满足需求。
现在,快速编写的 CouchDB-traceback 记录器仍在运行,是探索主网站上的错误的有用方法。无论如何,大约每月一次,数据库变得太大,CouchDB 进程被杀死。但是随后,CouchDB 的 compact-db 命令再次将大小从几 GB 减小到几 KB,并且数据库再次启动并运行(也许我应该考虑在那里添加一个 cronjob ...... 0o)。
总而言之,CouchDB 无疑是这个子项目的最佳选择(或者至少比 MySQL 更好),而且它的工作做得很好。