我有一个项目，这将是写重而不是重读。我想知道是否有人对开源DBMS设置提出了哪些建议很快？
它也不一定是关系型DBMS;我愿意接受建议。
答案 0 :(得分：7)
我在引用NoSQL: If Only It Was That Easy结论的某些部分（文章更多关于可伸缩性但仍包含适用于您的上下文的有趣内容）：
[...]
真实要指出的是，如果 你被制止了 超级棒的东西，因为你 你无法选择数据库 错了。 如果您了解mysql，请使用 它。在您真正需要时进行优化 至。像k / v商店一样使用它，使用它 像一个rdbms，但为了上帝的缘故，建立 你的杀手级应用！这些都不会 对大多数应用程序都很重要。 Facebook依旧 使用MySQL，很多。维基百科使用 MySQL，很多。 FriendFeed使用MySQL，a 许多。 NoSQL是一个很棒的工具，但它确实如此 肯定不会是你的 竞争优势，它不会 让你的应用程序变得热门，最重要的是， 您的用户不会对任何内容大肆宣传 这个。
我要构建我的下一个应用程序 上？可能是Postgres。我会用吗 NoSQL的？也许。我也可以使用Hadoop 和蜂巢。我可能会保留所有内容 平面文件。也许我会开始黑客攻击 在磁悬浮。我会用最好的东西 为了工作。如果我需要报告，我 不会使用任何NoSQL。如果我需要 缓存，我可能会使用东京 暴君。如果我需要ACIDity，我将不会使用 NoSQL的。如果我需要大量的柜台， 我会用Redis。如果我需要 交易，我会用Postgres。如果我 有一吨单一的 文件，我可能会用Mongo。的 如果 我需要写10亿个对象a 那天，我可能会使用Voldemort。 如果我 需要全文搜索，我可能 使用Solr。如果我需要全文搜索 我可能会使用易失性数据 斯芬克斯。
[...]
因此，如果选择非ACID存储系统，我会查看Voldemort。如果没有，没有更具体的信息，我不能说一个DBMS对于写密集型应用程序是否真的比另一个更好。实际上，我认为这更多的是设计/架构/调优，并倾向于与作者达成一致：1）使用你最了解的那个2）你选择哪一个对大多数应用都无关紧要。
答案 1 :(得分：3)
好吧，我看到商业数据库每分钟上升2GB，不是特别令人印象深刻的硬件。标准的开源dbs（MySQL，Postgress甚至sqlite都不甘落后）。
对于任何会给现代数据库带来麻烦的写入量，有三件事会影响性能（两者都不取决于您选择的特定数据库）。
一个是基本设计，特别是分区（将数据库扩展到多个物理磁盘上）并最小化表上的索引数（对于写性能零索引最好！）。
两个是日志放置或可能的日志避免。日志记录是大多数RDBM的瓶颈。确保您正在登录到专用快速磁盘是一种方法，如果您在表中转换日志（根据RDBMS而不是大多数支持） 可以承受失去交易。
三是硬件 - 大量内存和大量快速磁盘来分散您的I / O负载。
如果仍然不够快，那里有一些奇特的选择。 购买z / OS主机并使用DEDB（数据输入数据库）功能运行古老的IMS / DB。这比任何其他ACID DB快大约四倍。购买Oracle的In Memory DB选项（以前是HP TimesTen）。
如果你有一些像样的排队软件可用的另一种可能性是捕获数据并立即将其放入队列中。然后，您可以让一个或多个后台进程从队列中提取数据并在后台执行实际的数据库更新。
答案 2 :(得分：2)
数据库系统可以根据它们运行的环境进行优化，但最重要的是硬件，特别是I / O.尽可能多地使用磁盘并设置RAID 10或RAID 0 + 1，每次DBMS将某些内容写入磁盘时，您不希望计算奇偶校验。
答案 3 :(得分：1)
答案 4 :(得分：0)
定义“写重”：每天数十亿行，或与阅读活动相比写密集？
由于索引，重复检查，UPDATE..WHERE等，即使是“写密集型”数据库也会出现大约15％的写入率。
除非你真的是一个边缘案例（在上面的NoSQL答案中提到），任何DBMS都会这样做，因为限制将是硬件而不是供应商。
答案 5 :(得分：0)
这是一个神秘的问题 - 如果你正在做大量的写作和很少的查找（读取）和（某些）更新... ...
使用固定记录随机访问文件（Seek（）和posix平台上的东西），一个平面文件。如果需要建立索引，只需将密钥索引到平面文件即可进行读取和更新。
缺点是您需要保持密钥同步。与写入和更新的内容。一个非常简单的C ++或其他OO类可以为你处理这个问题。如果您不打算使用它们，为什么要编写索引？并且，根据您的实际需要，您可以一起取消索引 - 并在一天结束时索引或某事-K !!
干杯，w。