← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to docs/mysql_differences.rst

  • Committer: Lee Bieber
  • Date: 2010-11-07 19:34:48 UTC
  • mfrom: (1910.1.2 build)
  • Revision ID: kalebral@gmail.com-20101107193448-64kdu912qej354sh
Merge Stewart - including adapting and expanding the "differences from mysql" page from the wiki.
Merge Stewart - fix bug 668143: drizzleslap with --commit runs second iteration data load in a transaction

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/mysql_differences.rst
2
2
Notable MySQL Differences
3
3
=========================
4
4
 
5
 
Drizzle was forked from the (now defunct) MySQL 6.0 tree in 2008. Since then there have been a lot of changes. Drizzle is in some ways similar to MySQL, and in other ways, unrecognizable.
6
 
 
7
 
This section of documentation aims to explore some of the notable differences between MySQL and Drizzle, and has been modified from its original state on the Drizzle Wiki.
 
5
Drizzle was forked from the (now defunct) MySQL 6.0 tree. Since then there
 
6
have been a lot of changes. Some areas are similar, others unrecognisable.
 
7
 
 
8
This section aims to explore some of the notable differences between MySQL
 
9
and Drizzle.
 
10
 
 
11
This section was originally adapted from the Drizzle Wiki.
8
12
 
9
13
Usage
10
14
-----
13
17
 * Drizzle is optimized for massively concurrent environments. If we have the
14
18
   choice of improving performance for 1024 simultaneous connections to the
15
19
   detriment of performance with only 64 connections, we will take that choice.
16
 
 * It is designed for modern POSIX systems
 
20
 * Designed for modern POSIX systems
17
21
 * Microsoft Windows is not a supported platform (neither is HP-UX or IRIX).
18
 
 * Drizzle doesn't use timezones. Everything is UTC.
 
22
 * No timezones. Everything is UTC.
19
23
 
20
24
Installation
21
25
------------
22
26
 
23
 
 * No scripts/mysql_install_db or similar. Drizzle aims for a "just works" installation, without administrative overhead.
 
27
 * No scripts/mysql_install_db or similar. A "just works" installation
 
28
   mentality without administrative overhead.
24
29
 * No system database that needs upgrading between versions.
25
30
 * Drizzle can listen on the Drizzle port (4427) and/or MySQL port (3306)
26
31
   and speak the respective protocols.
28
33
Architecture
29
34
------------
30
35
 
31
 
Drizzle is designed around the concept of being a microkernel. There should
 
36
Drizzle is designed around the concept of being a micro-kernel. There should
32
37
be a small core of the server with most functionality being provided through
33
38
small, efficient and hard to misuse plugin interfaces. The goal is a small,
34
 
light weight kernel that is easy to maintain, understand and extend.
 
39
light weight kernel which is easy to maintain, understand and extend.
35
40
 
36
 
Drizzle is written in C++ and makes use of the Standard Template Library (STL)
 
41
Drizzle is written in C++ making use of the Standard Template Library (STL)
37
42
and Boost. Only where performance or correctness proves to be inadequate will
38
 
we consider rolling our own; our preference is to fix the upstream library
 
43
we consider rolling our own, and our preference is to fix the upstream library
39
44
instead.
40
45
 
41
46
Network protocol
44
49
Pluggable network protocols allow Drizzle to speak one (or more) of several
45
50
protocols. Currently we support the MySQL protocol (compatible with existing
46
51
MySQL client libraries) and the Drizzle protocol which is still under
47
 
development.
48
 
 
49
 
The Drizzle protocol embodies several important differences from MySQL:
 
52
development but aims for several important differences:
50
53
 
51
54
 * Client sends first packet instead of server
52
 
 * Built in sharding
53
 
 * Multi statement support (without using a semicolon to separate them)
54
 
 * Room for expansion to include NoSQL type commands inline with SQL.
 
55
 * built in sharding
 
56
 * multi statement support (without using a semicolon to separate them)
 
57
 * room for expansion to include NoSQL type commands inline with SQL.
55
58
 
56
 
There is also a console plugin -- instead of providing access over a network
57
 
socket, this plugin allows access from the current tty.
 
59
There is also a console plugin that instead of providing access over a network
 
60
socket, allows access from the current tty.
58
61
 
59
62
Plugin API
60
63
----------
61
64
 
62
 
The existing plugin APIs that Drizzle inherited from MySQL have been reworked.
 
65
Existing plugin APIs inherited from MySQL have been reworked.
63
66
 
64
 
 * User Defined Functions (UDFs) now follow the same API as a given
 
67
 * User Defined Functions (UDFs) now follow the same API as within the
65
68
   server instead of a different C API. This means that UDFs are on the
66
 
   exact same level as built-in functions.
 
69
   exact same level as builtin functions.
67
70
 * Storage Engine API has had some parts extensively reworked, especially
68
71
   around transactions and DDL.
69
72
 * Logging is now pluggable
79
82
Stored Procedures
80
83
-----------------
81
84
 
82
 
Drizzle does not currently have any plugins that implement stored procedures. We
 
85
Drizzle does not currently have any plugins implement stored procedures. We
83
86
viewed the implementation in MySQL to be non-optimal, bloating the parser
84
 
and only supporting one language (SQL2003 stored procedures), which was not
 
87
and only supporting one language (SQL2003 stored procedures) which was not
85
88
well known.
86
89
 
87
90
Fundamentally, stored procedures usually are not the correct architectural
88
91
decision for applications that need to scale. Pushing more computation down
89
92
into the database (which is the trickiest layer to scale) isn't a good idea.
90
93
 
91
 
We do recognize that the ability to reduce the time row locks are held
92
 
by using stored procedures is valuable, but think we can achieve the same 
93
 
advantage by improved batching of commands over the wire instead of adding and
 
94
We do recognise that the ability to reduce the time row locks are held
 
95
by using stored procedures is valuable, but think the same advantage can
 
96
be gotten with improved batching of commands over the wire instead of adding
94
97
administering stored procedures to the list of things that can go wrong in
95
 
administering the database.
 
98
admisistering the database.
96
99
 
97
100
Triggers
98
101
--------
105
108
-----
106
109
 
107
110
SQL Views are not currently supported in Drizzle. We believe they should be
108
 
implemented via a query rewrite plugin. See the `Query Rewrite Blueprint <https://blueprints.launchpad.net/Drizzle/+spec/query-rewrite>`_ on launchpad.
 
111
implemented via a query rewrite plugin. See the `Query Rewrite Blueprint <https://blueprints.launchpad.net/drizzle/+spec/query-rewrite>`_ on launchpad.
109
112
 
110
113
Partitioning
111
114
------------
113
116
INFORMATION_SCHEMA
114
117
------------------
115
118
 
116
 
The INFORMATION_SCHEMA provides access to database metadata.
117
 
 
118
119
The INFORMATION_SCHEMA in Drizzle is strictly ANSI compliant. If you write
119
120
a query to any of the tables in the INFORMATION_SCHEMA in Drizzle, you can
120
121
directly run these on any other ANSI compliant system.
127
128
Authentication, Authorization and Access
128
129
----------------------------------------
129
130
 
130
 
Authentication lies in Drizzle plugins. Currently there are PAM and HTTP AUTH plugins for authentication.
 
131
Plugins. Currently there are PAM and HTTP AUTH plugins for authentication.
131
132
Through the PAM plugin, you can use any PAM module (such as LDAP).
132
133
 
133
134
Command line clients
138
139
No gotcha of using the unix socket when localhost is specified and then
139
140
connecting you to the wrong database server.
140
141
 
141
 
There is no Drizzle admin command.
 
142
There is no drizzleadmin command.
142
143
 
143
144
Storage Engines
144
145
---------------
156
157
---------
157
158
 
158
159
There are no FRM files in Drizzle. Engines now own their own metadata.
159
 
Some still choose to store these in files on disk. These are now in a
 
160
Some choose to still store these in files on disk. These are now in a
160
161
documented file format (using the google protobuf library).
161
162
 
162
163
SHOW commands
167
168
queries. Our INFORMATION_SCHEMA implementation does not have the drawbacks
168
169
of the MySQL implementation.
169
170
 
170
 
Here are some specific SHOW differences:
171
 
 
172
171
 * SHOW ENGINES: use DATA_DICTIONARY
173
 
 * SHOW CREATE TABLE: specifies the AUTO_INCREMENT at CREATE/ALTER TABLE time,
174
 
   not the current AUTO_INCREMENT
175
 
 * SHOW TABLE STATUS: only shows tables in the current table cache
176
 
 * SHOW [ENGINE] STATUS: use the DATA_DICTIONARY tables for that engine
177
172
 
178
173
Removed commands
179
174
----------------
183
178
 * CREATE FUNCTION
184
179
 * CONVERT
185
180
 * SET NAMES
186
 
 * Multi-table delete and multi-table update code was removed and can be accomplished through subqueries. More detailed information can be found in the :doc:`dml` section.
187
181
 
188
182
Operators Removed
189
183
-----------------
190
184
 
191
 
Bit operators
192
 
 * &&
193
 
 * >>
194
 
 * <<
195
 
 * ~
196
 
 * ^
197
 
 * '|'
198
 
 * &
 
185
Bit operators: &&, >>, <<, ~, ^, |, &
199
186
 
200
187
Removed functions
201
188
-----------------
206
193
 
207
194
Keywords removed
208
195
----------------
209
 
 
210
196
 * BIT_AND
211
197
 * BIT_OR
212
198
 * BIT_XOR