MySQL Blogs

MySQL Connector/Net 6.7.2, a new version of the all-managed .NET driver for MySQL has been released.  This is the first beta release intended to introduce users to the new features in the release.  This release is feature complete, it should be stable enough for users to understand the new features and how we expect them to work.  As is the case with all non-GA releases, it should not be used in any production environment.  It is appropriate for use with MySQL server versions 5.0-5.7.
PlanetMySQL Voting: Vote UP / Vote DOWN

NetMotion Wireless develops software to manage and secure wireless data deployments for organizations with mobile field workers. Founded in 2001, NetMotion Wireless is one of the fastest growing wireless and technology companies and the recipient of over 25 awards for outstanding technology.  NetMotion Wireless has over 2,500 customers, including Advocate Healthcare, Comcast, and Unilever.

NetMotion Wireless had used Microsoft SQL Server with Mobility Analytics, their mobile VPN product’s analytics module, but found it was too costly and lacked the platform and language flexibility to be a good [embedded] database. As a result, when the NetMotion Wireless product team was developing Locality, a cellular network management product, they decided to find an alternative database to use with it and with Mobility Analytics. The team compared MySQL with Microsoft SQL Server on a number of key criteria and, after finding nothing in the “con column”, decided to use MySQL.

According to Jonathan Wiggs, NetMotion Wireless database architect, MySQL has been able to meet their products’ needs for:

• Real-time Data Collection and Analysis – with the ability to scale to hundreds of terabytes.
• Strong .NET and Java Support – “MySQL works every bit as well with ado.net as SQL Server, and its Java integration is equally good,” said Wiggs.
• Database Profiling and Tracing – MySQL Enterprise Monitor provided back level visibility on par with other enterprise databases, providing the data analytics and caching levels their products require.  
• Easy, Transparent Administration -“MySQL’s administration is automated, easy to configure, and highly configurable: we can get it to leap through any flaming hoops we need,” said Wiggs.
• “The Perfect Trifecta” - “There has been no tradeoff in using MySQL.  MySQL has provided the perfect trifecta of feature parity, ease of integration, and lower cost,” said Wiggs.

Read more>>

• NetMotion Wireless MySQL Case Study
• “MySQL on Windows: Reducing Costs with the New Migration Wizard” on-demand webinar
• MySQL TCO Calculator
• “MySQL on Windows: Why, Where, How” white paper
• More MySQL on Windows Resources

PlanetMySQL Voting: Vote UP / Vote DOWN

Read the original article at Make MySQL clustering work for you

We’ve told you all about MySQL mult-master replication’s limitations. If you write to two masters it is bound to fail for myriad reasons. Now what? Do what the pros do that’s what. A. Don’t write to both masters Using multi-master replication works great as long as you do so in active-passive mode. Never write to [...]

For more articles like these go to Sean Hull's Scalable Startups

Related posts:

1. Limitations of MySQL row-based replication
2. No tools to reconcile MySQL with two masters
3. 5 Ways to fortify MySQL replication
4. MySQL needs single master to check data integrity
5. MySQL Cluster In The Cloud – Managers Guide

PlanetMySQL Voting: Vote UP / Vote DOWN

Software Carpentry is running a 2-day software skills boot camp in Boston, June 24-25th 2013, for women in science, engineering, medicine, and related research
areas. Registration is $20.

Boot camps alternate short tutorials with hands-on practical exercises. You are taught tools and concepts you can use immediately to increase your productivity and improve confidence in your results. Topics covered include the Unix shell, version control, basic Python programming, testing, and debugging — the core skills needed to write, test and manage research software.

This boot camp is open to women at all stages of their research careers, from graduate students, post-docs, and faculty to staff scientists at hospitals and in the public, private, and non-profit sectors.

Registration is $20; to sign up, or find out more, please visit the announcement at http://software-carpentry.org/blog/2013/04/announcing-wise-bootcamp.html. If you have questions, there is an e-mail link on the announcement page.

For those curious, they are using sqlite, not MySQL or PostgreSQL, and I will be helping out with the SQL parts. There are about 2 months left but the boot camp is about 2/3 full right now, so I wanted to make sure this opportunity was spread to as many people as possible so they do not hear about it too late.

PlanetMySQL Voting: Vote UP / Vote DOWN

The world's largest producer of casual games has selected MySQL Cluster to power its real-time recommendations platform.

High velocity data ingestion, low latency reads, on-line scaling and the operational simplicity delivered by MySQL Cluster has enabled Big Fish to increase customer engagement and deliver targeted marketing, providing a more personalized experience to its users.

You can read the full Big Fish Games and MySQL Cluster case study here - and a summary below

BUSINESS NEED

The global video gaming market is experiencing explosive growth. Competition is intense, and so to differentiate services and engage users, progressive gaming companies such as Big Fish are seeking solutions to more fully personalize the customer experience.

Using Business Intelligence (BI) and predictive analytics Big Fish can segment customers based on a range of demographic and behavioural indicators. This enables Big Fish to serve highly targeted recommendations and marketing, precisely personalized to a user's individual preferences.

Big Fish's Marketing Management Service platform, powered by MySQL Cluster, is used across all of the company's customer management systems, including customer support and the company's "Game Manager", to provide a unique customer experience to each of its millions of monthly users whenever they come in contact with Big Fish.

TECHNOLOGY SELECTION

Big Fish already has an extensive deployment of MySQL databases powering web applications, including the storefront. They knew MySQL could power the recommendations database, but would require additional engineering efforts to implement database sharding to support data ingest and future scaling needs, coupled with a Memcached layer for low-latency reads.

As a result, they began evaluations of MySQL Cluster, in addition to other database technologies. Using MySQL Cluster, the Engineering teams were able to leverage their existing MySQL skills, enabling them to reduce operational complexity when compared to introducing a new database to the Big Fish environment.

At the same time, they knew MySQL Cluster, backed by Oracle, provided the long-term investment protection they needed for the MMS recommendations platform.

Through their evaluation, the Big Fish engineering team identified MySQL Cluster was best able to meet their technical requirements, based on:

Write performance to support high velocity data ingest

Low latency access with in-memory tables 

On-line scalability, adding nodes to a running cluster

Continuous availability with its shared-nothing architecture

SQL and NoSQL APIs to the cluster supporting both fast data loading and complex queries

PROJECT IMPLEMENTATION

As illustrated in the figure below:

• User data is replicated from the MySQL databases powering the gaming storefront to the Big Fish BI platform;
• User data is analyzed and segmented within the BI platform;
• Recommendations are loaded as user records into MySQL Cluster using the NoSQL Cluster_J (Java) Connector;
• The SQL interface presented by the MySQL Servers then delivers personalized content to gamers in real-time, initially serving over 15m sessions per day.

Big Fish has subscribed to MySQL Cluster CGE providing the Engineering team with access to 24x7 Oracle Premier Support and MySQL Cluster Manager, which reduces operational overhead by providing:

• Automated configuration and reconfiguration of MySQL Cluster;
• Automated on-line node addition for on-demand scaling.

The online scalability of MySQL CGE can help Big Fish to meet future requirements, as it expands its use of MySQL CGE to include all new website developments, channels and gaming platforms. 

LEARN MORE

Read the full Big Fish Games and MySQL Cluster case study

Read the press release 

PlanetMySQL Voting: Vote UP / Vote DOWN

“Best Practices for MySQL Scalability.”

If you have not already done so, I encourage you to register for my “Best Practices for MySQL Scalability” Webinar which will take place on May 1st at 10 a.m. PST. This will be an overview presentation, led by me and providing a high-level look at the components of MySQL scalability: application architecture, MySQL version and configuration, choosing hardware and operating systems. For each area we’ll investigate the most important best practices. Talk to you on Wednesday, and remember to prepare your questions in advance to get the most value out of the Webinar!

***

More info: MySQL scalability depends on getting many things right including the architecture, hardware, operating system, MySQL version, MySQL configuration, schema design and indexing, and query design. To avoid having any one of them become the bottleneck that limits the scalability of the entire system, you need to follow best practices in all of these technology areas. Each area deserves its own webinar so we won’t go into the trenches to explore every one in depth. Instead, we will provide an overview of MySQL scalability which highlights the most important considerations and best practices for each of these areas. Register now!

The post Webinar: Best Practices for MySQL Scalability on May 1 appeared first on MySQL Performance Blog.

PlanetMySQL Voting: Vote UP / Vote DOWN

Today I downloaded Fedora 19 alpha to give it a spin. Some quick notes.

You can get MySQL by asking for the package community-mysql-server. This is 5.5.31. If you ask for stock “mysql” (i.e. yum install mysql-server), you automatically get MariaDB 5.5.30 (mariadb-server).

Fedora 19 runs systemd, so there is no longer /etc/init.d/mysql to start/stop/restart. So just do systemctl enable mysqld.service. Then perform: systemctl start mysqld.service. Replace start with: stop/status too. You can disable it too if you want.

MariaDB 10.0.2 compiles cleanly on Fedora 19 with gcc-4.8. Just perform: yum install bzr gzip tar gcc gcc-c++ make libtool bison ncurses-devel zlib-devel automake autoconf cmake. Get the source code (I just downloaded it). Do BUILD/compile-pentium64-max. Wait. Run make test. Enjoy. Refer to build environment setup, generic build instructions.

If running in a VM, set aside 15GB to ensure you always have sufficient space (I personally use 20GB as I like to test various upgrade scenarios too.

Related posts:

1. Using MariaDB on CentOS 6
2. workbench-5.1.1-alpha on Fedora 9
3. Eric Raymond says: “Goodbye, Fedora”

PlanetMySQL Voting: Vote UP / Vote DOWN

Scaling OpenX Click and Impression Logging

By coincidence, my last two jobs I’ve been in have seen me administer a very high traffic ad server. Or maybe not so much a coincidence, since InnoDB is a great OLTP database with a focus on consistent response time - not just raw throughput. It is also very well optimized for the simpler style queries (primary key lookups, simple secondary key etc) which seems to be all that is needed to serve ads.

Anyway, in 2011/2012 I found myself managing OpenX - and discovered some quirks with it.

OpenX 2.6

When I first inherited an OpenX 2.6 install, it was configured in a mode called distributed statistics. What this means is that you have one central database server, and then a series of slave MySQL servers. The impression and click recording web servers write to a slave server, which then has a cron that batches up and writes to the master database server. The master database server always has a copy of all the data - and has a cron that runs a summarization of the data to feed reports.

What I didn’t like about this design is that the master always required all of the data anyway. so the slaves weren’t necessarily adding any capacity. What they were doing however was not without benefit - they were a poor man’s message queue. As data arrived there was some opportunity for flow control so your peaks would be smoothed out. It also enable you to optimize for throughput rather than response and put load on the master without impact to ad serving.

Message queues are a great part of any architecture - I am in love with them. However, in OpenX particular implementation, since the slaves didn’t have all the data, and the master’s summarization used temporary tables it also caused a lot of problems. We couldn’t upgrade to row-based replication because the summarization process created temporary tables with the TYPE=X syntax which had since been deprecated - locking us into an earlier version of MySQL as well.

I also profiled the code and noticed that our performance was very erratic. Sometimes requests were super fast, other times they would wait minutes. What I discovered was that the cron that ran on the slave servers was blocking - when it ran every 5 minutes (configurable) it would CHECK TABLE, then REPAIR TABLE if required! - a paranoid design that is centered around MyISAM. InnoDB has internal consistency checking with page checksums and doesn’t require this. So the first thing I did to improve OpenX 2.6 performance was comment out CHECK TABLE/REPAIR TABLE, and things were instantly much better.

When Open 2.6 was released in 2008, maybe more people had single core machines and web servers processed less traffic - so they may not have noticed exactly how hot of a lock waiting on CHECK TABLE/REPAIR TABLE was - which is a single threaded process inside MySQL. Since our slave servers sat on the web servers, we had these locks fairly well distributed, and since I don’t think the servers synced with NTP, this managed to stay functional for years because machines would fall in and out of service from the load balancer on different cycles. However, as traffic per server increased, it also got much worse.

I also changed the slave servers to not be on the web servers - but a separate tier of servers, which supported x3 web servers per slave without any issues. To me this was more elegant architecturally, because of the time consuming process of rebuilding slaves as they failed due to the master’s use of temporary tables, and that database servers tend to have uniquely different needs to web servers (more memory, faster disks, CPUs less important). However, my little architecture optimization presented me with another problem - the cron that ran on the slaves was consuming too much memory and dying!

What I discovered was that it was simply reading from a few tables, and then inserting those rows on the master (like I said above - a poor man’s message queue). But it did this in PHP and used all sorts of associative arrays that were not memory efficient. I managed to reverse engineer and change this cron to be just a simple shell script which used the MySQL CLI and was incredibly more efficient. It also meant that my CHECK TABLE/REPAIR TABLE patch was obsolete - which made me comfortable having slightly less OpenX code to maintain.

However, OpenX 2.6 was still a beast at best. The ‘monthly’ part of the maintenance script on the master couldn’t delete old impression rows as fast as new ones came in - and the total impressions table was over 1TB and caused a lot of locking inside InnoDB! So I commented out the monthly cleanup code and wrote a standalone script to constantly cleanup old versions of the data. However, my standalone script wasn’t fast enough either, so every month we would temporarily disable the slave crons and master cron while we created a new table like the previous table and then inserted just the small fraction of data we required, renaming and dropping the old table. It was very high effort to maintain, and not particularly operationally friendly.

OpenX 2.8

OpenX obviously figured out on their own that there was a problem with how they were collecting data, because with 2.8 they changed from using raw impression logging of one row per impression to something they called Bucket Based Logging . What they would do, is record only a running count of impressions per ad-zone/creative-id/time-period, and perform an insert on duplicate key update count = count+1. They still had the ability to have “distributed” statistics with the slaves having a part of the data, and the maintenance on the slaves would have a special update to the master with an insert on duplicate key update count = count + my_number.

Taking from my earlier thought process where the slaves are really just message queues, I managed to find a really non invasive way to modify the OpenX code to not write to MySQL, but instead write to a message queue - in my case ZeroMQ. I then wrote some proof of concept code (that a colleague of mine later improved) which would receive from the message queue, and then merge requests by ad-zone/creative-id/time-period and then insert directly onto the master server. Eliminating those pesky slaves!

I left before the project could go live - and from what I heard afterwards, it unfortunately never did. But when I reflect on it, I really don’t like OpenX’s 2.8 bucket based logging and from an operational perspective - I think this would have still been hire maintenance. If one slave was too slow to phone home statistics before the master ran its summary cron, you will be missing statistics. And since the on duplicate key update count = count+1 style design is not idempotent - you can’t easily regenerate statistics to fix data. You are stuck with inaccurate results.

What I would have done now

I would have kept the bucket based logging in 2.8, but cut out the message queue. I would have changed the code that records the click and/or impression to essentially be a no-op, and configured Apache so that it would write out a log file every 5 minutes in a format that records the fields I need:

# /etc/httpd/conf.d/openx.conf LogFormat "%{%Y%m%d-%H%M%S}t\t%>s\t%r\t%{X-Forwarded-For}i\t%{User-agent}i\t%{Referer}i" openxFmt CustomLog "|usr/sbin/rotatelogs /var/log/httpd/in/openx.log-%Y%m%d.%H%M%S 300" openxFmt

Then I would have written a cron to find all log files not currently open, and then summarize them similar to how my message queue reader did + upload the log file to permanent storage (in our case Amazon S3 would have worked). I don’t think that MySQL is the correct place to store the raw data - but it’s essential to be able to reprocess as necessary:

for LOGFILE in `ls /var/log/httpd/in/openx.*`; do if /usr/sbin/lsof -c rotatelog | grep -F $LOGFILE; then echo "Log file $LOGFILE is currently open. Skipping this iteration."; else echo "Log file $LOGFILE is unopened. Doing stuff.."; doStuffAndMoveSomewhere(); fi done

Keeping these log files in plain text on S3 make them easy victims for Amazon EMR - which can read and process directly, and then store the results in MySQL. I would have loved to have eliminated the summarization cron that ran on the master and turned it into a hive query. Then I would have used sqoop to write the results back to MySQL. I am sure refactoring the summarization/maintenance cron to Hive would have been difficult - there were a lot of strange behaviors in it, but it would have made things idempotent, reduced a lot of load on my MySQL servers (which are not good at the complex summarization queries) and meant I could avoid the temporary tables which made replication slaves hard. I would have kept one replication slave for HA.

Also - the more I think about it, being able to keep raw log files is so important. They are incredibly easy to compress and retain, and often take up a lot less space than any (row-store) database indexed equivalent would.

PlanetMySQL Voting: Vote UP / Vote DOWN

From https://fedoraproject.org/wiki/Test_Day:2013-04-30_MariaDB, this installment of Fedora’s Test Day focuses on the replacement of MySQL with MariaDB. If you’re a Fedora (or RHEL or CentOS user), do take a peek at the page and see if you can pitch in – it might be a little bit of work for you, but with great benefits in terms of getting the MariaDB performance and features, and specifically on the day the Fedora crowd have extra people on the case to track and address issues you might find, so it’s an ideal opportunity to upgrade on a development or test-prod environment!

PlanetMySQL Voting: Vote UP / Vote DOWN

Oracle Database has a feature which allows it to query millions of rows in parallel while executing a join which has a big fanout.
How important is it that a database server has a lot of intra-query concurrency? Does it still make a lot of sense to run an analytical query in parallel threads, on a single machine?

While at Percona Live, there was a lot of talk about the future of MySQL, and some even mentioned this as being part of the future.

The reason for intra-query parallelism has always been to fill up the pipeline to disk with lots of parallel queries. Indeed, this pipe is thick and long - and if used, it'd better produce a lot of data at once. Efficiency of CPU utilization is sacrificed to achieve efficiency of a rotating disk drive.

Yet in DaaS world this all fails to make sense to me. In a cloud, one execution unit is not one CPU, but one instance, and one database instance equals to a cluster of virtual machines. Map/Reduce was only the first sign of the change - it is stupid, indeed, but network is faster than disk, and if a query needs to inspect a million of rows, they'd better be on thousands of disks, not on a single one.

It's funny how MySQL technology is steadily pulled up-market. I haven't seen a single project use MySQL Stored Procedures, which were created for SAP R/3 integration, in applications they were created for. Perhaps, when parallel query in MySQL is ready, it also will be used for something completely different.

Meanwhile, I think the task of coming up with an efficient join algorithm to run across sharded data is more in line with the way hardware is going to look like in the future. Sharding is done best when not done at all. But so is concurrency.
PlanetMySQL Voting: Vote UP / Vote DOWN

Oracle is the most powerful DBMS in the world. However, Oracle's expensive and complex replication makes it difficult to build highly available applications or move data in real-time to data warehouses and popular databases like MySQL.  In this webinar you will learn how Continuent Tungsten solves problems with Oracle replication at a fraction of the cost of other solutions and with less
PlanetMySQL Voting: Vote UP / Vote DOWN

Last week Tokutek announced that they’re open-sourcing their TokuDB storage engine for MySQL. If you’re not familiar with TokuDB, it’s an ACID-compliant storage engine with a high-performance index technology known as fractal tree indexing. Fractal trees have a number of nice characteristics, but perhaps the most interesting is that they deliver consistently high performance under varying conditions, such as when data grows much larger than memory or is updated frequently. B-tree indexes tend to get fragmented over time, and exhibit a performance cliff when data doesn’t fit in memory anymore.

The MySQL community is excited about having access to TokuDB’s source code, and rightly so. TokuDB is, broadly speaking, aimed at the same category of use cases as Oracle’s InnoDB, which has been MySQL’s leading storage engine for a long time.

MySQL’s market size is large for an opensource product (roughly $500M to $1B USD, depending on who you talk to), and in a big pond, a stone causes wide ripples. I think the most significant implications, though, are for MongoDB. Tokutek has published a series of benchmarks of MongoDB performance with TokuDB as the storage engine instead of MongoDB’s default storage engine. The results are compelling.

I think TokuDB will rapidly become the storage engine of choice for MongoDB, and could catapult MongoDB into the lead in the NoSQL database arena. This would have profound implications for opensource databases of all flavors, not just NoSQL databases.

It’s worth revisiting a bit of ancient history for some context.

Way back in the olden days, MySQL’s main storage engine was MyISAM. MyISAM is non-transactional and has table-level locking, meaning that a write (update, insert, delete, or similar) blocked all concurrent access to the table. This is okay for some uses, and can even be very good in special cases, but in the general case it is a disaster. MyISAM introduced some special workarounds for common cases (such as permitting nonblocking inserts to occur at the end of the table), but in the end, you can’t fix table-level locking. A mixed workload needs storage that’s designed for high read and write concurrency without blocking.

MyISAM had other problems, such as lacking transactions, being prone to data corruption, and long repair times after a crash.

As a result, MySQL as a whole was only interesting to a minority of users. For demanding applications it was little more than a curiosity.

Then came InnoDB. InnoDB introduced ACID transactions, automatic crash recovery, and most importantly, row-based locking and MVCC, which allowed highly concurrent access to rows, so readers and writers don’t block each other. InnoDB was the magic that made MySQL a credible choice for a wide range of use cases.

Most of the interesting chapters in MySQL’s history have involved InnoDB in one way or another. To list some highlights: Oracle bought InnoDB’s creator Innobase Oy, MySQL scrambled to find a replacement (Maria, Falcon, PBXT), Sun’s decision to acquire MySQL was said to be influenced by Falcon, Percona created XtraDB, and Oracle acquired Sun. Things are settling down now, but it’s easy to forget how much of a soap opera the MySQL world has lived through because of InnoDB not being owned by MySQL.

And in the middle of all this came NoSQL databases. In the past half-dozen years, more databases have been invented, popularized, and forgotten than I care to think about. In many cases, though, these databases were criticized as ignoring or reinventing (badly) decades of learning in relational database technology, and even computer science in general. I know I’ve looked at my share of face-palm code.

Databases, by and large, depend on reliable, high-performance storage and retrieval subsystems more than anything else. Many of the NoSQL databases have interesting ideas built on top of bad, bad, bad storage code.

MongoDB is a case in point. MongoDB reinvented some of the worst parts of MySQL all over again. Storage was initially little more than mmap over a file. I think Mark Callaghan put it best in 2009, when he said “Reinventing MyISAM is not a feature.” MongoDB’s storage at that time really was MyISAM-like. It’s improved somewhat since then, but it hasn’t had the wholesale rip-and-replace improvement that I think is needed. Not only that, but MongoDB as a whole is still (predictably) built around the limitations of the underlying storage, with coarse-grained locking.

But MongoDB, like MySQL, has been relevant in spite of these shortcomings. Form your own opinion about why this is, but from my point of view there are two main reasons:

• MongoDB was born in an era when the popular databases were frustratingly slow and clunky to work with, and innovation was stalled due to the political drama surrounding them.
• MongoDB simply feels nice to developers. If you’re not a developer, this is a little hard to explain, but it just feels good, like your favorite pair of jeans. Like a hug from a good friend. Like a hammock and a summer day. The difference between an SQL database and MongoDB for many developers is like the difference between an iPod and a cheap knockoff MP3 player. I could go on and on.

It’s difficult to overstate the importance of this, because it means that MongoDB may well become an enterprise database, despite what bad opinions you may have about it now. Why is this? It’s because developers are king in the modern IT enterprise. Developers determine what technologies get adopted in IT. CTOs like to think the decisions come from the top down, but I’ve seen it work the other way time and time again. Developers start to use something that frustrates them less than the alternatives, and a groundswell begins that’s impossible to stop. Someday the CTO discovers that the question of whether to use technology X was decided by a junior developer long ago and deployed to production, and now it’s too late.

I’ve done it myself. At Crutchfield I hijacked the company-wide policy that migration from legacy VB6 to .NET would proceed along the lines of a transition to VB.NET. I was fighting through awful code day in and day out, and I knew that a more restrictive language would prevent a lot of bad practices. So I wrote several major systems in C# without asking permission. It’s a lot easier to get forgiveness than permission. Then I showed off what I’d done. When I left Crutchfield, the IT department had chosen C#, not VB.NET, as its language of the future (even though there were, and probably still are, major VB.NET applications).

Similarly, at Crutchfield I was provided a 15-inch CRT monitor to work on. This was 2003, you understand. Even at that time, it was awful. How can you expect a developer to work on a flickering, small monitor? I bought my own large-screen LCD and put it in my cubicle. Management ordered me to remove it because it was causing a flood of “hey, how did Baron get a nice monitor?” questions, but the camel already had a nose under the tent. I took my monitor home, but not too long after that we all started to get nicer monitors. I brought my own nice chair to work, too. All told I probably forced Crutchfield to spend thousands of dollars upgrading equipment. You have to be careful about headstrong kids like me — don’t turn your backs on us for a moment.

This story illustrates why MongoDB is likely to become a major database: because developers enjoy working with it. It feels pleasant and elegant. Remember, most technology decisions are based on how people feel, not on facts. We’re not rational beings, so don’t expect the best solution to win. Expect people to choose what makes them happy.

And with the availability of TokuDB, MongoDB is lovable by a lot more people. With reliable storage and transactions, uncool kids can like it too.

It goes further than just the storage engine. The kernel of MongoDB has code that needs to be fixed, such as the coarse-grained locking code. Tokutek basically forked MongoDB in order to insert TokuDB into it. They had to, in order to get all that locking out of the way and allow MongoDB to shine with TokuDB on the backend.

I’m not sure exactly how this will play out — will Tokutek start offering a competitive product? Will there be opensource community-based forks of MongoDB that integrate TokuDB? Will 10gen do the engineering to offer TokuDB as a backend? Will 10gen and Tokutek partner to do the engineering and provide support? Will 10gen acquire Tokutek? Will a large company acquire both? You decide.

But I believe that a few things are inevitable, and don’t require a crystal ball to guess.

Anyone who cares about MongoDB is going to be using TokuDB as their storage backend within a matter of months. It’s happened before — look at what happened to MySQL and InnoDB. Look at Riak; people dropped Bitcask like a hot potato when LevelDB storage arrived (although it hasn’t been a perfect solution).

Just to be clear, I do not think that MongoDB’s parallels with MySQL’s history must inevitably repeat in all aspects of the story. The world of databases today (big data, cloud, mobile) is not in the same situation it was when MySQL was creeping into general awareness (web, gaming, social, general lack of good alternatives to commercial databases), and the reasons people use MongoDB now are different from the reasons people chose MySQL back in the day. Still, there’s a good chance that MySQL’s past can teach us about MongoDB’s future, and for some use cases, MongoDB deployments will soon accelerate rapidly. I expect a larger commercial ecosystem to emerge, too; right now the MongoDB market is worth tens of millions, and I’d guess in a few years we’ll look back and see a sharp inflection point in 2013 and 2014. TokuDB could help propel MongoDB’s market size into hundreds of millions of dollars, which is a position occupied uniquely by MySQL today in the opensource database world.

It’s getting real in the MongoDB world — this is going to be interesting to watch.

PlanetMySQL Voting: Vote UP / Vote DOWN

I have worked as an architect in the MySQL/NDB world for more than 20 years and I am still working at Oracle and I like it here. Given all the FUD spread about MySQL I thought it might be a good idea to spread the word about all the great things we're doing to MySQL at Oracle.

#1 We are working on improving modularity in MySQL code base
In the early days of MySQL the MySQL development had serious issues with its development model. It was a model designed for a small code base. I used to work at Ericsson which is developing telecom switches that have systems with tens of millions lines of code. Such large systems require modularity. The Ericsson switches was developed with modularity built into the programming language already since the 70's. Even with this modularity a second level of modularity was required. The learnings from this reengineering project that span over more than a decade has given me valuable insights that can now be put to use for the development of the MySQL architecture.

When we're developing MySQL at Oracle we have a long-term view on the development, we've taken a lot of steps to make the code more modular. This means more work in developing a feature from a short-term point of view, but it pays back very quickly. As an example of this we did rearchitect the meta-data locking model in MySQL over a period of almost 5 years. Due to this rearchitecting effort we were able in MySQL 5.6 to split one of the crucial locks in the MySQL Server, the LOCK_open. This meant payback time as this improved our top performance of more than 100% with one small incremental step.

The principal idea is that new areas of development we try to put into separate modules which are as independent as possible from the rest of the MySQL Server code. Old code cannot be modularised in one swift move, this code has to be improved upon in small reengineering steps. Eventually those steps lead into more modularity and easier changability also of the old code base. We expect to continuosly improve the MySQL architecture in this manner.

Does this work benefit the entire MySQL community. Yes, modular code is the very foundation for successful open source code development also by the MySQL community. MySQL has a thriving development community, we expect it to thrive even more by the improved modularity we add to the MySQL code base.

#2 We have an improved development model
One of the first things I got engaged in 2007 when I was assigned to Senior MySQL Architect was to improve the MySQL development model. Previously we had a model where features were developed as projects and then pushed to the next release branch, often new features were pushed in several steps. This model had issues in quality and in development speed. This model often led to prioritisation issues when coming close to GA releases and often code was pushed very close to GA releases without proper quality. After MySQL was acquired by Sun and Oracle we have managed to get this under control using a new development model.

In the new development model we wanted to ensure that we took small steps forward (called milestone releases), always with retained quality. So in the new model we develop in 3-6 month steps, each step is quality assured and we use a lot of QA resources to ensure each milestone release is ok from a quality point of view. Some of these milestone releases are then taken out to become new GA releases. The GA releases are then put into our QA grind from where most bugs are squeezed out of the code.

We introduced this new model in 2009, it affected positively the MySQL 5.5 development and MySQL 5.6 has been completely developed according to this model. One only needs to look at what we achieved with MySQL 5.6 to understand that the new model works very well. We're continuing to use this model for new steps in the MySQL development.

The model is described in http://dev.mysql.com/doc/mysql-development-cycle/en/index.html

Our MySQL development is divided into a number of parts, we have a team taking care of InnoDB, another team taking care of MySQL Cluster (with the NDB storage engine), one team dealing with partitioning, an optimizer team, a replication team, a runtime team taking care of things such as metadata handling and other things related to query execution and a general team taking care of support code, networking, client code.

We also have teams handling MySQL Connectors, utilities and other things needed around the MySQL Server. There is also a performance and architecture team focusing on scalability, special projects and all sorts of improvements to ensure that our users get a good experience of using MySQL. Naturally we also have teams focusing entirely on the quality of the code. We have also a separate team working on MySQL Workbench and related tools to support MySQL management and development.

#3 We have great performance experts for the MySQL development
The community has lots of performance experts that understand how to help users in getting the best out of a MySQL Server. The community also has a number of people that are able to pinpoint performance issues in the MySQL Server. The patches these people develop are very useful in showing what can be improved in the MySQL codebase. The community is here very useful to the development of the MySQL Server. In this area we see a very good cooperation between our developers and the MySQL community developers.

We have also been able to do numerous performance improvements independent through the combination of MySQL experts and InnoDB experts that we have internally in Oracle. If you need proof of this just go to the MySQL 5.6 page and see demonstrated performance improvements we've done in MySQL compared to MySQL 5.5. This is an area I have contributed a lot to personally and I find it interesting how we managed to increase scaling of the MySQL Servers from 4 CPU threads to almost 64 CPU threads in just a few years.

#4 We continously develop MySQL partitioning
We continously improve scalability of our partitioning solution and integrate it further into the main storage engines as evidenced by the new set of partitioning features in MySQL 5.6.

#5 We have the most serious QA team in the MySQL world
Through the use of a large QA team we do our best to ensure that our community users are shielded from bugs in our released code. We also work with the community through milestone releases, lab releases and RC releases to ensure that our GA releases have top notch quality. We tripled the size of the QA teams as part of the MySQL 5.6 development.

Anyone can of course add new features to these MySQL trees, but it will be the community that mainly becomes the QA team for these additional features. We strive hard to ensure that our community users are shielded from being our QA team.

Although the MySQL is continously growing, the code coverage of our tests has continously improved going from MySQL 5.1 to MySQL 5.6.

#6 We are continously developing InnoDB inside Oracle
The major storage engine for MySQL is InnoDB, the InnoDB developers are also located within Oracle. We've seen many great benefits of being together inside the same company. This means that we can integrate InnoDB even better and improve scalability and functionality than ever before.

#7 We have a thriving MySQL Cluster development in Oracle
All MySQL Cluster development currently happens inside Oracle. I am still very much involved in this development and I sit next to a number of the key Cluster developers in my office in Stockholm with a beatiful view over the Stockholm City centre. We have shown magnitude improvements in scalability, performance per node and so forth in a regular and steady development. MySQL Cluster even has the capability to execute parallel queries as of version 7.2.

#8 We are making great efforts to make MySQL manageable
Many community developments are centered around getting more access to internal statistics about MySQL Server behaviour. Since a few years back we have a focused effort in this area to provide anything that a user could be interested in through the performance schema tables. These tables gather data internally and provide access to this statistical data through a set of performance schema tables. This effort is continuing, there is still more work to be done in this area.

#9 We have the largest and best optimizer team in the MySQL world
Our team of optimizer developers consists of developers that have loads of experience on developing DBMSs. Many of the developers have a background in developing SQL databases in the past and also have a scholar background which is almost a requirement to understand the fairly complex optimizer algorithms required in a relational DBMS. The team has made a tremendous effort in preparing a load of new optimizer features for MySQL 5.6.

#10 A thriving team working on MySQL Replication
The MySQL success have always been closely intertwined with the ability to replicate between MySQL servers using the master-slave model. The requirements on better failover capabilities and manageability of large sharded environments have led to an ever increasing set of new functionality in the replication area. We're continuing this development and working to provide even more functionality for the MySQL community that will be useful in building large MySQL installations.

#11 We have many other teams
The runtime team is doing a lot of work on handling metadata changes online, making the MySQL Server more scalable and making the server more modular.

The general team is ensuring that MySQL becomes more modular, ensuring that our support code is further developed, ensuring that we also have more unit tests on our code.

We have a thriving utilities team that is developing various tools useful for people managing MySQL Servers.

Each of the teams mentioned above have developed a great number of new features in the respective MySQL versions making it quite clear that MySQL development is thriving as never before.

So if you're looking for a MySQL version to use that have the best performance, the best stability and the most future-proof code base, then use MySQL 5.6.

The MySQL community continues to be an interesting place to work in. Oracle leads the development of new MySQL versions, we have a number of large companies that are building massive infrastructure components based on MySQL (Google, Facebook, Twitter and so forth) and we have a number of forks that also develops their own versions. There is also many new interesting requirements on MySQL to behave well also in a highly scalable environment and this requires even more work to be done on the MySQL replication architecture.

As a MySQL architect I am able to work with many parts of the MySQL engineering organisation and also the MySQL support organisation. There is a lot of interesting work going on that will continue to increase the use cases of MySQL for the MySQL community. So my work continues to be interesting and it's very rewarding to develop new functionality knowing that it will be used by many organisations in the world.

When I tell my kids or their friends about my work I tell them that I work on things that makes their computer games continue to tick since this is what most kids care about in the IT community. Personally I find it even more interesting the use cases for genealogy and other cool stuff.
PlanetMySQL Voting: Vote UP / Vote DOWN

With this version, the source code is now freely available under the GPL License v2. For more details, see our blog here. Open source pioneer Mozilla has been using TokuDB to manage its MySQL-driven Datazilla Data cluster, an open-source system for managing and visualizing performance data.

Date: May 2nd
Time: 2 PM EST / 11 AM PST
REGISTER TODAY

In the past TokuDB has been free for evaluation; the new TokuDB Community Edition extends free use to deployed environments. With this release Tokutek is also planning on making available a TokuDB Enterprise Edition, which includes technical support, initial customer onboarding services, and advanced tools for backup and recovery.

We look forward to having you join the webinar.

About the Presenters

Martín Farach-Colton is the Co-founder & Chief Technology Officer at Tokutek. Prof. Farach-Colton is an expert in algorithmic and information retrieval. He was an early employee at Google, where he worked on improving performance of the Web Crawl and where he developed the prototype for the AdSense system. Prof. Farach-Colton is also a Professor of Computer Science at Rutgers University.

Gerry Narvaja leads Technical Services at Tokutek. Gerry has spent more than 25 years in the software industry, most of them working with databases for different kinds of applications, from embedded to large-scale web products. Gerry worked first at MySQL, and then Sun Microsystems supporting the Sales teams. In 2008 he transitioned into being a Senior MySQL DBA. For over a year he has been co-hosting the popular MySQL Community podcast, OurSQL, which was given the MySQL Community Contributor of the Year 2012 award at the recent Percona MySQL Users Conference.

PlanetMySQL Voting: Vote UP / Vote DOWN

The Percona Live MySQL Conference & Expo 2013 was April 22-25 in Santa Clara, California. This was Percona’s second year organizing the conference and we were very pleased with the event and the feedback (check the #perconalive hashtag for a sampling of the great comments such as this from Tom Krouper or this from John Goulah or this from Jeremy Tinley or this from SF MySQL Meetup).

There are so many people involved with putting on this event that it’s impossible to list them all. The conference would be meaningless, though, without great content. Our heartfelt appreciation goes out to all of the great keynote, tutorial, and breakout session speakers who presented insights into MySQL and MySQL-related technologies in over 110 sessions across four days. Special thanks go to our Conference Committee and, in particular, to the Committee Chair, Shlomi Noach, for working through over 300 submissions to create the final agenda of tutorials and breakout sessions.

I particularly enjoyed the Percona Live MySQL Conference keynote presentations this year. I heard very positive comments on the sponsor sessions including the talks from Simone Brunozzi from Amazon Web Services, Robert Hodges from Continuent, Brian Aker from HP Cloud Services, and Peter Zaitsev from Percona and the keynote panel on MySQL 5.6 and the future of MySQL in the cloud with all of these speakers as panelists.

I found the invited keynote presentations from Tomas Ulin of Oracle and Matt Aslett of 451 Research very insightful. My major takeaways from those talks were:

• Oracle is investing a tremendous amount of time and energy into development of MySQL with an engineering team of over 200 developers
• The release process is more agile, predictable, and effective than ever before thanks to adoption of the Oracle development discipline
• MySQL 5.0 and 5.1 were rushed and not properly tested but 5.5 and 5.6 were significantly improved and 5.7 promises to be more of the same

• The future for the MySQL community remains bright with a total projected market size of nearly US$1 billion within the next few years despite the buzz created by NoSQL alternatives
• Despite the buzz, MySQL is still much more common than even the most popular NoSQL database when viewing indicators such as inclusion in LinkedIn bios
• Oracle MySQL may diminish in importance within the ecosystem as alternatives including Percona Server and MariaDB grow in relevance

I invite you to read Matt Aslett’s summary of 451 Research’s database survey by viewing the research report “451 Research database survey points to MySQL gravitational tug of war” on the 451 Research website.

Peter Zaitsev kicks off the Percona Live conference with his keynote, “Our ever-evolving MySQL ecosystem.”

Unlike last year, Oracle sent both executives and technical staff to the conference so it included all significant MySQL server development teams (Oracle, Percona, & MariaDB). The Percona Live MySQL Conference was a gathering place for the entire MySQL community with the industry thought leaders presenting insights on technology, the market, and the community in a cooperative atmosphere. We run Percona Live MySQL conferences to bring together all MySQL users, vendors, and technologies. This was the first of what I hope are many such events where all members of the community, including Oracle, come together and connect.

If you could not attend the Percona Live MySQL Conference, there are a few options for accessing the conference content:

• Visit the Percona Live MySQL Conference & Expo 2013 website and go to the individual session descriptions to download the speaker slides (we depend on the speakers to provide their slides following the conference so please check in a few days if the slides you would like to access are not yet available)
• Visit the conference website and go to the individual keynote descriptions to watch the session recordings
• To access all of the currently available slides from one web page, visit the conference website and complete the Sessions Slides form
• To view all of the keynote recordings on a single web page, complete the Keynotes Recordings form
• To view the keynote recordings without slides, visit the Percona MySQL YouTube channel (please visit the channel often as we will be posting webinar recordings to this channel going forward as well)

As with last year, the Wednesday night Community Networking Reception was a highlight of the conference. A hearty congratulations go out to all of the MySQL Community Awards winners with a special thanks to Henrik Ingo and Shlomi Noach for running the awards program. The Lightning Talks ranged from informative to very entertaining – thanks to Guiseppe Maxia for acting as MC.

Special thanks go to our Director of Conferences, Kortney Runyan, for her monumental efforts organizing the event. Kortney could not have succeeded without the support of our multiple service vendors including Ireland Presentations, Carleson Production Group, Tricord, the Hyatt Santa Clara, and the Santa Clara Convention Center, to name just a few.

Please mark your calendars now for two upcoming Percona Live events. Percona Live London 2013 will be November 11-12 at the Millenium Gloucester Conference Center. The Percona Live MySQL Conference and Expo 2014 will begin on March 31, 2014 at the Santa Clara Convention Center and Hyatt Santa Clara. Watch for the call for papers for Percona Live London.

The post Percona Live MySQL Conference 2013 wrap-up appeared first on MySQL Performance Blog.

PlanetMySQL Voting: Vote UP / Vote DOWN

Those who are familiar with me know I've a dream.

5 years ago I decided to leave a systems integrator where I was doing great. Why? I wanted to be in a company with the same growth prospects that Oracle had in the 80s. I dreamed to be in the Oracle of 30 years ago and, as time travel wasn't affordable, I decided to join MySQL AB to help expand the business in Europe, the Middle East and Africa.
A few years later my dream came true, but in a slightly different sense. Sun acquired MySQL and was later swallowed by Oracle giving me the opportunity to join the company I wished I could have helped build.

Oracle is an amazing company and the MySQL family is full of energy and passion. The product is much better now and the opportunities are even more. MySQL is a dream that I've proudly been part of, but I decided to move on to a new adventure to keep the energy, commitment and passion that are part of me. That's why I decided to leave Oracle.

I've joined an outstanding company, with a leading solution and huge growth prospects. A company that could become the size of Oracle in less than 30 years. I'll be working with a product sitting at the intersection of Cloud, Mobile and Big Data. A document database that will shape the technology landscape in the years to come.

With an attractive partner program and a shiny new version of MongoDB just launched, it's the right time for me to join 10gen. I've accepted the exciting challenge of building the ecosystem and work with software, hardware, cloud, services and channel partners to make MongoDB the de-facto standard NoSQL database.

Interested in a partnership with 10gen? Let's talk! Reach out to me via LinkedIn or firstname.lastname at 10gen.com. ;)

My new dream starts today, and today is the time to say Thank You! to all friends, colleagues, customers and users who made the MySQL journey a great one. I look forward to working with all of you again in the future.

All the best!
PlanetMySQL Voting: Vote UP / Vote DOWN

 

No need to say that as many others I have enjoy this conference a lot.

For me was also a personal success because I was finally able to have my company sponsoring the event and bring new members of my team to the conference as speakers, obviously all their merit, but I was happy as responsible of the MySQL cluster in Pythian knowing how much have cost to them to be there.

 

We also had a lot of people at the community dinner, last head count I did was over 120 people. In this regard I have to clarify some misunderstanding and confusion we had there.

Pedro’s requests to us to have the last head count by Tuesday morning, given that I have closed the count from the comments in the web-site and from the emails around noon.  The number I pass to Pedro’s base on that was of 70-80 people, but we had additional people registering after that time and also last moment show, given that we have to manage additional 40 people that has to be located in different areas.  Quite obvious that I did not give clear enough instructions, I personally apology for that, I (we) will do better next year. I hope you had good time and good food also if a little bit detach from the other tables.

 

What about the conference?

My feeling is that this event consolidates what is the “core” of the MySQL community.

We have seen many companies providing the same service, one close to the other sitting and talking with positive spirit and attitude.  I have been personally chatting all the time with people from SkySQL, Percona and others, all of us with open and friendly attitude.

I have seen Oracle people participate to the conference (hurray!!!), as IOUG committee member I know very well the number of time we have said to Oracle to be there, and they were! This was good, period.

 

MySQL where are you going?

In relation of what is happening to MySQL, and where is that leading us, I have confirm my idea that nowadays we are not talking anymore of LAMP or Full stack, when we talk about MySQL.

What customers, companies and users are expecting is a more complex and articulate environment. Interaction between different blocks is now not an optional but a fact.

When we approach an existing environment or when we have to build a new one, we now think in term of hundreds of application servers, terabytes of data to store or to process, many different client platform to support and impressive amount of data to analyze for reporting.

 

Feel free to fill the boxes with the name of the product that you like most, but for sure you will not limit yourself to MySQL or LAMP.

Already today I have customers using MySQL, Oracle Database, MongoDB, Hadoop and more, all in one single connected environment.

 

Thinking in term of MySQL only when we think to product, service, monitoring or design is too limitative.

 

For instance a tools that monitor MySQL but do not catch his interaction with other element like Hadoop, is going to provide only part of the picture. That partial picture referring only to MySQL metrics will be close to be useless because it will not be able to provide all the require information needed to perform a valid analysis and eventually projection.

In other terms will cover the basic of the single block and will not help us to get the big picture. That is it, still useful to keep the block in decent state but will let you blind for what is going on in the whole context.

This is for many aspects true also for the products, each block, MySQL included, must become more and more flexible to exchange data with the others. This can be achieve developing specific interfaces, or by defining a common protocol/format of communication that is shared between the different blocks.

 

In MySQL universe (or MariaDB), this also means to keep consistency and to remain as open as possible to facilitate the creation of additional plug-in/engines.

But what really worries me, given also is “my” field, is “service”. Those environments require support, design and so on. We know very well how complex a MySQL environment could be, what about it when we start to have many other actors involve? What really scares me is the level of knowledge is required to cover all of them or just a segment.

I am convince that we will have to work around it, because users/customers/companies will ask us to provide the support for all the element in their architecture, actually it is already happening, and the real risk is to have or become generalist instead of high profile experts.

 

If you don’t do it, if you do not differentiate, the risk is to be isolate by the market, and yes be very smart on that specific area, but not able to understand the big picture, ergo useless.

On the other hand, trying to do too much could drives you (as company) to disperse the resource and have an average level, that is good but not Excellent with capital “E”.

The possible solution is to have a huge monster with hundred and hundred of people, and division per technology … and … well I have seen already several of them starting and die. Starting good with very high service quality and then become big, heavy and so slow that customers moves out.

 

No that is not the solution, solution reside in being able to balance correctly what you can do with your resources, and reasonable growth, and what not.

I am working in a multi technology company, and I know very well of what I am talking about when I say that balance is the key.  The future will need to see two things: one is the companies improving their capacity to cover more then just MySQL, the other is open the space to collaboration, company covering different technologies must start to interact more, and offer better service and results to the users/customers in a cooperative way.

That will allow the single company to remain focus on few things and keep a high level of expertise on the chosen areas. Working in a cooperative way is the key.

All this needs to happen, and require coordination.

 

Flexibility and coordination are the keywords for the future. The MySQL community have shown already how much energy it has, how strong it could be in difficult moment and how much we really care about our customer/users.

What I see for the future is us working all together gathering all the actors involve, and give life to a new ecosystem which will help to facilitate the evolution of the next generation of data and applications.

 

What about the Speeches

In term of talks I have to say I was expecting a little bit more, not from the speakers only (me included), but also from the product companies.

As said I think is time to move to the next step and I was expecting more talks about interactions between technologies.

 

I am not saying that we should not cover the base; we must do it, but having more talks on how MySQL and MongoDB coexist, or how we could help Terabytes of data to be process between A and B; well that would have be nice.

Not only as what we have now, but also what we are planning for the future, including new features and ideas for the development.

 

In this regards the only relevant speeches I have seen were, the ones done by my colleague Danil Zburivsky on Hadoop/MySQL , and the other about Json by Anders Karlsson during the MariaDB/SkySQL event.

Thanks guys you see the future, and shame on Marco that was thinking about it and could have done it but did not … may be for the next conference.

 

Said that, the level of the speeches was good, I have being talking with the people attending, most of them satisfy, but let us wait and see what the evaluations will reveal.

What I can say is that I really enjoy the tutorial on Xtradb and Galera done by Jay Janssen, that helps me to feel less alone in the Galera implementation adventure; and I regret to have miss the “InnoDB: A journey to the core” by Davi Arnaut  and Jeremy Cole. But I was presenting at the same slot, and would have not be nice for me to say to the people there, ok let us move all to the next room.

 

What about the Expo

WoooW, first time as sponsor and first time with a boot. A lot of talk, a lot of possible new friends and a better understanding on what we need to do to be more effective next time. T-shirts first!!! Lesson learned we bring to few … we could have cover all the bay area with LOVE YOUR DATA, we miss the target this year, we will not do the same the next one.

 

I think that this year we had a well-balanced expo, with less show, but more focus, I must also mention the presence outside the expo area of  Julian Cash (http://jceventphoto.com/index.html), which takes a lot of cool shot of most of us.

I know Julian was there also during other conferences but I never met him before. I did this year and was a great experience, I hate to takes photos but with Julian I was having so much fun that at the end I love it.

 

What about the Lightening Talks?

Another well establish event at MySQL conference, and every year we have fun. This year I have enjoy the Shlomi one, and absolutely AWSOME was the performance from the Tokutek team.

 

About the Lightening talks and just to confirm what Dave Apgar was saying in his really good presentation, shit happens and you never know when. I had place my video camera and register the WHOLE event, and guess what… my new SD card just failed, and nothing I mean NOTHING was there after. Next time I will come with TWO video cameras and will setup redundancy!

 

Announcements

Finally during the conference we had two very significant announcements.

The first one was the expected merge of MariaDB and SkySQL, nothing new, but it is good to see that SkySQL is defining his identity with more determination, but not only this merge is very important because all MariaDB users now have a clear referring point, that will hep them and the community to better adopt and improve MariaDB. Way to go guys well done!

 

The second one is about Tokutek (http://www.tokutek.com/), finally open source. I have tested it the first time 3 years ago, and was a very interesting technology, but hard to have implemented because customers where reluctant to go for non-open source code.

Just a note, I wrote open source, not free. Open source doesn’t mean free, and here the concept was very clear, customers were willing to “eventually” pay, but not for close code.

Tokutek move is not only smart because will allow the company to have substantial help from the community in identify issues, improve utilization and identify new trends, but it is smart also because remove the last philosophical barrier in the software adoption.

 

From the technical point of view, the presentations have shown a significant improvement in respect to the previous years, and I was very impress from the presentation done by Gerry Narvaja during the SkySQL/MariaDB event.

One thing is sure, I have customers that could take huge benefit from Tokutek and I will give a try right away starting next week.

 

Winner and looser

No doubt from my side, I was not even mentioning before because for me is a given.

On the 12 of March 2011 I have written this article http://www.tusacentral.net/joomla/index.php/mysql-blogs/96-a-dream-on-mysql-parallel-replication, which was my dream about replication. At the time of writing I was not aware/testing ANY software able to do what I was asking.

On the 23 November 2011 I wrote another article http://www.tusacentral.net/joomla/index.php/mysql-blogs/119-galera-on-red-hat-is-123-part-1, and that was my first approach with Galera.

On the 29 September 2012 I have presented the first results of a POC done on customer environment http://www.slideshare.net/marcotusa/scaling-with-sync-replication-2012.

Next week, I must implement another MySQL Cluster, base on Galera replication.

 

The winner for me is the Galera solution (http://www.codership.com/), whatever version you may like; from my side I have found that the Percona version is the more stable, and using the Severalnines tool to manage the cluster (http://www.severalnines.com/clustercontrol) is also helpful.

 

 

Who is the looser then?

All the ones that have believe MySQL was over on the 2010 (Oracle take over).

We have MySQL from Oracle, we have MariaDB from Monty, we have companies developing their storage engines and tools, we have a more complex ecosystem that is growing day by day.

No MySQL is not over at all.

One note only, whoever leads the development from any side, reminds that you MUST allow the community to use and develop code on top of yours, modify interfaces without documenting, or not be fully explicit on what to do, how to do, and which direction, well it is not fair.

Percona Live, MySQL Conference in Santa Clara was a great conference, done by great people. We can do better all of us, always, but what makes me feel good is that I know we will do better next year.

 

Last note…

Did not you miss some one? Did you as I did, feel as that something was not right? Was not a face missed?

I mean … yes! He! Baron Schwartz!!  Hey man we miss you!!! Or at list I miss you and your block notes during the presentations, come back ASAP.

 

Happy MySQL to everyone.

 

References

http://www.codership.com/

http://www.severalnines.com/

http://jceventphoto.com/index.html

https://www.percona.com/live/mysql-conference-2013/

http://www.tokutek.com/

http://www.skysql.com/

http://www.pythian.com/

https://vividcortex.com

And more ...

 

{joscommentenable}

PlanetMySQL Voting: Vote UP / Vote DOWN

As Stewart mentioned in in post where-are-they-now-mysql-storage-engines : “Federated It’s still there… but is effectively unmaintained and dead. There’s even FederatedX in MariaDB which is an improvement, but still, the MySQL server really doesn’t lend itself kindly to this type of engine… it’s always been an oddity only suitable for very specific tasks.”

The CONNECT [...]
PlanetMySQL Voting: Vote UP / Vote DOWN

Here are a few questions remained open for me from Percona Live 2013 about things that have been said during keynotes; I will appreciate a discussion on comments. Here goes:

Question #1

Brian Aker (HP) asks Simone Brunozzi (Amazon) what the underlying technology for DynamoDB is. Simone says can't disclose. Brian says: "it's MySQL!!". Simone says: "can't disclose". Brian insists: "it's MySQL!!"

Seriously? I will be very much surprised to learn that DynamoDB uses MySQL; it doesn't make sense to me. Why would Brian Aker say that though? Did he just mean to tease Simone or is there something I just don't get?

(Yes, Brian?)

Question #2

Matt Aslett speaks about adoption of MySQL & variants, and expected adoption in next years, Mentions MariaDB, Percona Server, SkySQL. KEeps saying how the SkySQL server gets more traction.

What does he mean? There's no SkySQL fork; does he mean SkySQL cloud offer? Or just SkySQL support services, typically for MariaDB variant? But in that case, SkySQL is out of context. What's going on?

Question #3

Matt Aslett presents quite pessimistic prediction for MySQL. Reduced popularity in next years. Relatively good news for MontyProgram/MariaDB; otherwise a lot of switch-off to PostgreSQL, poor adoption for Continuent, low ratios of "evaluation" to "adoption" of technologies; really quite depressing. Later mentions at about 200+ questionnaires.

I don't have a special interest here as I don't work for any mentioned company; other than my general desire to see the ecosystem flourishing.

Are 200+ people enough to both give a faithful picture of current MySQL usage and adoption? Are they enough for prediction 1 year into the future? 4 years into the future?

In Israel, with less than 8M population, election surveys usually look at 500+ people. To me it doesn't sound a lot, but statistics is not my strong skill. However those picked for the survey have to be a diverse population, distributed in similar ratio to overall population (so Jews, Muslims, Christians, Orthodox, income level, geographic location, etc.).

Does the same happen with those 200+ questionnaires in the 451 research? The reason I ask is this: at the end of keynote Matt says: "if you want your voice to be heard, if you think differently, contact me, and I'll add you to our survey". Does this mean anyone stepping up is included? Great, so a hypothetical company called GalleriaDB would encourage its 50 employees to enlist, thereby completely shifting the balance.

Who are those 200+ people in the survey? World wide known experts? Your regular DBA? Your remote DBA consultant? Your web developer? Do they represent the overall MySQL ecosystem population? Do their insights into the future collide with those of everyone?

Please discuss below
PlanetMySQL Voting: Vote UP / Vote DOWN

common_schema booth in Percona Live 2013 (someone left their soup on our table)

Allen Kinnard

Yay! I got a booth!

I confess it was mostly deserted. My hero Allen Kinnard, whom I've never met before, was kind enough to volunteer to occupy the booth.
So between him and me, both of course also looking to visit other booths and talk to people, the common_schema booth was only moderately attended.

Well, this was the DotOrg Pavilion: free booths for free & open source projects (e.g. OpenStack, PhpMyAdmin, etc.).
We both did our best to explain common_schema to the visitors.

The booth was actually titled "common_schema & openark-kit". However I don't recall that anyone asked me about openark-kit. Most were just interested in what common_schema was. I get that openark-kit is well known by now to many.

We did not have so many visitors, which played well with our occasional absence. But this was a last moment arrangement. In future events I may try to get things on top and have an army of volunteers to help me out (and I hope that by next time common_schema is widely used).

Now for the criminal department: practically all other DotOrg booths came prepared, with printed material, giveaway stuff and the like. We were like way beyond "the minimalist". We were "the poor and the pitiful". So I asked Kortney if she could arrange me some decorations (pulling some strings - yeah!). We were thinking a bowl of candies or something. Eventually she brought a few dozen candies (no bowl) and laid them nicely on the table; very nice touch! Good mixture of colors, nice wave design.

And guess what? Visitors actually thought they may take one of our candies! Oh, I schooled them.
But on Wednesday, when we arrived to the booth, a horrid sight stroke us: someone stole (and probably ate) 80% of our candies!
Well, I hope you've got bellyache, and next time you should know there will be surveillance, candy-thief!

PlanetMySQL Voting: Vote UP / Vote DOWN