0% found this document useful (0 votes)
29 views

Measuring Mysql Server Performance For Sensor Data Stream Processing

This document describes benchmarks performed to measure the performance of MySQL server for processing streaming sensor data from the Reagan Test Site. The benchmarks included an Insertion Measurement Benchmark (IMB) to test inserting up to 10 MB/s of data with various record lengths into single and multiple tables. A variety of hardware and software configurations were tested. The results analyzed how performance varied based on these factors, such as comparing local vs remote servers, different MySQL versions, and storage engines. The goals were to determine if MySQL could meet current and future throughput requirements and how scalable and dependent on hardware/software it was.

Uploaded by

vusumumuzi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

Measuring Mysql Server Performance For Sensor Data Stream Processing

This document describes benchmarks performed to measure the performance of MySQL server for processing streaming sensor data from the Reagan Test Site. The benchmarks included an Insertion Measurement Benchmark (IMB) to test inserting up to 10 MB/s of data with various record lengths into single and multiple tables. A variety of hardware and software configurations were tested. The results analyzed how performance varied based on these factors, such as comparing local vs remote servers, different MySQL versions, and storage engines. The goals were to determine if MySQL could meet current and future throughput requirements and how scalable and dependent on hardware/software it was.

Uploaded by

vusumumuzi
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 27

Measuring MySQL Server

Performance for Sensor Data


Stream Processing
Jacob Nikom

MIT Lincoln Laboratory

The MySQL Users Conference 2006

27 April 2006
MIT Lincoln Laboratory
MySQL Users Conf.-1 This
work was sponsored by the U.S. Army Space and Missile Defense Command under Air Force Contract# FA8721-05-C-0002.
04-27-2006
Opinions, interpretations, recommendations and conclusions are that of the author and are not necessarily endorsed by the
United States Government.
Outline

• Introduction

• Benchmark for real-time streamed data recording

• Benchmark for real-time streamed events processing

• Summary

MySQL Users Conf-2


MIT Lincoln Laboratory
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
MySQL Users Conf-3
MIT Lincoln Laboratory
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

MySQL Users Conf-4


MIT Lincoln Laboratory
04-27-2006
RTS Operations Coordination Center
(ROCC)
ROCC controls RTS instrumentation

ROCC
Data Analysis Activity
Algorithms Displays Simulation
Database

Network

Sensors

Primary operations:
– 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

MySQL Users Conf-5


MIT Lincoln Laboratory
04-27-2006
ROCC Architecture and
Real-Time Data Flow
Sensors
ROCC Publish-subscribe middleware

ROCC
Interface
Historian Alg_1
Box_1

MySQL
server

ROCC
Operational
Interface Alg_M
Box_N Data Store
(ODS)

MySQL Users Conf-6


MIT Lincoln Laboratory
04-27-2006
ROCC Backend Design
Network/middleware

Messages Queries

Queries

Historian MySQL
subscription threads server ODS

Questions for benchmark to answer (then)


• 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?
MySQL Users Conf-7
MIT Lincoln Laboratory
04-27-2006
Outline
• Introduction
• Benchmark for real-time streamed data recording
– Insertion measurement benchmark (IMB)
– Testing system configurations
– Analysis of IMB results
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
MySQL Users Conf-8
MIT Lincoln Laboratory
04-27-2006
Insertion measurement benchmark

(IMB)
Goals
– Store up to 10 MB/s with various record lengths
– Simulate the asynchronous message generation in the acquisition system

Multiple clients –— one table (M1) Multiple clients –— multiple tables (MM)

Server Table
Client Client
Client

1 … 100 1 … 100

Client Client
Client

Design parameters

– 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
MySQL Users Conf-9
MIT Lincoln Laboratory
04-27-2006
Testing system configurations
Hardware tested
Quantity CPU Memory Disks Network
2 Quad CPU Opteron, 64-bit, 8 GB RAID 5 SCSI Ultra 320, 300 GB 1 Gb/sec
1 MB Cache 144 GB, 10 K rpm, 4.7 ms
4 Dual CPU Opteron, 64-bit, 4 - 8 GB RAID5, SATA, 250 GB, 80 GB, 7.2 K rpm, 1 Gb/sec
10.9 ms, UltraATA-100, 7.2 K rpm, 11.5 ms
1 MB Cache

2 Single and dual CPU Intel(R) 2 - 3 GB Ultra SCSI 320, 146 GB, 15K rpm, 3.5 ms 1 Gb/sec
Xeon(TM) CPU, 2.0 GHz,
SCSI Ultra 160, 73 GB, 10K rpm, 7.8 ms
2 MB Cache

Software tested
# 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

MySQL Users Conf-10


MIT Lincoln Laboratory
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
MySQL Users Conf-11
MIT Lincoln Laboratory
04-27-2006
Comparing One and Multiple
Tables Performance (MyISAM)
4-CPU Opteron –— local client and server (the same machine)

MySQL Users Conf-12


MIT Lincoln Laboratory
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

MySQL Users Conf-13


MIT Lincoln Laboratory
04-27-2006
Comparing MySQL 4.1 and 5.0
Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server

MySQL Users Conf-14


MIT Lincoln Laboratory
04-27-2006
Comparing MySQL 4.0 and 4.1
Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server

MySQL Users Conf-15


MIT Lincoln Laboratory
04-27-2006
Comparing MySQL 4.0, 4.1, and 5.0
Servers Performance (MyISAM)
1-CPU Intel Xeon—local client and server

MySQL Users Conf-16


MIT Lincoln Laboratory
04-27-2006
Comparing InnoDB vs MyISAM and
JDK 1.4.2 32-bit vs JDK 1.5.0 64-bit
2-CPU Opteron client; 4-CPU Opteron server; MySQL 4.0.18

MySQL Users Conf-17


MIT Lincoln Laboratory
04-27-2006
Outline

• 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
MySQL Users Conf-18
MIT Lincoln Laboratory
04-27-2006
Client/Server (CS)–based
ROCC architecture
Sensors
ROCC ROCC
Interface Alg_1
Box_1

MySQL server

ROCC
Alg_M
Interface
Box_N
ODS

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
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

MySQL Users Conf-19


MIT Lincoln Laboratory
04-27-2006
Using Indexes for Storing and
Retrieving Real-Time Data
Traditional (interactive and batch) approach
1. Store data into the relational table
2. Add indexes to the table once the data accumulation is finished
3. Retrieve the data using added indexes
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

Real-time (continuous) approach


1. Store data into the relational table using primary key with AUTO_INCREMENT option
2. Retrieve the latest data using primary key, ORDER and LIMIT query parameters
3. 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
• 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
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
MySQL Users Conf-20
MIT Lincoln Laboratory
04-27-2006
Records Retrieval Acceleration
Using Inner Query and Indexes
Table for record insertion and retrieval
Primary autoincrement
key (indexed) recordID Column1
column1 ……….

Last record in the table N 301


Last record in the
second query window N-1 299
Found record second query
N-2 303
window

……. ……. …….


window width = M<<N
N-M 400
First record in the
second query window N-M-1 …….

……. …….

First record in the 1 …….


table

SELECT * FROM ( SELECT * FROM table1 ORDER BY recordID DESC LIMIT M ) t WHERE t.column1< 300

MySQL Users Conf-21


MIT Lincoln Laboratory
04-27-2006
Event Measurement Benchmark (EMB)
Goals and Design
• Goals
– 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

• Design
– 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

MySQL Users Conf-22


MIT Lincoln Laboratory
04-27-2006
EMB Goals and Design
Computer 0 Computer 1 Computer 2
Reading Client_6 Reading Client_6
Reading Client_5 Reading Client_5
Reading Client_4 Reading Client_4
WritingClient_3 Reading Client_3 Reading Client_3
WritingClient_2 Reading Client_2 Reading Client_2
WritingClient_1 Reading Client_1 Reading Client_1

MySQL
server

MySQL database

Writing tables 0
Result tables 1 Result tables 2

MySQL Users Conf-23


MIT Lincoln Laboratory
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

Throughput = 2 MB/sec, 90% latencies within 100 Throughput = 3 MB/sec, 90% latencies within 40 msec
msec

Throughput = 4 MB/sec, 90% latencies within 100 msec Latencies histograms for writing/reading threads for 4 clients

MySQL Users Conf-24


MIT Lincoln Laboratory
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

MySQL Users Conf-25


MIT Lincoln Laboratory
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

MySQL Users Conf-26


MIT Lincoln Laboratory
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
MySQL Users Conf-27
MIT Lincoln Laboratory
04-27-2006

You might also like