← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to docs/mysql_differences.rst

  • Committer: brian
  • Date: 2008-06-25 05:29:13 UTC
  • Revision ID: brian@localhost.localdomain-20080625052913-6upwo0jsrl4lnapl
clean slate

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/mysql_differences.rst
1
 
=========================
2
 
Notable MySQL Differences
3
 
=========================
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.
8
 
 
9
 
Usage
10
 
-----
11
 
 * There is no embedded server. The Drizzle Server is not loadable as a shared
12
 
   library.
13
 
 * Drizzle is optimized for massively concurrent environments. If we have the
14
 
   choice of improving performance for 1024 simultaneous connections to the
15
 
   detriment of performance with only 64 connections, we will take that choice.
16
 
 * It is designed for modern POSIX systems
17
 
 * Microsoft Windows is not a supported platform (neither is HP-UX or IRIX).
18
 
 * Drizzle doesn't use timezones. Everything is UTC.
19
 
 
20
 
Installation
21
 
------------
22
 
 
23
 
 * No scripts/mysql_install_db or similar. Drizzle aims for a "just works" installation, without administrative overhead.
24
 
 * No system database that needs upgrading between versions.
25
 
 * Drizzle can listen on the Drizzle port (4427) and/or MySQL port (3306)
26
 
   and speak the respective protocols.
27
 
 
28
 
Architecture
29
 
------------
30
 
 
31
 
Drizzle is designed around the concept of being a microkernel. There should
32
 
be a small core of the server with most functionality being provided through
33
 
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.
35
 
 
36
 
Drizzle is written in C++ and makes use of the Standard Template Library (STL)
37
 
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
39
 
instead.
40
 
 
41
 
Network protocol
42
 
----------------
43
 
 
44
 
Pluggable network protocols allow Drizzle to speak one (or more) of several
45
 
protocols. Currently we support the MySQL protocol (compatible with existing
46
 
MySQL client libraries) and the Drizzle protocol which is still under
47
 
development.
48
 
 
49
 
The Drizzle protocol embodies several important differences from MySQL:
50
 
 
51
 
 * 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
 
 
56
 
There is also a console plugin -- instead of providing access over a network
57
 
socket, this plugin allows access from the current tty.
58
 
 
59
 
Plugin API
60
 
----------
61
 
 
62
 
The existing plugin APIs that Drizzle inherited from MySQL have been reworked.
63
 
 
64
 
 * User Defined Functions (UDFs) now follow the same API as a given
65
 
   server instead of a different C API. This means that UDFs are on the
66
 
   exact same level as built-in functions.
67
 
 * Storage Engine API has had some parts extensively reworked, especially
68
 
   around transactions and DDL.
69
 
 * Logging is now pluggable
70
 
 * Authentication is pluggable
71
 
 * Replication is pluggable
72
 
 * INFORMATION_SCHEMA plugins have been replaced by the function_engine, which
73
 
   is a lot more space and time efficient.
74
 
 * Network protocols are pluggable
75
 
 * Scheduler is pluggable (multi_thread, pool_of_threads etc)
76
 
 * Plugin points for manipulating rows before/after operations: used for
77
 
   replication and the PBMS Blob Streaming plugin.
78
 
 
79
 
Stored Procedures
80
 
-----------------
81
 
 
82
 
Drizzle does not currently have any plugins that implement stored procedures. We
83
 
viewed the implementation in MySQL to be non-optimal, bloating the parser
84
 
and only supporting one language (SQL2003 stored procedures), which was not
85
 
well known.
86
 
 
87
 
Fundamentally, stored procedures usually are not the correct architectural
88
 
decision for applications that need to scale. Pushing more computation down
89
 
into the database (which is the trickiest layer to scale) isn't a good idea.
90
 
 
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
 
administering stored procedures to the list of things that can go wrong in
95
 
administering the database.
96
 
 
97
 
Triggers
98
 
--------
99
 
 
100
 
Drizzle does not currently have any plugin that provides SQL triggers. We
101
 
have some hooks for callbacks inside the server so that plugins can hook
102
 
into points that triggers could.
103
 
 
104
 
Views
105
 
-----
106
 
 
107
 
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.
109
 
 
110
 
Partitioning
111
 
------------
112
 
 
113
 
INFORMATION_SCHEMA
114
 
------------------
115
 
The INFORMATION_SCHEMA provides access to database metadata.
116
 
 
117
 
The INFORMATION_SCHEMA in Drizzle is strictly ANSI compliant. If you write
118
 
a query to any of the tables in the INFORMATION_SCHEMA in Drizzle, you can
119
 
directly run these on any other ANSI compliant system.
120
 
 
121
 
For information that does not fit into the standard, there is also the
122
 
DATA_DICTIONARY schema. Use of tables in DATA_DICTIONARY is non-portable.
123
 
 
124
 
This allows developers to easily know if the query is portable or not.
125
 
 
126
 
Authentication, Authorization and Access
127
 
----------------------------------------
128
 
 
129
 
Authentication lies in Drizzle plugins. Currently there are PAM and HTTP AUTH plugins for authentication.
130
 
Through the PAM plugin, you can use any PAM module (such as LDAP).
131
 
 
132
 
Command line clients
133
 
--------------------
134
 
 
135
 
We've stopped the confusion: -p means port and -P means password.
136
 
 
137
 
No gotcha of using the unix socket when localhost is specified and then
138
 
connecting you to the wrong database server.
139
 
 
140
 
There is no Drizzle admin command.
141
 
 
142
 
Storage Engines
143
 
---------------
144
 
 
145
 
 * MERGE storage engine has been removed
146
 
 * FEDERATED storage engine has been removed (all current development is
147
 
   focused on FederatedX, so having FEDERATED made no sense).
148
 
 * CSV engine is now for temporary tables only. See the filesystem_engine for
149
 
   the future of reading files as database tables.
150
 
 * MyISAM is for temporary tables only.
151
 
 * ARCHIVE is fully supported
152
 
 * PBXT is merged
153
 
 
154
 
FRM Files
155
 
---------
156
 
 
157
 
There are no FRM files in Drizzle. Engines now own their own metadata.
158
 
Some still choose to store these in files on disk. These are now in a
159
 
documented file format (using the google protobuf library).
160
 
 
161
 
SHOW commands
162
 
-------------
163
 
 
164
 
Several SHOW commands have been removed, replaced with INFORMATION_SCHEMA
165
 
or DATA_DICTIONARY views. All SHOW commands are aliases to INFORMATION_SCHEMA
166
 
queries. Our INFORMATION_SCHEMA implementation does not have the drawbacks
167
 
of the MySQL implementation.
168
 
 
169
 
 * SHOW ENGINES: use DATA_DICTIONARY
170
 
 
171
 
Removed commands
172
 
----------------
173
 
 
174
 
 * ALTER TABLE UPGRADE
175
 
 * REPAIR TABLE
176
 
 * CREATE FUNCTION
177
 
 * CONVERT
178
 
 * SET NAMES
179
 
 
180
 
Operators Removed
181
 
-----------------
182
 
 
183
 
Bit operators: &&, >>, <<, ~, ^, |, &
184
 
 
185
 
Removed functions
186
 
-----------------
187
 
 
188
 
 * crypt()
189
 
 * bit_length()
190
 
 * bit_count()
191
 
 
192
 
Keywords removed
193
 
----------------
194
 
 * BIT_AND
195
 
 * BIT_OR
196
 
 * BIT_XOR
197
 
 * CIPHER
198
 
 * CLIENT
199
 
 * CODE
200
 
 * CONTRIBUTORS
201
 
 * CPU
202
 
 * DEFINER
203
 
 * DES_KEY_FILE
204
 
 * ENGINES
205
 
 * EVERY
206
 
 * IO
207
 
 * IPC
208
 
 * ISSUSER
209
 
 
210
 
Objects Removed
211
 
---------------
212
 
 
213
 
 * There is no requirement for a 'mysql' schema.
214
 
 * There is no SET datatype, use ENUM.
215
 
 * There is no SET NAMES command, UTF-8 by default
216
 
 * There is no CHARSET or CHARACTER SET commands, everything defaults to UTF8
217
 
 * There is no TIME type, use DATETIME or INT.
218
 
 * There is no TINYINT, SMALLINT or MEDIUMINT. Integer operations have been optimized around 32 and 64 bit integers.
219
 
 * There are no TINYBLOB, MEDIUMBLOB and LONGBLOB datatypes. We have optimized a single BLOB container.
220
 
 * There are no TINYTEXT, MEDIUMTEXT and LONGTEXT datatypes. Use TEXT or BLOB.
221
 
 * There is no UNSIGNED (as per the standard).
222
 
 * There are no spatial data types GEOMETRY, POINT, LINESTRING & POLYGON (go use `Postgres <http://www.postgresql.org>`_).
223
 
 * No YEAR field type.
224
 
 * There are no FULLTEXT indexes for the MyISAM storage engine (the only engine FULLTEXT was supported in). Look at either Lucene, Sphinx, or Solr.
225
 
 * No "dual" table.
226
 
 * The "LOCAL" keyword in "LOAD DATA LOCAL INFILE" is not supported