经常写入的建议，很少读取数据库

我有一个应用服务器，它经常写入数据库并在不久的将来读取，但很少读取数据条目。经常写入的建议，很少读取数据库

什么是为这种访问优化的一些好的数据库？我目前正在使用MongoDB，但我认为这可能不是在这种情况下的最佳选择。

我公开关系的DB（即MySQL的），MongoDB的，Redis的等

P.S.似乎很容易回答这个问题，以便经常阅读数据库访问权限，但很难找到有关此特定案例的信息。

来源

2011-10-11 Steven

这是很普通的问题，我们需要知道更多的细节

数据库的大小
数据增长的，多少钱每天/ 200GB 10GB每月？
它是OLTP应用程序还是OLAP应用程序？
什么是最大并发交易数/用户数？

除了它，既然你提到的数据是很少看超过一定点

您可以随时看的档案选项（清理基于时间 - 月额/每年）
Parititioning也是另一种选择，更快的检索

再次为去为SQL或NOSQL选项是基于

一致性
如果你有一个固定的模式，我建议你去关系数据库
并发方面，根据需要，你需要决定SQL或NOSQL（例如 - 网上银行，我建议RDBMS，对于商品评论/评论存储为一个网站，我行的NOSQL因为这不需要任何并发处理）

您需要在功能，数据量，数据使用方面提供您的数据库需要更多的细节和生长方面

希望它有帮助...

来源

2011-10-11 07:08:54 Siva

这是一个基于OLTP的应用程序。数据库的大小现在很小，但可能会迅速增长。没有二进制数据存储 - 只是文本（也没有数字，也许时间戳虽然）。我真的不能预测数据的增长，但我预计必须定期存档数据以保持插入和快速访问年轻数据。可以有许多并发事务，但数据不需要是关系型的。数据并没有相互引用，我不能想到并发访问会如何影响它（因为每个用户几乎只访问他们自己的密钥）。 – Steven

继续（最大文本长度），我希望模式非常灵活，同时我仍然处于繁重的发展阶段，因为它可能需要经常更改，直到我解决问题。 P.S.非常有帮助的回应！ :-D – Steven

我不确定多少灵活的架构。你指的是非结构化数据吗？从你的答复中，SQL和NOSQL都能达到你的目的。根据SQL/NOSQL开发人员的技能/舒适度，您必须接受该调用。 – Siva

既然你提到MySQL，你可能想看看ARCHIVE storage engine。

来源

2011-10-11 07:12:50

经常写入的建议，很少读取数据库

回答

相关问题