Post on 11-Dec-2015
transcript
MySQL Users Conf.-104-27-2006
MIT Lincoln Laboratory
Measuring MySQL Server
Performance for Sensor Data
Stream Processing
Jacob Nikom
MIT Lincoln Laboratory
The MySQL Users Conference 2006
27 April 2006
This work was sponsored by the U.S. Army Space and Missile Defense Command under Air Force Contract# FA8721-05-C-0002.Opinions, interpretations, recommendations and conclusions are that of the author and are not necessarily endorsed by the United States Government.
MIT Lincoln LaboratoryMySQL Users Conf-2
04-27-2006
Outline
• Introduction
• Benchmark for real-time streamed data recording
• Benchmark for real-time streamed events processing
• Summary
MIT Lincoln LaboratoryMySQL Users Conf-3
04-27-2006
Outline
• Introduction
– Reagan Test Site (RTS) and its instrumentation
– RTS Operations Coordination Center (ROCC)
– ROCC architecture and real-time data flow
– ROCC backend design
• Benchmark for real-time streamed data recording
• Benchmark for real-time streamed events processing
• Summary
MIT Lincoln LaboratoryMySQL Users Conf-4
04-27-2006
Reagan Test Site (RTS) and its Instrumentation
– Multiple RF sensors collecting data in several regions of electromagnetic spectrum
– Multiple optical sensors collecting objects’ metric and spectral characteristics
– Telemetry systems capable of tracking multiple targets
– Mobile and fixed ground safety instrumentation
MIT Lincoln LaboratoryMySQL Users Conf-5
04-27-2006
ROCC
RTS Operations Coordination Center (ROCC)
ROCC controls RTS instrumentation
– Manages data flow from multiple sensors– Analyses the acquired data– Displays tracks and predicts the path of space objects– Stores acquired data for later analysis and reporting– Simulates past and future activities
Activity Simulation
Data Analysis Algorithms DatabaseDisplays
Network
Sensors
Primary operations:
MIT Lincoln LaboratoryMySQL Users Conf-6
04-27-2006
ROCC Publish-subscribe middleware
ROCC Architecture andReal-Time Data Flow
Sensors
Alg_1
Alg_M
ROCC
Interface
Box_1
ROCC
Interface
Box_N
Historian
MySQL server
OperationalData Store
(ODS)
MIT Lincoln LaboratoryMySQL Users Conf-7
04-27-2006
ROCC Backend Design
Network/middleware
ODSMySQL server
• How well Historian/MySQL server pair could satisfy current performance requirements for particular hardware platform and operating system?
• How well it could satisfy future requirements (how scalable is the solution)?
• How server performance depends upon specific hardware?
• How server performance depends upon specific software?
Questions for benchmark to answer (then)
Messages
Queries
Queries
Historiansubscription threads
MIT Lincoln LaboratoryMySQL Users Conf-8
04-27-2006
Outline
• Introduction
• Benchmark for real-time streamed data recording
– Insertion measurement benchmark (IMB)
– Testing system configurations
– Analysis of IMB resultsComparing one and multiple tables performance
Comparing local and remote servers performance
Comparing MySQL 4.1 and 5.0 servers performance
Comparing MySQL 4.1 and 4.0 servers performance
Comparing MySQL 4.0, 4.1 and 5.0 servers performance
Comparing InnoDB engine vs. MyISAM engine performance
Comparing JDK 1.5.0 64-bit vs. JDK 1.4.2 32-bit performance
• Benchmark for real-time streamed events processing
• Summary
MIT Lincoln LaboratoryMySQL Users Conf-9
04-27-2006
Insertion measurement benchmark
(IMB)Goals
– Multiple clients writing into the same table (up to 100 clients)
– Multiple clients writing into different tables (up to 100 tables)
– Different record lengths (from 10 bytes up to 10 MB – 1,000,000 times)
– Reading performance was not the major issue
Design parameters
– Store up to 10 MB/s with various record lengths
– Simulate the asynchronous message generation in the acquisition system
Server TableClient
Client
Client
Client
1 … 100
Multiple clients –— one table (M1)
Client
Client
1 … 100
Multiple clients –— multiple tables (MM)
MIT Lincoln LaboratoryMySQL Users Conf-10
04-27-2006
Testing system configurations
Quantity CPU Memory Disks Network
2 Quad CPU Opteron, 64-bit,
1 MB Cache
8 GB RAID 5 SCSI Ultra 320, 300 GB
144 GB, 10 K rpm, 4.7 ms
1 Gb/sec
4 Dual CPU Opteron, 64-bit,
1 MB Cache
4 - 8 GB RAID5, SATA, 250 GB, 80 GB, 7.2 K rpm, 10.9 ms, UltraATA-100, 7.2 K rpm, 11.5 ms
1 Gb/sec
2 Single and dual CPU Intel(R) Xeon(TM) CPU, 2.0 GHz,
2 MB Cache
2 - 3 GB Ultra SCSI 320, 146 GB, 15K rpm, 3.5 ms
SCSI Ultra 160, 73 GB, 10K rpm, 7.8 ms
1 Gb/sec
# Operating System MySQL Server Java Client
1 RHEL 4 AS, kernel 2.6.9-5.ELsmp, 64-bit 4.0.18-standard 32/64-bit build 1.4.2_03, 32-bit
2 RHEL 4 ES, kernel 2.6.9-11.ELsmp 32-bit 4.1.11-standard 32/64-bit build 1.4.2_10, 32-bit
6 SLES 8 kernel 2.4.21, 64-bit 5.0.16-standard 32/64-bit build 1.5.0_01, 64-bit
Software tested
Hardware tested
MIT Lincoln LaboratoryMySQL Users Conf-11
04-27-2006
Outline
• Introduction
• Benchmark for real-time streamed data recording
– Insertion measurement benchmark (IMB)
– Testing system configurations
– Analysis of IMB results (MyISAM tables)Comparing one and multiple tables performance
Comparing local and remote servers performance
Comparing MySQL 4.1 and 5.0 servers performance
Comparing MySQL 4.1 and 4.0 servers performance
Comparing MySQL 4.0, 4.1 and 5.0 servers performance
Comparing InnoDB engine vs. MyISAM engine performance
Comparing JDK 1.5.0 64-bit vs. JDK 1.4.2 32-bit performance
• Benchmark for real-time streamed events processing
• Summary
MIT Lincoln LaboratoryMySQL Users Conf-12
04-27-2006
Comparing One and Multiple Tables Performance (MyISAM)
4-CPU Opteron –— local client and server (the same machine)
MIT Lincoln LaboratoryMySQL Users Conf-13
04-27-2006
Comparing Local and Remote Servers Performance (MyISAM)
2-CPU server; 2-CPU remote client/2-CPU local client and server
2-CPU server; 4-CPU remote client/2-CPU local client and server
MIT Lincoln LaboratoryMySQL Users Conf-14
04-27-2006
Comparing MySQL 4.1 and 5.0 Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server
MIT Lincoln LaboratoryMySQL Users Conf-15
04-27-2006
Comparing MySQL 4.0 and 4.1 Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server
MIT Lincoln LaboratoryMySQL Users Conf-16
04-27-2006
Comparing MySQL 4.0, 4.1, and 5.0 Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server
MIT Lincoln LaboratoryMySQL Users Conf-17
04-27-2006
Comparing InnoDB vs MyISAM and JDK 1.4.2 32-bit vs JDK 1.5.0 64-bit2-CPU Opteron client; 4-CPU Opteron server; MySQL 4.0.18
MIT Lincoln LaboratoryMySQL Users Conf-18
04-27-2006
• Introduction
• Benchmark for real-time streamed data recording
• Benchmark for processing real-time streamed events– Client/Server (CS)–based ROCC architecture
– Using indexes for real-time data storing and retrieving
– Records retrieval acceleration using secondary query and indexes
– Event measurement benchmark (EMB)
– Analysis of EMB Results
– Comparing MySQL 4.1 and 5.0 servers performance (MyISAM)
• Summary
Outline
MIT Lincoln LaboratoryMySQL Users Conf-19
04-27-2006
Client/Server (CS)–based ROCC architecture
CS drawbacks
• Data centralization
• More workload for the network – UDP vs. TCP/IP, no multicast
• More workload for the database server
• Require indexes and multilevel queries—more complex requests
Sensors
CS advantages
• “Don’t need special “recording” component (Historian)
• Pull” model—all components get the data when they want them
• The same API for the current and historical data
• Excellent filtering capabilities (SQL)
• High throughput, very simple settings, no load balancing
• Very standard, very low cost, low demand for resources
ROCC
ROCCInterfaceBox_N
ROCCInterface
Box_1 Alg_1
Alg_MODS
MySQL server
MIT Lincoln LaboratoryMySQL Users Conf-20
04-27-2006
Using Indexes for Storing and Retrieving Real-Time Data Traditional (interactive and batch) approach
1. Store data into the relational table2. Add indexes to the table once the data accumulation is finished3. Retrieve the data using added indexes
Real-time (continuous) approach1. Store data into the relational table using primary key with AUTO_INCREMENT option2. Retrieve the latest data using primary key, ORDER and LIMIT query parameters3. Store the latest retrieved data in the temporary derived table 4. Make the search of the record using all available fields only in the derived table
Advantages• Simplicity• Independence of indexes addition from data creation
Drawbacks• Adding indexes to all data in the table is a slow process• Indexes will be recalculated every time a new record is stored
Advantages
Drawbacks• Primary key has to be numeric to allow AUTO_INCREMENT option• Only one index per table could be used for selecting the derived table
• Very fast! Index creation time is spread over all insertion operations (10% overhead)• LIMIT parameter defines the width of the window (number of records for the second SELECT statement)• Primary key is indexed automatically
MIT Lincoln LaboratoryMySQL Users Conf-21
04-27-2006
Records Retrieval Acceleration Using Inner Query and Indexes
recordID column1 ……….
N 301
N-1 299
N-2 303
……. ……. …….
N-M 400
N-M-1 …….
……. …….
1 …….
recordID column1 ……….
N 301
N-1 299
N-2 303
……. ……. …….
N-M 400
N-M-1 …….
……. …….
1 …….
recordID Column1 ……….
N 301
N-1 299
N-2 303
……. ……. …….
N-M 400
N-M-1 …….
……. …….
1 …….
SELECT * FROM table1 ORDER BY recordID DESC LIMIT M
Table for record insertion and retrieval
SELECT * FROM ( ) t WHERE t.column1< 300
second query window
window width = M<<N
Primary autoincrement key (indexed)
Last record in the table
First record in the table
First record in the second query window
Last record in the second query window
Found record
MIT Lincoln LaboratoryMySQL Users Conf-22
04-27-2006
Event Measurement Benchmark (EMB) Goals and Design
• Goals
– Multiple writing clients write into multiple tables time-stamping each record
– Multiple reading clients read from into different tables while the writing clients continue to write into the tables
– Reading clients compare each record time stamp with current time and calculate the latency
– Reading clients write the results into result tables
• Design
– Measure the latencies between freshly stored and retrieved events
– Demonstrate that more than 2 MB/sec throughput could be achieved
– Demonstrate the sustainable latencies were less that 300 msec
MIT Lincoln LaboratoryMySQL Users Conf-23
04-27-2006
MySQL server
MySQL database
EMB Goals and Design
WritingClient_3WritingClient_2
WritingClient_1
Computer 0
Writing tables 0
Computer 2
Reading Client_6Reading Client_5
Reading Client_4Reading Client_3
Reading Client_2Reading Client_1
Result tables 2
Computer 1Reading Client_6
Reading Client_5Reading Client_4
Reading Client_3Reading Client_2
Reading Client_1
Result tables 1
MIT Lincoln LaboratoryMySQL Users Conf-24
04-27-2006
Analysis of EMB Results
Database server—4 CPU Opteron, writing/reading clients—2 CPU Opterons
MySQL server version 4.1.11–standard, Network 1 Gb/sec, JDK 1.4.2_10
Latencies histograms for writing/reading threads for 4 clientsThroughput = 4 MB/sec, 90% latencies within 100 msec
Throughput = 2 MB/sec, 90% latencies within 100 msec
Throughput = 3 MB/sec, 90% latencies within 40 msec
MIT Lincoln LaboratoryMySQL Users Conf-25
04-27-2006
Comparing MySQL 4.1 and 5.0 Servers Performance (MyISAM)
Database server—2 CPU Xeon, writing and reading clients—two 2CPU Opterons
Network 1 Gb/sec, JDK 1.4.2_10
MySQL 5.0.16 MySQL 4.1.11
MIT Lincoln LaboratoryMySQL Users Conf-26
04-27-2006
Outline
• Introduction
• Benchmark for recording real-time streamed data
• Analysis of Insertion Measurement Benchmark (IMB)
• Benchmark for processing real-time streamed events
• Summary
MIT Lincoln LaboratoryMySQL Users Conf-27
04-27-2006
Summary
• IMB and EMB were designed to model major data flows in ROCC
• IMB demonstrated:
– Java/MySQL client/server architecture satisfies ROCC requirements
– MySQL 4.1.11 was the fastest version for insertion transactions
– MyISAM showed superior performance relative to InnoDB
– JDK 1.5.0 64-bit delivers much better performance than 1.4.2 32-bit
• EMB demonstrated:
– Java/MySQL-based client/server architecture with appropriate queries and indexation could be used for ESP applications
– It delivered better throughput and latencies than currently employed publish/subscribe architecture
– MySQL 5.0.16 exhibited better linearity and performance for large number of writing/reading threads than 4.1.11 version
• Benchmarks showed that MySQL server is capable to handle both real-time data recording and real-time event stream processing