As below, I organized the cluster and conducted DML performance test.
However, SELECT’s performance was lower than other DMLs.
This was not what I expected.
UPDATE, DELETE thought that SELECT would be performed internally and then proceeded.
However, the performance of simple SELECT statements was lower than other DMLs.
I’m attaching some information you can refer to regarding the test.
In addition, the DML performance indicators below show that the average TPS did not improve as the threads increased further.
Sixteen threads showed the average TPS of the highest point.
I expected linear performance.
What engine variable is blocking this problem?
I am sending you two reports.
One is the report collected during the test in the ‘SELECT statement’.
MemSQL Cluster info
Version : 7.0.14
4Servers( 1ma, 6leaves with HA )
- CREATE TABLE TEST_01 (
C2 VARCHAR(100) ,
C3 VARCHAR(100) ,
C4 VARCHAR(100) ,
C5 VARCHAR(100) ,
C6 VARCHAR(100) ,
C7 VARCHAR(100) ,
C8 VARCHAR(100) ,
C9 VARCHAR(100) ,
C10 VARCHAR(100) ,
C18 VARCHAR(100) ,
UPDATE_DATE DATETIME ,
INSERT INTO TEST_01 VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
SELECT ID, C1, C2, C3, C4, C5, C6, C7, …, C18 FROM TEST_01 WHERE ID = ranVal
UPDATE TEST_01 SET C8=C8+1 UPDATE_DATE = updateDate WHERE ID = ranVal
DELETE FROM TEST_01 WHERE ID = ranVal
30 million initial data (ID: 1-300000)
Based on 20 column 200byte, generate the first column random value (ranVal)
100,000 data per thread
- SELECT_CA : MA, CA, 6leaves with HA
Thanks in advance