Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
Previous 10 Newer Entries Showing entries 31 to 40 of 256 Next 10 Older Entries

Displaying posts with tag: TokuDB (reset)

Percona Server with TokuDB: Packing 15TB into local SSDs
+0 Vote Up -0Vote Down

Two weeks ago we released an Alpha release of Percona Server with TokuDB. Right now I am on a final stage of evaluation of TokuDB for using in our project Percona Cloud Tools and it looks promising.

What is the most attractive in TokuDB? For me it is compression, but not just compression: TokuDB provides great performance over compressed data.

In my synthetic tests I saw a compression ratio of 10:1 (TokuDB LZMA to InnoDB uncompressed), in the real production data it is less, 6:1, but still impressive.

In our servers we have 4 x SSD Crucial M500 960GB combined in RAID5, which give 2877.0 GB of usable space. With TokuDB we should be


  [Read more...]
My Favorite MongoDB Replication Feature: Crash Safety
+0 Vote Up -0Vote Down

At an extremely high level, replication in MongoDB and MySQL are similar. Both databases have exactly one machine, the primary (or master), that accepts writes from clients. With a single transaction (or atomic operation, in MongoDB’s case), the tables and oplog (or binary log in MySQL) are modified to reflect the change. The log captures what the change is so other secondaries (or slaves) can read the changes and process them, making the slaves identical to the master. (Note that I am NOT talking about multi-master replication.)

Underneath the covers, their implementations are quite different. And in peeking underneath the covers while developing TokuMX, I learned

  [Read more...]
Big trouble with zero-length character columns in TokuDB
+0 Vote Up -0Vote Down

What good is a zero-length character column in a MySQL table? A zero-length character column has type of ‘char(0)’. If it is nullable, then it can at least store one bit. If it is not nullable, then the value for this column in all rows is a null string. IMO, not very useful. However, the MySQL Reference Manual says that there are valid uses for such a column, so TokuDB should support it. Unfortunately, we recently found and fixed a bug related to zero length character columns in TokuDB.

A Random Query Generator (RQG) trial generated a table with a ‘char(0)’ column and caused TokuDB to crash when executing an alter

  [Read more...]
March 20 Webinar: How to Scale MySQL for Big Data Applications
+0 Vote Up -0Vote Down

You may think that you have to buy, install, and get up to speed on a new database if you want to work with large amounts of data, but you can do more than you think with the MySQL you already have.
Register Now!

SPEAKER: Jon Tobin, Tokutek
DATE: Thursday, March 20th
TIME: 1pm ET

Without having to change your application or do special tuning you can increase performance and save significant time and money when you need to scale.

Join Tokutek’s Jon Tobin as he demonstrates how to use MySQL or MariaDB in Big Data applications by simply upgrading the storage engine with TokuDB, and how to effectively evaluate TokuDB for increased performance, compression and agility.

During this webinar you will learn:

  • How to dramatically increase performance without having to rewrite



  [Read more...]
Announcing TokuDB v7.1.5
+0 Vote Up -0Vote Down

Yesterday we released TokuDB v7.1.5, which includes the following important features and fixes:

  • Upgraded MySQL and MariaDB to version 5.5.36.
  • Six months of performance improvements to our underlying Fractal Tree indexing.
  • Fixes for bugs, stalls, and behavioral issues reported by users.
  • Fixes for issues identified by the addition of Random Query Generator (RQG) testing.
  • Fixes for issues identified by the addition of Valgrind testing.
  • Full details on the changes in TokuDB v7.1.5 can be found in the release notes section of the TokuDB User’s Guide, available from our documentation page.

As always, you can download the Community and Enterprise

  [Read more...]
Tokutek and Percona Live 2014
+1 Vote Up -0Vote Down

I’ve been a little behind in recent blogging efforts, and realized that in less than a month we’ll be back at Percona Live: MySQL Conference and Expo 2014, aka PLMCE. Last year’s PLMCE was my first, as well as the event where Tokutek announced the open sourcing of TokuDB.

It’s hard to believe that a year has gone by, but the customer adoption in both enterprise and community users has been awesome. TokuDB is available from our website for both MySQL and MariaDB, and is also

  [Read more...]
The MySQL ARCHIVE storage engine – Alternatives
+0 Vote Up -0Vote Down

In my previous post I pointed out that the existing ARCHIVE storage engine in MySQL may not be the one that will satisfy your needs when it comes to effectively storing large and/or old data. But are there any good alternatives? As the primary purpose of this engine is to store rarely accessed data in disk space efficient way, I will focus here on data compression abilities rather then on performance.

The InnoDB engine provides compressed row format, but is it’s efficiency even close to the one from that available in archive engine? You can also compress MyISAM tables by using myisampack tool, but that also means a table will be read only after such operation.

Moreover, I don’t trust MyISAM nor Archive when it comes to data

  [Read more...]
The Effects of Database Heap Storage Choices in MongoDB
+0 Vote Up -0Vote Down

William Zola over at MongoDB gave a great talk called “The (Only) Three Reasons for Slow MongoDB Performance”. It reminded me of an interesting characteristic of updates in MongoDB. Because MongoDB’s main data store is a flat file and secondary indexes store offsets into the flat file (as I explain here), if the location of a document changes, corresponding entries in secondary indexes must also change. So, an update to an unindexed field that causes the document to move also causes modifications to every secondary index, which, as William points out, can be expensive. If a document has indexed an array, this

  [Read more...]
January 28 Webinar: Get More Out of MySQL with TokuDB
+0 Vote Up -0Vote Down

You love MySQL and MariaDB for its ease of deployment, but what if you could increase performance and save significant time and money when your application starts to scale without having to change your applications?
Register Now!

SPEAKER: Tim Callaghan, VP of Engineering at Tokutek
DATE: Tuesday, January 28th
TIME: 1pm ET

Join this interactive webinar with Tokutek’s VP of Engineering, Tim Callaghan, as he walks through the potential pitfalls when using MySQL or MariaDB for Big Data applications, and how to effectively use TokuDB to increase performance, reduce database size and achieve true schema agility.

Attend this webinar to learn:

  • How easy it is to install and configure TokuDB with MySQL or MariaDB
  • How to dramatically increase performance without having to rewrite code



  •   [Read more...]
    MariaDB world record price per row 0.0000005$ on a single DELL R710
    +0 Vote Up -0Vote Down
    Don't look at an industry benchmark here, it's a real client story.

    200 Billion records in a month and it should be transactional but not durable.

    For regular workload we use LOAD DATA INFILE into partitioned InnoDB, but here we have estimated 15TB of RAID storage. This is a lot of disks and it can't no more stay inside a single server internal storage.

    MariaDB 5.5 come with TokuDB storage engine for compression, but is it possible in the time frame impose by the workload?

    We start benchmarking 380G of raw input data files,  6 Billion rows.

    First let's check the compression with the dataset.













      [Read more...]
    Previous 10 Newer Entries Showing entries 31 to 40 of 256 Next 10 Older Entries

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.