有没有人能推荐一个写起来又快又高效的DBMS？

Question

我有一个项目，这将是写重，而不是读重。我想知道是否有人有任何关于开源DBMS设置的建议，这些建议可以快速编写？

它也不一定是关系型DBMS；我愿意接受建议。

Answer 1

我在下面引用NoSQL: If Only It Was That Easy结论的一些部分(这篇文章更多的是关于可伸缩性的，但仍然包含适用于您的上下文的有趣的东西)：

...

真正需要指出的是，如果你因为不能选择数据库而无法做出一些超级棒的东西，那么你就做错了。如果你知道mysql，那就使用它。在你真正需要的时候进行优化。像使用k/v商店一样使用它，像使用rdbms一样使用它，但是看在上帝的份上，构建你的杀手级应用吧！对于大多数应用程序来说，这些都无关紧要。仍然大量使用MySQL。维基百科经常使用MySQL。FriendFeed经常使用MySQL。NoSQL是一个很棒的工具，但它肯定不会成为你的竞争优势，它不会让你的应用变得火爆，最重要的是，你的用户不会关心这些狗屎。

我将在什么基础上构建我的下一个应用程序？可能是Postgres。我会使用NoSQL吗？也许吧。我也可以使用Hadoop和Hive。我可能会把所有东西都放在平面文件里。也许我会开始黑进磁悬浮列车。我会用最适合这项工作的东西。如果我需要报告，我不会使用任何NoSQL。如果我需要缓存，我可能会使用东京暴君。如果我需要ACIDity，我不会使用NoSQL。如果我需要一大堆计数器，我会使用Redis。如果我需要事务，我会使用Postgres。如果我有一大堆单一类型的文档，我可能会使用Mongo。如果我每天需要写10亿个对象，我可能会使用Voldemort.solr。如果我需要全文搜索，我可能会使用。如果我需要对易失性数据进行全文搜索，我可能会使用Sphinx。

..。

因此，如果可以选择非ACID存储系统，我会考虑Voldemort。如果不是，如果没有更具体的信息，我不能说对于写密集型应用程序来说，一种DBMS是否真的比另一种更好。实际上，我认为这更多的是设计/架构/调优的问题，并倾向于同意作者的观点: 1)使用你最熟悉的应用程序2)你选择哪个应用程序对大多数应用程序都不重要。

Answer 2

嗯，我已经看到商业数据库在不是特别令人印象深刻的硬件上每分钟增加2 2GB。标准的开源数据库(MySQL，Postgress甚至sqlite也紧随其后)。

对于任何会给现代数据库带来麻烦的写操作，有三件事会影响性能(这两件事都不取决于您选择的特定数据库)。

一个是基本设计，特别是分区(将数据库分散在几个物理磁盘上)和最小化表上的索引数量(对于写性能来说，零索引是最好的！)。

二是日志放置，或者如果可能的话，日志避免。日志记录是大多数RDBMes中的瓶颈。确保将日志记录到专用的快速磁盘是一种方法，如果您能够承受丢失事务的代价，则可以关闭表的日志记录(根据RDBMS的不同而不同，但大多数都支持这一点)。

三是硬件--大量内存和大量快速磁盘来分散您的I/O负载。

如果这仍然不够快，还有一些奇特的选择。购买一台z/OS大型机，并运行具有DEDB (数据输入数据库)特性的古老的IMS/DB。这大约比任何其他ACID DB快四倍。购买甲骨文的内存DB选项(以前是惠普TimesTen)。

如果你有一些像样的queing软件，另一种可能是捕获数据并立即将其放入队列中。然后，您可以让一个或多个后台进程将数据从队列中拉出，并在后台执行实际的数据库更新。

Answer 3

数据库系统可以根据它们运行的环境进行优化，但最重要的是硬件，特别是I/O。尽可能多地使用磁盘，并设置RAID 10或RAID 0+1，您不想在每次DBMS向磁盘写入某些内容时计算奇偶校验。