本文介紹了MySQL處理海量數據的處理方法,對大家解決問題具有一定的參考價值,需要的朋友們下面隨著小編來一起學習吧!
問題描述
目前,我的應用程序每小時大約生成4000萬條記錄,我已經為每小時創建了一個分區,這樣我就可以更容易地在需要時刪除該分區,還可以使用該分區來聚合數據。
如果沒有發生任何查詢,我的聚合過程將運行得很好,但一旦啟動這些查詢,聚合代碼就需要一個多小時才能完成。
在MySQL中,是否有基于對數據庫發生的查詢而凍結且不影響的進程?
回復@Rick
內存:32 GB
Innodb_Buffer_Pool_Size:20 GB
固態硬盤:是
讀取類型:它是
GROUP BY和UPDATE混合覆蓋主鍵
我不想每隔5分鐘進行一次聚合,因為這也會生成大量記錄,應用程序無法實現,我實際上每小時保存5個分區并運行最舊的分區,我的應用程序至少需要5小時的非聚合數據。
對于我的應用程序,不需要ACID類型的特征,因此將默認隔離更改為Read-Unmitted,并將自動提交更改為0,這提高了聚合代碼的運行速度,但插入受到了影響,這需要2秒以上的時間。
此處更新聚合查詢的配置文件信息
+----------+-----+---------------------------+-----------+------------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| QUERY_ID | SEQ | STATE | DURATION | CPU_USER | CPU_SYSTEM | CONTEXT_VOLUNTARY | CONTEXT_INVOLUNTARY | BLOCK_OPS_IN | BLOCK_OPS_OUT | MESSAGES_SENT | MESSAGES_RECEIVED | PAGE_FAULTS_MAJOR | PAGE_FAULTS_MINOR | SWAPS | SOURCE_FUNCTION | SOURCE_FILE | SOURCE_LINE |
+----------+-----+---------------------------+-----------+------------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| 50754 | 2 | continuing inside routine | 0.000015 | 0.000197 | 0.000036 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NULL | NULL | NULL |
| 50754 | 3 | checking permissions | 0.000007 | 0.000005 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | check_access | sql_authorization.cc | 809 |
| 50754 | 4 | checking permissions | 0.000006 | 0.000006 | 0.000000 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | check_access | sql_authorization.cc | 809 |
| 50754 | 5 | Opening tables | 0.000017 | 0.000013 | 0.000003 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | open_tables | sql_base.cc | 5815 |
| 50754 | 6 | init | 0.000260 | 0.000400 | 0.000073 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc | 128 |
| 50754 | 7 | System lock | 0.000011 | 0.000009 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_lock_tables | lock.cc | 330 |
| 50754 | 8 | optimizing | 0.000115 | 0.000098 | 0.000017 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc | 158 |
| 50754 | 9 | statistics | 0.001624 | 0.003051 | 0.000552 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc | 374 |
| 50754 | 10 | preparing | 0.000158 | 0.000134 | 0.000024 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc | 482 |
| 50754 | 11 | Sorting result | 0.000009 | 0.000007 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | make_tmp_tables_info | sql_select.cc | 3849 |
| 50754 | 12 | executing | 0.000006 | 0.000005 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | exec | sql_executor.cc | 126 |
| 50754 | 13 | Sending data | 40.298694 | 144.161765 | 12.297466 | 596361 | 261826 | 265128 | 2899384 | 0 | 0 | 0 | 328 | 0 | exec | sql_executor.cc | 202 |
| 50754 | 14 | end | 0.000031 | 0.000024 | 0.000005 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc | 206 |
| 50754 | 15 | query end | 0.000016 | 0.000013 | 0.000003 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 4959 |
| 50754 | 16 | closing tables | 0.000055 | 0.000048 | 0.000007 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 5018 |
| 50754 | 17 | query end | 0.000007 | 0.000005 | 0.000002 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 4959 |
| 50754 | 18 | closing tables | 0.000012 | 0.000009 | 0.000002 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 5018 |
+----------+-----+---------------------------+-----------+------------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
聚合代碼如下所示,每次占用約100個客戶端密鑰,每小時可用客戶端密鑰約為100K
insert into DB.NETWORK_USAGE_FINAL(clientKey,k1,k2,k3,k4,k5,createdAt)
select clientKey, sum(k1) as k1, sum(k2) as k2, sum(k3) as k3 ,
k4, k5 , "',startTime,'" from DB.NETWORK_USAGE_F1 partition (',partitionKey,')
where clientKey in (',selectedClientKey,')
group by clientKey,k4,k5
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
innodb_buffer_pool_size=20G
innodb_buffer_pool_instances=20
max_connections=100
query_cache_size=0
query_cache_type=0
query_cache_limit=2M
innodb_log_file_size=3G
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_io_capacity = 2000
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
back_log = 1000
tmp_table_size = 1G
max_heap_table_size = 1G
join_buffer_size=1G
sort_buffer_size=512M
innodb_lru_scan_depth=100
table_open_cache=4000
max_allowed_packet=1G
innodb_file_per_table=1
character-set-server = utf8
collation-server = utf8_unicode_ci
event_scheduler = ON
transaction_isolation = READ-COMMITTED
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer_size = 1G
thread_stack = 128M
thread_cache_size = 8
myisam-recover-options = BACKUP
log_error = /var/log/mysql/error.log
expire_logs_days = 10
max_binlog_size = 100M
顯示CREATE TABLE
CREATE TABLE `NETWORK_USAGE_F1` (
`id` char(15) NOT NULL,
`clientKey` int(11) NOT NULL,
`k4` int(11) NOT NULL,
`k5` char(50) NOT NULL,
`createdAt` datetime NOT NULL,
`partitionKey` int(11) NOT NULL,
`k1` bigint(20) NOT NULL,
`k2` bigint(20) NOT NULL,
`k3` int(11) NOT NULL,
PRIMARY KEY (`id`,`partitionKey`),
KEY `key2` (`clientKey`,`k4`,`k5`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
/*!50100 PARTITION BY RANGE (partitionKey)
*/
@回復里克更新:
聚合代碼一次在100個客戶端鍵(限制)上運行,一個小時內將存在大約100K個唯一的客戶端鍵,但數據庫中一個小時/分區的總行數約為4000萬行(因此,每個客戶端鍵大約有400行)
使用的ID僅為15個字符長度
目前我有5個分區,分區鍵格式為YYYYMMMDDHH
不使用MyISAM
推薦答案
讓我們看看聚合代碼。和SHOW CREATE TABLE
。
可嘗試的其他內容:
改為每5分鐘匯總一次。
不斷地聚合";。也就是說,執行自上次執行聚合以來的所有行。
將行收集到”臨時”表中。然后進行聚合,最后將行復制到主表中。以下是有關乒乓球技術的討論:http://mysql.rjweb.org/doc.php/staging_table
每秒11K行是很多,但也不是不可能。
其他問題:
您有多少內存?
innodb_buffer_pool_size
的設置是什么?
您有固態硬盤嗎?
同時進行哪些類型的讀取?(從大桌子上看書?是否正在讀取匯總表?)
(re my.cnf)
我建議您將這些限制為內存的1%(除非您有確定的較大原因):
tmp_table_size = 1G
max_heap_table_size = 1G
join_buffer_size=1G
sort_buffer_size=512M
max_allowed_packet=1G
key_buffer_size = 1G -- for MyISAM only
我希望您沒有使用MyISAM。如果不是將其降低到50M。
thread_stack = 128M
糟糕!保留默認設置!
(架構)
使用VARCHAR
,而不是CHAR
,除非字符串確實是固定長度的。
由于您的桌子將很大,請使用實際最小的INT
大小。
有多少個PARTITIONs
?哪個版本的MySQL?(分區太多本身可能會拖累性能。)
partitionkey
設置為什么?
(其他)
是拼寫錯誤,還是我被它的內容搞糊涂了?
此外,這似乎與每小時4,000萬條記錄沖突。
這篇關于MySQL處理海量數據的文章就介紹到這了,希望我們推薦的答案對大家有所幫助,