Adi*_*och 4 nosql database-recommendation memory couchdb couchbase
我开始在我的生产站点上遇到一些问题，当有一个网页需要加载一个非常大的 ResultSet（目前来自关系数据库，MySQL）时，它需要永远，而且这些结果集只会越来越大。
我开始寻求更好的解决方案，我遇到的是将数据保存在 NoSQL 数据库中的想法。（我已经在使用 Mongo，但由于我的环境中存在大量 DML，Mongo 效率低下。）因此，在网上搜索时，我考虑了以下 2 个选项：
当查看以上两个时，我可以说两者都是基于 JSON 文档的（好吧，这是一个好的开始），但是当进入一些技术背景时，我确实在寻找更好的缓存（我不想杀死我的服务器的 I/O）然后是 MongoDB 的主-主复制能力（我看到 CouchDB 可以根据源->目标/目标->源轻松复制）。
有人可以向我提供您的一些意见，如果您尝试过上述解决方案，我将很高兴听到您的经验。
Chr*_*ers 13
IMO，您在网页方面犯了可能是一个非常常见的错误，即假设由于 MySQL 的初始结果大小而导致的性能问题的答案是跳到 NoSQL 解决方案，通常对权衡是什么或什么知之甚少如何正确有效地使用它们。
如果结果集的大小是问题所在，那么如果一个经过良好调整的数据库实际上是 Web 应用程序的问题，我会感到惊讶。一个简单的事实是，结果集只能如此快地从磁盘检索（假设您没有使用主内存数据库，其中所有内容都强制在 RAM 中），然后您实际上必须花时间处理结果集才能获得您的网页。在假设它是数据库之前，您需要首先对所有内容进行全面分析。
您在 NoSQL 中最基本的权衡是数据输入的灵活性和易于扩展与完整性保证和输出数据处理。在 NoSQL 中对任意大小的结果集进行数据处理的唯一方法是在输入上进行数据处理，如果以牺牲传统 RDBMS 为代价使用 NoSQL 解决方案，这将对产品的生命周期产生重大影响。另一方面，这些提供对 RDBMS 的附件是否合适，这对预处理和后处理都有帮助。简而言之，选择 NoSQL 是有原因的，但规模确实不是其中之一。
现在，您在这里提到这是一个加载“非常大的结果集”的“网页”。现在，我有时会用网络应用程序做一些疯狂的事情，我怀疑如果您真的将非常大的结果集直接加载到网页中，那么除了数据库性能之外还有很多问题。
例如，在 LedgerSMB 中，我知道我们会提取一千多行发票来为某些用户生成单个网页（我们使用 PostgreSQL）。对我们来说，PostgreSQL 运行良好，即使聚合了从数百万条记录表中提取的数千条记录。我们在该级别每个页面加载所花费的时间（分析）大约是 15 秒的 db 时间到最多 5 分钟的 Web 应用程序时间来生成网页。（这是可以接受的，因为它确实为此客户全局优化了工作流程，请记住，网页可能有多达 20k 个输入元素，并且数据必须在 db 服务器发送它的位置和网页建立）。这可能与您的用例不匹配，但它可能让您了解数据库不匹配的事实
如果数据库确实是问题所在，以下是故障排除的一些方面和您可以使用的选项。
分析您的整个应用程序。实际花在 db 东西上的时间是多少？处理页面显示花费了多少？
分析您的数据库查询。可以做些什么来提高它们的效率？
在得出结论认为不同的数据库将解决您的问题之前执行此操作。
现在如果事实证明你真的把它推到了最大，那么你需要看看你的选择。这些包括：
PostgreSQL（是的，关系数据库）。这样做的一件事是更普遍优化的表/索引结构（InnoDB 专门研究 pkey 查找，这意味着其他搜索速度较慢）。
VoltDB（另一个关系数据库，但这是高速 oltp 的主内存，速度非常快）
您可以使用与您的 rdbms 一起工作的 NoSQL 数据库构建一个缓存层。这是您可以使用 MongoDB 或 CouchDB 的地方。