Новости « PlanetMysql.ru — информация о СУБД MySQL

Archive for the ‘Новости’ Category

Partitioning MySQL database with high load solutions

Ноябрь 19th, 2010

We need to test if MySQL can be reliable with huge data sets, talking of a daily waterfall of about 30 million INSERTs and a few daily analityc big SELECTs too.
So what's the deal ? which database engine ? which platform ? which architecture ? ... and is data secured ? accessible ?
Before choosing MySQL 5.1, i turned around these three databases:

Oracle :
Known as the 'most reliable' database engine in the world, personally i don't believe in that, and i didn't choose it for its cost (Especially that :) ).
PostgreSQL :
A good database engine, it succeeded where older than 5.0 versions of MySQL failed, but now, both engines are mature enough and i'm switching between them on every new projects depending on the specific needs of each project architectures.
Switching between database engines should be a simple task when the application deploys an abstraction layer on the database.
So why not PostgreSQL for this project ?
1. PostgreSQL (the latest stable version to this day) still lacks on partitioning and provide very basic features compared to what MySQL do.
2. As i know, PostgreSQL has no 'enterprise' version and no paid support, with mission critical projects, we cant rely on the community respondness to resolve issues, we need enterprise-level SLA.
MySQL 5.1
Refering to the new features list of the 5.1 version of MySQL, i felt in love with it.
Good partitioning (and sub-partitioning), better replication engine .. and the 'enterprise' version is making us comfortable with critical-mission applications.

As for scalability, making a database respond in less than 1 second when stressed with up to 2000 INSERT/sec throughput (with TRIGGER) does not rely on System sizing and Database engine only, these things wont scale if the design is poorly done.

Let's dive into the blue:
We have a sell reporting analytic application, we have about 20 million sells per day, each selling action has a Seller and a Buyer as long as the date and the amount of the bill.
The informations are provided in flat text files, so we use Talend ETL to load the data to the database.
On the output side, we need to get a fast access to these informations:

(1) Best sellers of each day having total amount of sells more than a defined limit. (Using the sum of the billing amounts of the day)
(2) Occasionally fetch selling details of a Seller for a specific period.

I've deployed two tables, the first is for delivering best sellers/buyers informations (1), the second is for the selling details (2).
Here's the first one:

CREATE TABLE `transaction` (
`seller` int(11) DEFAULT NULL,
`buyer` int(11) DEFAULT NULL,
`amount` decimal(5,2) DEFAULT 0,
`sell_date` date DEFAULT NULL,
`sell_time` time DEFAULT NULL,
PRIMARY KEY(`seller`, `buyer`, `sell_date`, `time`)
) ENGINE=InnoDB
PARTITION BY RANGE ( MONTH(`sell_date`))
SUBPARTITION BY HASH ( `seller` div 1000000)
SUBPARTITIONS 10
(
PARTITION p1 VALUES LESS THAN (1) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (2) ENGINE = InnoDB,
PARTITION p3 VALUES LESS THAN (3) ENGINE = InnoDB,
PARTITION p4 VALUES LESS THAN (4) ENGINE = InnoDB,
PARTITION p5 VALUES LESS THAN (5) ENGINE = InnoDB,
PARTITION p6 VALUES LESS THAN (6) ENGINE = InnoDB,
PARTITION p7 VALUES LESS THAN (7) ENGINE = InnoDB,
PARTITION p8 VALUES LESS THAN (8) ENGINE = InnoDB,
PARTITION p9 VALUES LESS THAN (9) ENGINE = InnoDB,
PARTITION p10 VALUES LESS THAN (10) ENGINE = InnoDB,
PARTITION p11 VALUES LESS THAN (11) ENGINE = InnoDB,
PARTITION p12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB
);

This table will contain the sell transactions, I've made partitioning by seller and month of the transaction in the way to facilitate queries for selling details for a specific seller and period: (2).

Here's the second one (dedicated to queries fetching best sellers of each day (1)):

CREATE TABLE `daily_sell_amount_summary` (
`seller` int(11) DEFAULT NULL,
`amount_summary` decimal(5,2) DEFAULT 0,
`summary_date` date DEFAULT NULL,
PRIMARY KEY(`seller`, `summary_date`)
) ENGINE=InnoDB
PARTITION BY RANGE ( DAY(`summary_date`) )
SUBPARTITION BY HASH (   `seller` div 1000000 )
SUBPARTITIONS 10
(
PARTITION p_day_of_year_1 VALUES LESS THAN (1) ENGINE = InnoDB,
PARTITION p_day_of_year_2 VALUES LESS THAN (2) ENGINE = InnoDB,
PARTITION p_day_of_year_3 VALUES LESS THAN (3) ENGINE = InnoDB,
PARTITION p_day_of_year_4 VALUES LESS THAN (4) ENGINE = InnoDB,
PARTITION p_day_of_year_5 VALUES LESS THAN (5) ENGINE = InnoDB,
PARTITION p_day_of_year_6 VALUES LESS THAN (6) ENGINE = InnoDB,
PARTITION p_day_of_year_7 VALUES LESS THAN (7) ENGINE = InnoDB,
PARTITION p_day_of_year_8 VALUES LESS THAN (8) ENGINE = InnoDB,
PARTITION p_day_of_year_9 VALUES LESS THAN (9) ENGINE = InnoDB,
PARTITION p_day_of_year_10 VALUES LESS THAN (10) ENGINE = InnoDB,
PARTITION p_day_of_year_11 VALUES LESS THAN (11) ENGINE = InnoDB,
PARTITION p_day_of_year_12 VALUES LESS THAN (12) ENGINE = InnoDB,
PARTITION p_day_of_year_13 VALUES LESS THAN (13) ENGINE = InnoDB,
PARTITION p_day_of_year_14 VALUES LESS THAN (14) ENGINE = InnoDB,
PARTITION p_day_of_year_15 VALUES LESS THAN (15) ENGINE = InnoDB,
PARTITION p_day_of_year_16 VALUES LESS THAN (16) ENGINE = InnoDB,
PARTITION p_day_of_year_17 VALUES LESS THAN (17) ENGINE = InnoDB,
PARTITION p_day_of_year_18 VALUES LESS THAN (18) ENGINE = InnoDB,
PARTITION p_day_of_year_19 VALUES LESS THAN (19) ENGINE = InnoDB,
PARTITION p_day_of_year_20 VALUES LESS THAN (20) ENGINE = InnoDB,
PARTITION p_day_of_year_21 VALUES LESS THAN (21) ENGINE = InnoDB,
PARTITION p_day_of_year_22 VALUES LESS THAN (22) ENGINE = InnoDB,
PARTITION p_day_of_year_23 VALUES LESS THAN (23) ENGINE = InnoDB,
PARTITION p_day_of_year_24 VALUES LESS THAN (24) ENGINE = InnoDB,
PARTITION p_day_of_year_25 VALUES LESS THAN (25) ENGINE = InnoDB,
PARTITION p_day_of_year_26 VALUES LESS THAN (26) ENGINE = InnoDB,
PARTITION p_day_of_year_27 VALUES LESS THAN (27) ENGINE = InnoDB,
PARTITION p_day_of_year_28 VALUES LESS THAN (28) ENGINE = InnoDB,
PARTITION p_day_of_year_29 VALUES LESS THAN (29) ENGINE = InnoDB,
PARTITION p_day_of_year_30 VALUES LESS THAN (30) ENGINE = InnoDB,
PARTITION p_day_of_year_31 VALUES LESS THAN (31) ENGINE = InnoDB,
PARTITION p_day_of_year_rest VALUES LESS THAN MAXVALUE ENGINE = InnoDB
);

Having about 7 million active sellers per day, this table will contain the summary amounts of each seller, with partitioning based on the date column, we'll have each day in a single partition.
Sells older than 3 months are purged, we wont get data for more than 3 months, so a partition will contain a maximum of 3 days.

The table above is updated on each sell transaction, we use the TRIGGER below to get things done:

CREATE TRIGGER summarize_amount AFTER INSERT ON `transaction`
FOR EACH ROW BEGIN
INSERT INTO `daily_sell_amount_summary`(`seller`, `amount_summary`,  `summary_date`)
VALUES (NEW.`seller`, NEW.`amount`, 0, NEW.`sell_date`)
ON DUPLICATE KEY
UPDATE `amount_summary`=`amount_summary`+NEW.`amount`;
END;

Used hardware:

HP Itanium2 Double Core, 1.2Ghz each.
8GB RAM.
2 SCSI U320 15K Disks, 146Gb each (No RAID is set).
Linux Debian Etch

Some software tuning:

Multi-threaded ETL (with 10 concurrent MySQL connections).
Linux is installed on the first disk only (sdb1) with classic EXT3 filesystem.
InnoDB is lonely hosted on the second disk (sdb2) relying on an XFS filesystem.

Here's my MySQL configuration file:

[client]
port = 3306
socket = /tmp/mysql.sock

[mysqld]
skip-name-resolv
pid-file = /var/run/mysqld/mysqld.pid
datadir = /opt/database << This is XFS
port = 3306
socket = /tmp/mysql.sock
back_log = 50
bind-address = 0.0.0.0
max_connections = 100
max_connect_errors = 10
table_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 64M
query_cache_limit = 2M
ft_min_word_len = 4
#default_table_type = InnoDB
thread_stack = 192K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
log-bin=mysql-bin
long_query_time = 2
log_long_format

# *** For debugging purpose, but not for the prod.
log_slow_queries

# *** Replication related settings
server-id = 1

#*** MyISAM Specific options
key_buffer_size = 2048M
read_buffer_size = 1024M
read_rnd_buffer_size = 1024M
bulk_insert_buffer_size = 1024M
myisam_sort_buffer_size = 1024M
myisam_max_sort_file_size = 40G
myisam_max_extra_sort_file_size = 40G
myisam_repair_threads = 6
myisam_recover

# *** INNODB Specific options ***
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 6G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 0
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_log_group_home_dir = /opt/database << This is XFS
innodb_max_dirty_pages_pct = 90
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 120
innodb_file_per_table=1
innodb_log_group_home_dir = /opt/database/ << This is XFS
innodb_data_home_dir = /opt/database

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[myisamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 8192

MySQL was compiled with these options:

./configure --prefix=/usr/local/mysql --enable-assembler --with-plugin-partition --with-plugin-innobase --with-big-tables --with-mysqld-user=mysql --enable-large-files

Monitoring is done with Munin since it's very simple to install and has no heavy footprint on the system resources.

Results:
1. Reads:

Query:
SELECT seller, amount_summary FROM daily_sell_amount_summary WHERE summary_date='2008-05-10' AND amount_summary>1200;
Table has more than 60 million rows, and 6 million just for the summary_date='2008-05-10'.

Results are from 6 seconds to 22 seconds depending on the system load (sometimes i do SELECTs while my ETL is stressing the base with triggered INSERTs.

2. Writes:

Using multi-threaded Java ETL from Talend Open Studio.
The ETL is ran from my Laptop (Centrino Duo 1.7Ghz, 2Gigs Memory with Ubuntu 8.04)
Simple INSERTs in the transaction table, 10 concurrent threads are INSERTing.

Results:

MyISAM engine with one ETL thread gave us about 1200 INSERT/second.
InnoDB engine with one ETL thread gave us about 400 INSERT/second.
InnoDB engine with 10 threads ETL gave us around 1400 INSERT/second.

Here's the system monitoring charts for the last benchmark (3):

Some will ask why I've insisted on InnoDB engine when MyISAM did a higher performance, i should say that I'm sticking with it for Security and Concurrency, i think these worth the performance, especially with a mission-critical project.
InnoDB doesn't only lack with performance, hot backup is provided under paid license, no free tools to do hotbackuping, LVM snapshots are a solution for this.

You can get more power when hosting the database on a RAID 10 disk array, this will be covered in a later post, so stay tuned !

We provide MySQL consulting and engineering for robust and scalable solutions, don't hesitate to contact us if you need any of our professional services.

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

What information do you want in the binlog?

Ноябрь 18th, 2010

The MySQL task WL#4033 Informational Events includes adding information about the original query for row-based replication. This will make it easier to debug failures and user mistakes. It also makes it easier for us to add other information to the binary log. Is there some information missing that you think we should add to the binary log? Please feel free to comment on this blog entry or send me an email at firstname.lastname@oracle.com.

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

O’Grady’s Fear of Forking, Let a thousand flowers bloom

Ноябрь 16th, 2010

In the article "Fear of Forking" there was a quote pulled from me about my observations from a yearly call done by the folks at O'Reilly with many of the authors of different open source projects.

"On a related note there was a recent phone call that O’Reilly put together with a number of open source leads. It was amazing to hear how many folks on the call where terrified of how Github has lowered the bar for forking. Their fear being a loss of patches. It was crazy to listen too."

Since I made that comment, there is one new observation I have made. GitHUB has begun to feel like the Sourceforge of the distributed revision control world. It feels like it is littered with half started, never completed, or just never merged trees. If you can easily takes changes from the main tree, the incentive to have your tree merged back into the canonical tree is low.

I feel like you can look at it in either two ways.

If you count up all of the hours and energy going into abandoned trees then you begin to worry about "all of that wasted work". It takes a lot of effort to keep projects going, and if all new energy is focused in this direction I don't know that we can keep a sustainable amount of focus to produce the sort of software that we do today. While consulting this last year I've run into a number of shops where a developer has made changes to an open source project, and placed these into production without any vetting (and in most of these cases they had a github/launchpad/etc sort of tree, or they pulled from some random person's tree). They didn't use a released piece of software, and often the code they had used was just thrown over the wall by some devs in some other company. It is the "we hired a smart guy who tinkered with our debian distribution/kernel" problem all over again.

The other way to look at it, is that Github/Launchpad are today's Burgess Shale. We are in the equivalent of a cambrian explosion and the diversification we are seeing is similar to what we saw when Sourceforge first launched. If this is the case then we will see some stabilization in the next few years. In the database world, we are certainly in the middle of one of these periods.

If I put all of this into perspective and apply it to the MySQL Ecosystem, I fully believe that the forking we saw was enabled by the move to bzr/launchpad. Without that move it would have been a lot harder to make that shift for most of the forks and distributions (and I believe it has also slowed down the evolution of most, since almost all of the forks/distributions are heavily tied to downstream changes that Oracle makes). Beyond Drizzle, none of the other forks have any significant contributions, and they are all stuck waiting for Oracle to fix bugs for them and/or hoping that the changes they make don't conflict with what Oracle is doing.

In a related Ecosystem, I am eager to see what happens in the Postgres world now that they have moved to Git. As I have mentioned before, with Drizzle we could have started with Postgres as the foundation, and I believe there would have been a lot of benefit in doing so. I will be curious to see if anyone decides to see what they could do with the code if they take a radical departure from the current architecture. I am still happy with our choice of MySQL, but I believe there is an opportunity to do something pretty incredible with that codebase as well.

In the cloud world we have OpenStack, Canonical, and Eucalyptus all circling around the same problem and having a history of shared tools and code. It is going to be interesting to see what happens there as well.
PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

Remember ComputerLand?

Ноябрь 16th, 2010

It's soon time to celebrate 30 years of IBM PCs (They were first released in 1981, initially in the US and Canada). Before that, the microcomputer maket was much more diversified, but once IBM released the PC, most of what remained, after a few years, was the PC itself and Apple.

If you remember how it all started though, with the MITS Altair kits, you might also recall the biggest competitor to MITS, IMSAI. IMSAI, big as they were, died off by the early 1980's.

So then, what about the title of this blog? What the heck is ComputerLand? And amusement park? Nope, far from it. Actually, if you were in the US in 1981 and decided you wanted to buy a PC, you had few options of where to get one. Either one of the few Sears stores that had them, but those were very few, or ComputerLand. That was about it, for a while. And ComputerLand was big, real big! And they started growing even bigger, having something that was close to a monopoly on selling the PC was like a license to print your own money. And now they are all gone.

Well, there is a Franchise chain around called ComputerLand to this day, and they have been around a while, but they are not related to the original ComputerLand. And what about IMSAI? Well, Bill Millard, who founded IMSAI also founded ComputerLand. And as he was the person who screwed up IMSAI, he was also the person to screw up ComputerLand.

ComputerLand was an international Franchise chain of Computer stores, stocking just about every personal computer on the market initially. They were the first and went to become the biggest, but the whole operation eventually was killed of by internal battles (among the founders, among others, like Bruce Van Natta and Jack Killian who co-founded IMSAI, which in practice was drained from resources to found and build ComputerLand, of which they got from Millard: Nuthin')

The lesson is that don't think you can get away with just about anything, just because you did it once, history will eventually catch up with you. And although one may discuss of Millard was wrong, or if his intentions were wrong (I'm not so sure they were), but that he was weird and lost track of what was important from IMSAI and ComputerLand, that is pretty clear, in my mind.

By the way, do we still have hunger in the world? Or is World Hunger also History? One of Bill Millards projects that he was part of was to end World Hunger by year 2000. How? By raising consiousness! Oh, of course, why didn't I think of that. Nope, didn't work. But the intentions were good at least.

No, let's forget the old ComputerLand (they were sold and namechanged a few times, and finally went to sleep some 10 years ago or so) and remember the PC. The original clunky, 5 1/4 inch diskette thingy with 16K RAM. (yes, that was it in the original PC. 16K). At lease the PC survived and is with us today, although it didn't end world hunger. And we have something to run Linux and MySQL on! Thanx you, IBM!

/Karlsson

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

MariaDB 5.2 is released as stable

Ноябрь 16th, 2010

I am happy to announce that MariaDB 5.2.3 is now released as a stable release.

During the gamma period we did not receive any serious reports for issues in 5.2, so we are relatively confident that the new code is of decent quality.

You can read about the features of MariaDB 5.2 in my previous blog entry or in the fast growing MariaDB knowledgebase..

What is most interesting about MariaDB 5.2 is that most of the features came from the MariaDB/MySQL community, not from Monty Program Ab!

Without the community it would not have been possible to do a stable release so soon after the last release. Virtual columns, Extended User Statistics, Segmented MyISAM key cache, OQGRAPH and the Sphinx client are all from code provided by people outside of Monty Program Ab. Pluggable Authentication, Storage-engine-specific CREATE TABLE, Enhancements to INFORMATION SCHEMA.PLUGINS table and "Group commit" for the Aria engine were provided by us at Monty Program Ab.

Thanks also to all those who have reported and provided bug fixes for 5.1 and 5.2!

MariaDB 5.2.3 has all changes from MariaDB 5.1.50 and MySQL 5.1.51. (We are just about to release MariaDB 5.1.51)

Please report any issues to the MariaDB bugs database so that we can fix them!

We will continue to fix critical bugs in MariaDB 5.1, even if the
attention of bug fixes will now move to 5.2.

Now we are busy working on getting MariaDB 5.3 ready for beta. We have also started a merge of MariaDB 5.3 + MySQL 5.5 -> MariaDB 5.5 and hope to release this tree soon!

Happy database usage!

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

MySQL configuration management using Chef

Ноябрь 14th, 2010

Here at Recorded Future we use Chef for Configuration Management, and I am a complete newcomer to this. Chef is, like Puppet, built in Ruby, Ruby sure seems popular for Configuration Management things.

As for the so called "recipes", which is what Chef names a things used for installing some software package, such as MySQL, is really not complete in the case of MySQL at least, but that is really not a big deal. I actually am beginning to like Chef, there are many good points to it, although I can't escape the feeling that I am spending more time writing Ruby than actually installing stuff and getting MySQL running. But I beleive that this most a result of the fact that we are still a startup and do not yet have that many MySQL servers running.

I my opinion, and I can be pretty opinionated as you know, I think the one big thing with Chef that I do not like is Ruby. I have to admit I really have to work hard to get used the idiosycratic means that this language works in. Mind you, I'm no big fan of scriping languages in general, but I have written fair amounts of PHP, for example is most of my website papablues built by myself in PHP as Joomla modules, components, tmeplates and plugins.

In many way, I think Ruby started of pretty well, the basics of it are promissing. But the way they have complicated Object Orientation seems to me to be not just an overkill, but an overkill without really good uses. There are so many different means and syntaxes for the same thing that you just get confused. And then you do what I do. Learn one tecnique and use that (which means the code will be hard to read for someone using some other tecnique: Tough sh*t!)

That said, all this may be just because I'm not used to it. I used to hate PHP also, but sort of got used to it. But my one and only favourite lange remains C. Which you can learn by reading the thin "The C programming language", not 1000 pages of "Idiots introduction to the basics of PHP" or some similar utterly useless publication.

All this though, Chef is beginning to be fun, and I will share some more experiences with you regarding the Chef work we are doing here at recorded Future. Also, I was thinking that we should share some experiences with other MySQL Chefs, maybe as a BoF session at the upcoming MySQL UC (It can't be a full blown talk, the deadline for CFP is over).

Cheers for now
/Karlsson
Who sticks to his old way of working, even with Chef: Code should be commented! And yes, I am also aware I am old fashioned....

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

Taking off again, up high in the sky…

Ноябрь 11th, 2010

After my departure from Oracle, I received lots of emails and messages, people who asked me where I will land. Thanks to everybody for the kind words and the great comments. By the way, more than a landing, I am going to take off… :)

On October 29th I joined Ulf Sandberg, Kaj Arno and Mick Carney at SkySQL. I will lead the Field Services team in Europe, i. e. my team will help users and customers in designing and implementing solutions around the MySQL technology. This will be my main role but, as you may expect, in small companies (small compared to large Corporates like IBM or Oracle), you must wear many hats.

My long term goals have not changed: I want to serve the MySQL Community of users, developers and, of course, the SkySQL customers. I want to provide the best possible advise, the best services and solutions. I will be specifically focused on these aspects:

Continue to support MySQL as the de facto standard for online applications

MySQL is great for online applications, but it is far from being perfect. MySQL 5.5 and MariaDB 5.2 show significant improvements in terms of performance and scalability, more statistics and admin features. We are still a bit behind schedule with real improvements, like the adoption of new storage engines - specifically PBXT and more NoSQL-like engines.

Scout and implement solutions that will make MySQL really suitable for the Enterprise and ubiquitous in new areas

In one of my old posts I have explained the difference between the mindset of an Enteprise-focused IT Manager versus an IT team devoted to the cause of open source. Part of the work to do is based on evangelisation, but there are some technical aspects to cover as well. MySQL needs some extra features to be "Entperprise-ready". "Enterprise features" are not just sophisticated features, or "all the features you may think of". They are features that are necessary to sustain Enterprise software and tools. The debate around which features are necessary is meaningless, since every Enterprise is different. There is a set of features that is quite mainstream. In particular, we need to improve:

- Documents and Multimedia objects handling
- Security
- Analytical functions and large data analysis
- Data sharing and integration

These improvements are not necessarily related to deep changes in the server core. Most of the can be implemented as plugins or at a connection level. Security plug-ins, Analytical storage engines, XML functions and connectors are still valid options that can well provide great features without affecting the core of the server.

Also, many tools for the Enterprise would simply facilitate the development and the administration of bespoken code or third party software. Tools like graphical set ups and monitoring for HA environments, replication or data migration, and so on would be incredibly helpful.

Promote and participate in new ideas that can make MySQL even better

If we have freedom to think, why not be open minded and think bigger? 1 out of 1,000 ideas may be a great idea! The amount of tools, engines, appliances, services, components and other products - commercial or open source - that have been developed in the last 3-4 years around MySQL is pretty amazing. Projects like Drizzle, storage engines like Infobright and Infinidb, appliances like Kickfire are great examples of these new products. Many others are incubated at the moment and they will bright soon. Some of these products can make MySQL a real success in many areas currently ruled by expensive and legacy solutions.

Make MySQL an affordable and inexpensive alternative to the other databases on the market

What is #1 reason to not use MySQL? Put it simply, it might not fit with the required solution. In the Enterprise market, it means that MySQL may not be certified to work with 3rd party products. In other areas it may be that other databases are the mainstream for certain projects. But IT solutions are really changing. Cloud computing is a reality and #1 database is, again, MySQL. SAAS solutions are the fastest growing products in IT and again, MySQL is becoming more and more the favourite database for a combination of robustness, reliability, performance, and obviously cost of ownership. At SkySQL, I believe I will have the opportunity to address these markets and to provide valid solutions for the Cloud and SAAS companies.

Maintain independence and objective views on the solutions available around MySQL

Despite the suspicion of some users, my ex team and I have always provided an objective view of the possible solutions around MySQL. When we were clearly not in the right place, we simply walked away, saving everybody's time. I want to maintain this level of independence and objectiveness and even more, at SkySQL I have the opportunity to experiment even more technologies and to be 100% agnostic, under any circumstance.

Contrary to what I posted few weeks ago, I will not close this blog. izoratti.blogspot.com is my personal blog and I am going to use it to post comments and ideas. The posts will be mainly related to MySQL, but sometimes I will diverge by sharing my personal experience on other topics. mysql4all.wordpress.com is the place where I will post technical evaluations and suggestions. I will get help from other people as well - the main objective is sharing useful information. I will also continue to work with the MySQL User Groups in UK and Italy, now more than before.

As usual, my postings will not be very frequent. I will let many other people write great articles and share valuable information on a regular basis. Every now and then, I will pop up on Planet.

See you soon!

-ivan

PlanetMySQL Voting: Vote UP / Vote DOWN

Posted in Новости

Комментарии отключены

MariaDB 5.2.3 in openSUSE (Build Service)

Ноябрь 11th, 2010

MariaDB logo You maybe already noticed, that MariaDB folks released their new stable version 5.2.3 today. And as we've got our great openSUSE Build Service, we already have this version packaged and you can install it easilly on openSUSE. I didn't had much time to test it deeply, I just tried that it runs, and that I'm able to connect to it, so it is currently in serveratabase:UNSTABLE repository, but after some testing, it will proceed futher If you want to try it, make sure to backup your data first! So on openSUSE you can use one click install to get MariaDB 5.2.3. For others, you can just use one of the following repositories: