mysql - 放弃写入 InnoDB

Question

我们每天都在构建从推文用户 ID 到该用户发布的推文的推文 ID 列表的映射。我们使用的存储引擎是 Percona xtraDB "5.1.63-rel13.4 Percona Server (GPL), 13.4, Revision 443"

我们对每秒插入行的最大吞吐量不满意。我们使用 xtraDB 处理推文的最大吞吐量约为每秒 6000 ~ 8000 条推文。 (例如，如果我们从头开始重建某天的数据，我们将不得不等待将近一天)

在大多数情况下，我们能够使用全部 Twitter 数据(大约每秒 4000 ~ 5000 条推文)足够实时地完成此操作。

我们已经将应用程序的瓶颈缩小到 MySQL InnoDB 插入。在我们的应用程序中，我们从磁盘读取提要并使用 jackson 对其进行解析(每秒大约发生 30,000 条推文)。然后，我们的应用程序会分批处理推文。对于生成这些推文的一组作者，我们将他们分成 8 组(使用用户 ID 模 8 进行简单分区)。为每个组分配一张表，并分配 1 个线程将数据写入该表。每天大约有 2600 万唯一用户生成这些推文，因此每个表大约有 400 万行。对于一组用户，我们只使用一个事务进行读取和更新。组大小是运行时可调的。我们尝试了 8 ~ 64000 的各种大小，我们确定 256 是一个很好的批量大小。

我们表的架构是

CREATE TABLE `2012_07_12_g0` (  `userid` bigint(20) NOT NULL,  `tweetId` longblob,  PRIMARY KEY (`userid`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

其中 tweetId 是推文 ID 长整数的压缩列表，使用 Google snappy 压缩

每个线程使用

Select userid,tweetId from <tablename> where userid IN (....)

解析userids回读数据，线程使用

INSERT INTO <tablename> (userid,tweetId) VALUES (...) ON DUPLICATE KEY UPDATE tweetId=VALUES(tweetId)

用新的 tweetid 更新行。

我们已尝试设置各种 XtraDB 参数

innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit = 2
innodb_max_dirty_pages_pct = 80
innodb_flush_method = O_DIRECT
innodb_doublewrite = 0
innodb_use_purge_thread = 1
innodb_thread_concurrency = 32
innodb_write_io_threads = 8
innodb_read_io_threads = 8 
#innodb_io_capacity = 20000 
#innodb_adaptive_flushing = 1
#innodb_flush_neighbor_pages= 0"

每天的表大小约为所有表的 8G，InnoDB 有 24GB 可供使用。

我们正在使用:

• 6 盘(crucial m4 SSD，512 GB，000F 固件)软件 RAID5。
• mysql innodb数据，SSD分区上的表空间
• 使用 noatime,nodiratime,commit=60 挂载 ext4
• centos 6.2
• 太阳jdk 1.6.30

如果有任何能让我们的插入速度更快的提示，我们将不胜感激，谢谢。

Answer 1

InnoDB is given 24GB

你是说这是 innodb_buffer_pool_size 吗？你没有说你有多少内存，也没有说你正在使用什么 CPU。如果是这样，那么您可能应该使用更大的 innodb_log_buffer_size。 innodb_log_file_size 的设置是什么？它应该在 96Mb 左右。

innodb_write_io_threads = 8

ISTR 认为 ext3 与多个编写器存在一些并发问题 - 但我不知道 ext4

您是否尝试过更改 innodb_flush_method？

您使用哪个 I/O 调度程序(在没有智能磁盘 Controller 的情况下，通常 deadline 最快，有时是 CFQ)？

关闭 ext4 屏障将有助于提高吞吐量——这有点冒险——确保你在 JBD2 中启用了校验和。类似地设置 innodb_flush_log_at_trx_commit=0 应该会显着增加但风险更大。

既然您显然不介意以关系格式维护数据，那么您可以考虑使用 noSQL 数据库。