The Future of MySQL by Monty Widenius and Jay Pipes.
- Why this talk
- MySQL and Sun should become more transparent
- Easier to discuss and act when you have facts
- when user know the limitations, they know how to go around
- Threads
- one connection/thread doesn’t work well
- no priority threads
- no way to ensure we have X threads
- Symptoms
- Too many context switches
- we are not using multi-core efficiently
- does not scale that well after 4-8 cores
- Solution
- –thread-handling=pool-of-threads (6.0)
- Lots of work
- Memory as a resource
- no single memory allocator
- sort_buffer_size is not flexible
- memory engine has limitations (no varchar/blob)
- Metadata
- no online operations
- .frm files are used to generate table info
- no versioning
- they are not ACID
- slow information schema / SHOW command
- Privileges
- not modular or pluggable
- hard to extend
- Get community to add LDAP support and ask MySQL/Sun to add ROLE as high priority
- Pluggable storage engine
- storage engines are depending on internal mysql data structures (table, field)
- can only be used with the exact MySQL server version that is compiled
- think as loadable engine
- Items
- hold temporary values during evaluation
- are not re-entrant
- hard to make parallel execution of statement
- we cant cache prepared statements and stored procedures
- Parser
- state machine too large
- not pluggable
- not cacheable
- still uses Bison
- bad error messages
- Modularity
- very monolithic
- few defined interfaces
- server and libraries are not documented
- multiple execution paths
- no rewrite state for optimizer
- Stored procedures/triggers
- not cacheable across connections
- only supports SQL
- pre-locking for all tables
- all cursors are materialized
- trigger code is not shared across opened tables
- uses more memory
- hard to debug and profile
- Replication
- not fail safe
- no synchronous option
- no consistency checking
- setup and resync is complicated
- single thread on the slave
- no multi master
- only InnoDB synchronizes with the replication binary log
- Client/Server protocol
- only one running query/connection
- not all statements can be prepared
- not all language support prepared statement protocol
- multi-statements/sps with multiple results (need to add the support)
- Table names
- stored as files (.frm)
- file system can be a case sensitive or not
- falcon has its own interpretation of how things should be done
- Why Falcon and Maria
- we don’t have any transactional engine
- if one fails, another will succeed
- Phone home
- no clue for mysql/sun what features mysql users are using
- endless internals discussion
- what can be deprecated
- default values for future
- Open source project ?
- very hard to contribute code or ideas
- customers are using their production systems as bug-finders
- road map and decision making is not transparent
- Release policy
- constantly shipping releases
- 5.1 was declared RC way too early
- features are removed/added in RC code (hmm?, what’s wrong)
- Good news
- we know the problems and have a good clue of how to fix (most) of them
- sun is more open source / free software friendly than MySQL
- sun really understands developer