0
0
1
959
5469
Homework
45
12
6416
14.0
Normal
0
false
false
false
EN-US
JA
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-ansi-language:EN-US;}
Yesterday we ran a webinar discussing the
demands of next generation web services and how blending the best of relational
and NoSQL technologies enables developers and architects to deliver the
agility, performance and availability needed to be successful.
Attendees posted a number of great
questions to the MySQL developers, serving to provide additional insights into areas like auto-sharding and cross-shard JOINs,
replication, performance, client libraries, etc. So I thought it would be useful to post those
below, for the benefit of those unable to attend the webinar.
Before getting to the Q&A, there are a
couple of other resources that maybe useful to those looking at NoSQL
capabilities within MySQL:
- On-Demand webinar (coming
soon!)
- Slides used during the webinar
- Guide to MySQL and NoSQL
whitepaper
- MySQL Cluster demo, including
NoSQL interfaces, auto-sharing, high availability, etc.
So here is the Q&A from the event
Q.
Where does MySQL Cluster fit in to the CAP theorem?
A. MySQL Cluster is flexible. A single
Cluster will prefer consistency over availability in the presence of network
partitions. A pair of Clusters can be configured to prefer availability over
consistency. A full explanation can be found on the MySQL Cluster & CAP Theorem blog post.
Q.
Can you configure the number of replicas? (the slide used a replication factor
of 1)
Yes. A cluster is configured by an .ini
file. The option NoOfReplicas sets the number of originals and replicas: 1 = no
data redundancy, 2 = one copy etc. Usually there's no benefit in setting it
>2.
Q. Interestingly most (if not all) of the NoSQL databases recommend having 3 copies of data (the replication factor).
Yes, with configurable quorum based Reads and writes. MySQL Cluster does not need a quorum of replicas online to provide service. Systems that require a quorum need > 2 replicas to be able to tolerate a single failure. Additionally, many NoSQL systems take liberal inspiration from the original GFS paper which described a 3 replica configuration. MySQL Cluster avoids the need for a quorum by using a lightweight arbitrator. You can configure more than 2 replicas, but this is a tradeoff between incrementally improved availability, and linearly increased cost.
Q.
Can you have cross node group JOINS? Wouldn't that run into the risk of
flooding the network?
MySQL Cluster 7.2 supports cross nodegroup
joins. A full cross-join can require a large amount of data transfer, which may
bottleneck on network bandwidth. However, for more selective joins, typically
seen with OLTP and light analytic applications, cross node-group joins give a
great performance boost and network bandwidth saving over having the MySQL
Server perform the join.
Q.
Are the details of the benchmark available anywhere? According to my
calculations it results in approx. 350k ops/sec per processor which is the
largest number I've seen lately
The details are linked from Mikael
Ronstrom's blog
The benchmark uses a benchmarking tool we
call flexAsynch which runs parallel asynchronous transactions. It involved 100
byte reads, of 25 columns each. Regarding the per-processor ops/s, MySQL
Cluster is particularly efficient in terms of throughput/node. It uses
lock-free minimal copy message passing internally, and maximizes ID cache
reuse. Note also that these are in-memory tables, there is no need to read
anything from disk.
Q. Is
access control (like table) planned to be supported for NoSQL access mode?
Currently we have not seen much need for
full SQL-like access control (which has always been overkill for web apps and
telco apps). So we have no plans, though especially with memcached it is
certainly possible to turn-on connection-level access control. But specifically
table level controls are not planned.
Q. How
is the performance of memcached APi with MySQL against memcached+MySQL or any
other Object Cache like Ecache with MySQL DB?
With the memcache API we generally see a
memcached response in less than 1 ms. and a small cluster with one memcached
server can handle tens of thousands of operations per second.
Q.
Can .NET can access MemcachedAPI?
Yes, just use a .Net memcache client such
as the enyim or BeIT memcache libraries.
Q. Is
the row level locking applicable when you update a column through memcached API?
An update that comes through memcached uses
a row lock and then releases it immediately. Memcached operations like
"INCREMENT" are actually pushed down to the data nodes. In most cases
the locks are not even held long enough for a network round trip.
Q. Has
anyone published an example using something like PHP? I am assuming that you just use the PHP
memcached extension to
hook into the memcached API. Is that correct?
Not that I'm aware of but absolutely you
can use it with php or any of the other drivers
Q. For
beginner we need more examples.
Take a look here for a fully worked example
Q. Can I access MySQL using Cobol (Open Cobol) or C and if so where can I find the coding libraries etc?
A. There is a cobol implementation that works well with MySQL, but I do not think it is Open Cobol. Also there is a MySQL C client library that is a standard part of every mysql distribution
Q. Is
there a place to go to find help when testing and/implementing the NoSQL
access?
If using Cluster then you can use the
[email protected] alias or post on the MySQL Cluster forum
Q. Are there any white papers on this?
Yes - there is more detail in the MySQL Guide to NoSQL whitepaper
If you have further questions, please don’t
hesitate to use the comments below!
