Ohio Linux Fest -- MySQL's NoSQL

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1
Insert Picture Here
MySQL's NoSQL
Dave Stokes
MySQL Community Manager
David.Stokes@Oracle.com
@stoker
Slideshare.net/davidmstokes
Insert Picture Here

Safe Harbor
The following is intended to outline our general product direction. It
is intended for information purposes only, and may not be
incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in
making purchasing decision. The development, release, and timing
of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.

MySQL
 Most popular database on the web
 Ubiquitous
 16+ million instances
 Feeds 80% of Hadoop installs
 20 Years Old

But what
have you
done for us
lately??

http://www.thecompletelistoffeatures.com/

Relational Data
● Based on relational calculus, set theory
● Been heavily used for decades
● Many vendors
● Goal: Store data efficiently

Relational Data
● ACID (from Wikipedia https://en.wikipedia.org/wiki/ACID)
● Atomicity – requires that each transaction be "all or nothing": if one part of the
transaction fails, the entire transaction fails, and the database state is left unchanged
● Consistency – ensures that any transaction will bring the database from one valid
state to another.
● Isolation – the concurrent execution of transactions results in a system state that
would be obtained if transactions were executed serially
● Durability – means that once a transaction has been committed, it will remain so,
even in the event of power loss, crashes, or errors.

So why NoSQL?!?
● A NoSQL (often interpreted as Not only SQL) database provides
a mechanism for storage and retrieval of data that is modeled in
means other than the tabular relations used in relational
databases. (https://en.wikipedia.org/wiki/NoSQL)
● Motivations for this approach include simplicity of design,
presumed better "horizontal" scaling to clusters of machine,
which is a problem for relational databases, and presumed finer
control over availability.

CAP Theorem
CAP theorem states that it is impossible for a distributed computer
system to simultaneously provide all three of the following guarantees:
● Consistency (all nodes see the same data at the same time)
● Availability (a guarantee that every request receives a response about
whether it succeeded or failed)
● Partition tolerance (the system continues to operate despite arbitrary
partitioning due to network failures)
(https://en.wikipedia.org/wiki/CAP_theorem)

Want BOTH! What to do?!?!?!
● Polyglot Databases – Use best storage approach for the data
● Oracle, Postgresql, MySQL, etc. all adopting some NoSQL features
● NoSQL trying to adopt SQL
● Vendors not dumb!
● Better for consumers

Access SQL
and NoSQL
One set of disks
Simultaneous access
MySQL InnoDB tables and NDB tables
Use SQL and/or Key/Value pair
2,000,000,000 writes a minute with MySQL Cluster
At the same time!

Benefits
Raw performance for simple lookups. Direct access to the InnoDB storage engine avoids the
parsing and planning overhead of SQL. Running memcached in the same process space as
the MySQL server avoids the network overhead of passing requests back and forth.
Data is stored in a MySQL database to protect against crashes, outages, and corruption.
The transfer between memory and disk is handled automatically, simplifying application logic.
Data can be unstructured or structured, depending on the type of application. You can make
an all-new table for the data, or map the NoSQL-style processing to one or more existing
tables.

Benefits continued
You can still access the underlying table through SQL, for reporting, analysis, ad hoc queries, bulk
loading, set operations such as union and intersection, and other operations well suited to the
expressiveness and flexibility of SQL.
You can ensure high availability of the NoSQL data by using this feature on a master server in
combination with MySQL replication.
The integration of memcached with MySQL provides a painless way to make the in-memory data
persistent, so you can use it for more significant kinds of data. You can put more add, incr, and similar
write operations into your application, without worrying that the data could disappear at any moment.
You can stop and start the memcached server without losing updates made to the cached data. To
guard against unexpected outages, you can take advantage of InnoDB crash recovery, replication, and
backup procedures.
The way InnoDB does fast primary key lookups is a natural fit for memcached single-item queries. The
direct, low-level database access path used by the memcached plugin is much more efficient for key-
value lookups than equivalent SQL queries.

More Benefits Continued
The serialization features of memcached, which can turn complex data structures, binary files, or even
code blocks into storeable strings, offer a simple way to get such objects into a database.
Because you can access the underlying data through SQL, you can produce reports, search or update
across multiple keys, and call functions such as AVG() and MAX() on the memcached data. All of
these operations are expensive or complicated with the standalone memcached.
You do not need to manually load data into memcached at startup. As particular keys are requested
by an application, the values are retrieved from the database automatically, and cached in memory
using the InnoDB buffer pool.
Because memcached consumes relatively little CPU, and its memory footprint is easy to control, it can
run comfortably alongside a MySQL instance on the same system.
Because data consistency is enforced through the usual mechanism as with regular InnoDB tables,
you do not have to worry about stale memcached data or fallback logic to query the database in the
case of a missing key

Installation
mysql> install plugin daemon_memcached soname "libmemcached.so";

Here is an example using telnet to send memcached commands and receive
results through the ASCII protocol:
● telnet 127.0.0.1 11211
● set a11 10 0 9
● 123456789
● STORED
● get a11
● VALUE a11 0 9
● 123456789
● END
● quit
Set memory location 'a11'
to hold 9 characters
'123456789' – 10 & 0 are
TTL and flags

Can it be used with MySQL Replication?
Because the InnoDB memcached daemon plugin supports the
MySQL binary log, any updates made on a master server through the
memcached interface can be replicated for backup, balancing
intensive read workloads, and high availability. All memcached
commands are supported for binlogging.
You do not need to set up the InnoDB memcached plugin on the
slave servers. In this configuration, the primary advantage is
increased write throughput on the master. The speed of the
replication mechanism is not affected

With MySQL Cluster

Bypass MySQL daemon!
● 4.2 billions reads/min
● 1.2 billion updates/min
● 2 billion writes a min
● MySQL Cluster

Can MySQL Replication work with Hadoop?

Native JSON Data Type
mysql> CREATE TABLE employees (data JSON);
Query OK, 0 rows affected (0,01 sec)
mysql> INSERT INTO employees VALUES ('{"id": 1, "name": "Jane"}');
Query OK, 1 row affected (0,00 sec)
mysql> INSERT INTO employees VALUES ('{"id": 2, "name": "Joe"}');
Query OK, 1 row affected (0,00 sec)
mysql> select * from employees;
+---------------------------+
| data |
+---------------------------+
| {"id": 1, "name": "Jane"} |
| {"id": 2, "name": "Joe"} |
+---------------------------+
2 rows in set (0,00 sec)

Validation and Effiency
Document Validation
● Only valid JSON documents can be stored in a JSON column, so you get automatic
validation of your data. If you try to store an invalid JSON document in a JSON column, you
will get an error
Efficient Access
● JSON document in a JSON column it is stored in an optimized binary format that allows for
quicker access to object members and array elements.
● The binary format of a JSON column contains a preamble with a lookup table. The lookup
table has pointers to every key/value pair in the JSON document, sorted on the key. The
json_EXTRACT function to perform a binary search for the ‘name’ key in the table and read
the corresponding value directly, without having to parse the ‘id’ key/value pair that precedes
it within the JSON document.

JSON Functions
● Manipulating JSON documents:
● json_array()
● json_object()
● json_insert()
● json_remove()
● json_set()
● json_replace()
● json_append()
● json_merge()
● json_extract()
● JSON Query:
● json_SEARCH()
● json_CONTAINS()
● json_CONTAINS_PATH()
● json_VALID()
● json_TYPE()
● json_KEYS()
● json_LENGTH()
● json_DEPTH()
● json_UNQUOTE()
● json_QUOTE()

Quick Example
mysql> desc colors;
+--------------+----------+------+-----+---------+-------------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+----------+------+-----+---------+-------------------+
| popular_name | char(10) | YES | | NULL | |
| hue | json | YES | | NULL | |
+--------------+----------+------+-----+---------+-------------------+
2 rows in set (0.00 sec)
INSERT INTO `colors` VALUES ('red','{"value": "f00"}'),
('green','{"value": "0f0"}'),('blue','{"value": "00f"}'),('cyan','{"value":
"0ff"}'),('magenta','{"value": "f0f"}'),('yellow','{"value": "ff0"}'),
('black','{"value": "000"}');

Using json_extract
mysql> SELECT json_extract(hue, '$.value') FROM colors WHERE
popular_name = 'magenta';
+-----------------------------+
| json_extract(hue, '$.value') |
+-----------------------------+
| "f0f" |
+-----------------------------+
1 row in set (0.00 sec)

That is great but ...
That JSON_EXTRACT stuffs seems to
make using regular MySQL Indexes pretty
messy.
● Yup, the previous query results in a full
table scan (bad)

Indexing JSON Data
● Use GENERATED columns
● mysql> ALTER TABLE colors ADD value_ext char(10) GENERATED
ALWAYS AS (jsn_extract(hue, '$.value')) VIRTUAL;
● Two types of generated columns
● VIRTUAL – when read
● STORED – when written
● mysql> CRATE INDEX value_ext_index ON colors(value_ext);
● Now the query uses the index and efficiently gets data (yea!!)

For More Information
● Mysql.com
● Labs.mysql.com
● Planet.mysql.com
● Thecompletelistoffeatures.com
– MySQL 5.7 new features
● Dave Stokes
David.Stokes@Oracle.com
@stoker
slideshare.net/davidmstokes

Ohio Linux Fest -- MySQL's NoSQL

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Ohio Linux Fest -- MySQL's NoSQL

Similaire à Ohio Linux Fest -- MySQL's NoSQL (20)

Plus de Dave Stokes

Plus de Dave Stokes (20)

Dernier

Dernier (11)

Ohio Linux Fest -- MySQL's NoSQL