我正在从事一个涉及大量数据库写入的项目(70%的插入和30%的读取)。这个比率还包括我认为是一个读一个写的更新。读取可能是脏的(例如,在读取时我不需要100%准确的信息)。 该任务每小时将处理超过100万个数据库事务。

我在网上读了一堆关于MyISAM和InnoDB之间区别的东西,对于我将用于这个任务的特定数据库/表来说,MyISAM似乎是显而易见的选择。从我看来,InnoDB在需要事务时是很好的,因为它支持行级锁。

有人有这种负载(或更高)的经验吗?MyISAM是正确的选择吗?


当前回答

还可以看看MySQL本身的一些替代品:

玛丽亚数据库

http://mariadb.org/

MariaDB是一个数据库服务器,为MySQL提供了直接替换功能。MariaDB是由MySQL的一些原始作者在更广泛的免费和开源软件开发人员社区的帮助下构建的。除了MySQL的核心功能之外,MariaDB还提供了一组丰富的功能增强,包括备用存储引擎、服务器优化和补丁。

Percona服务器

https://launchpad.net/percona-server

一个增强型的MySQL替代品,具有更好的性能、改进的诊断和新特性。

其他回答

对于这样的读写比率,我猜InnoDB会表现得更好。 既然您可以接受脏读,那么您可以(如果您负担得起)复制到一个从服务器,并让您的所有读都到从服务器。另外,考虑批量插入,而不是一次插入一条记录。

这个问题和大部分答案都已经过时了。

是的,MyISAM比InnoDB快是无稽之谈。注意问题的日期:2008年;现在已经过去了近十年。从那时起,InnoDB在性能上取得了显著的进步。

戏剧性的图表是MyISAM获胜的一种情况:没有where子句的COUNT(*)。但这真的是你花时间做的事情吗?

如果你运行并发测试,InnoDB很可能会赢,即使是对MEMORY。

如果在对select进行基准测试时执行任何写入操作,MyISAM和MEMORY可能会因为表级锁定而丢失。

事实上,Oracle非常确定InnoDB更好,以至于他们几乎从8.0中删除了MyISAM。

这个问题写于5.1的早期。从那时起,这些主要版本被标记为“一般可用性”:

2010: 5.5(。12月8日) 2013: 5.6(。2月10日) 2015年:5.7(。10月9日) 2018年:8.0(。四月十一日)

底线:不要使用MyISAM

如果使用MyISAM,则每小时不会执行任何事务,除非将每个DML语句视为一个事务(在任何情况下,在崩溃时都不是持久的或原子的)。

因此我认为你必须使用InnoDB。

每秒300个交易听起来很多。如果您绝对需要这些事务在电源故障时保持持久,请确保您的I/O子系统能够轻松地处理每秒这么多的写操作。您至少需要一个带有电池缓存的RAID控制器。

如果你可以降低一点持久性,你可以使用InnoDB,将innodb_flush_log_at_trx_commit设置为0或2(参见文档),你可以提高性能。

有许多补丁可以从谷歌和其他补丁中提高并发性——如果没有它们仍然不能获得足够的性能,这些补丁可能会引起您的兴趣。

myisam对于这种类型的工作负载(高并发写入)是一个NOGO,我对innodb没有那么多的经验(测试了3次,发现每次性能都很糟糕,但自从上次测试以来已经有一段时间了) 如果你没有被强迫运行mysql,可以考虑尝试postgres,因为它处理并发写要更好

我不是数据库专家,也不是凭经验说的。然而:

MyISAM表使用表级锁定。根据您的流量估计,您每秒有接近200个写入操作。有了MyISAM,在任何时候只有其中一项可以进行。您必须确保您的硬件能够跟上这些事务,以避免超时,即单个查询的时间不能超过5毫秒。

这就意味着你需要一个支持行级锁的存储引擎,比如InnoDB。

另一方面,编写几个简单的脚本来模拟每个存储引擎的负载,然后比较结果应该是相当简单的。