(Fractal) Tree Frog

Fractal Tree™ indexes are green. They have the potential to be greener still. Here’s why:

Remarkably, data centers consume 1-3 percent of all the US electricity. A majority of this power is used to drive servers and storage systems. Significant energy savings remain on the table.

Here’s why Fractal Tree indexing enables more energy-efficient storage: Data centers typically use many small-capacity disks rather than a few large-capacity disks. Why? One reason is to harness more spindles to obtain more I/Os per second. In some high-performance applications, users go so far as to employ techniques such as “short stroking” to get more performance (and less storage) out of drives. But Fractal Tree indexes are so I/O-efficient that they don’t need as many I/Os.

Consider the power consumption of disks. An enterprise 80 to 160 GB disk runs at something like 4W (idle power), while an enterprise 1-2 TB disk runs at something like 8W (idle power). If you replace many small-capacity disks by a small number of large-capacity disks, you can maintain the same capacity, but reduce your storage power consumption per GB by close to an order of magnitude. So Fractal Tree indexes enable energy-efficient hardware when the metric is Watts per GB.

For a databases, however, joules per DB operation may be a better metric. Fractal Tree indexes are so I/O efficient, that they are terrific when measured as Joules per operation.

What about power consumed by servers? A lot of our customers see an increase in server activity due to the increase in throughput. Fractal Tree indexes are so I/O-efficient that they drive CPUs harder, consequently using more power. But, assuming that a user is trying to keep the same overall target number of inserts/deletes, Fractal Tree indexes are still more efficient in terms of joules per database insert/delete.

Given how important these topics are, Bradley and I recently attended the National Science Foundation workshop “Energy-Efficient Data Management” in Arlington, VA. This was a two-day planning meeting, where researchers from industry and academia convened to discuss open problems in energy-efficient data management. We discussed how to devise and deploy new data-management methods and new data-intensive applications that are more energy efficient.

I spoke about how better data structures have the potential to deliver energy savings. For details, see the slides themselves: “How Fast Indexing Makes Databases Greener.”

The main purpose of the talk was to discuss open areas for research. Here are three open problems I covered in my talk. For more details see the slides.

• Area 1: Develop a massively multithreaded Fractal Tree variant that could run on future-generation machines consisting of thousands very very slow cores.
• Area 2: Develop an Energy-Efficient SSD/Rotational Disk Hybrid.
• Area 3: The proof is in the pudding.

Thanks again to the NSF for supporting Tokutek through SBIR grants on topics like these.

Last week I gave a talk entitled “Don’t Thrash: How to Cache your Hash.” The talk took place at the Workshop on Algorithms and Data Structures (ADS) in a medieval castle turned conference center in Bertinoro, Italy. An earlier version of this work (with the same title) appeared at the HotStorage conference in Portland, OR. Tokutek co-founders Bradley, Martin, and I are coauthors on the work, along with students and other faculty at Stony Brook University.

The talk title is colorful and doggerel-y. Here’s what the title means. “Cache your hash”—the so-called Bloom Filter type data structure. A Bloom filter acts like a negative cache, letting you know that a particular element is not stored in a database. The problem is that Bloom filters don’t scale outside of RAM (they “thrash”). In the paper, the basis for my talk, we wrote about an alternative data structure that scales beyond main memory as data goes to SSDs.

The attendees at HotStorage comprised researchers/practitioners in storage technology for both MySQL and other databases. The attendees of ADS comprised mathematicians and theoretical computer scientists, studying algorithms and data structures. Since storage technologists, mathematicians and computer scientists often speak different languages, it was great to see that this time around they all responded to the material.  The theoretical computer scientists and mathematicians commented on the elegance—but so did the storage practitioners. The storage practitioners praised the real horsepower and the application of SSDs—but so did the algorithmicists.  From my perspective, it was gratifying to get this type of reaction. After all, it’s exactly this type of theoretical/practical conflux that got me excited about starting Tokutek six years ago – applying abstract algorithms to alleviate the all-too-real database bottlenecks our customers face every day.

To learn more about how this proposed alternative data structure supports over half a million insertions/deletions per second and over 500 point queries per second on a commodity flash-based SSD, please click here for the technical paper, slides, and mp3.

One topic we discussed in detail was the data-ingest problem common to three letter agencies: sensors generate thousands or millions of data items per second. The sensors could be recording mouse-click data, taking temperature or chemical readings, or measuring network performance. The data must be stored so that analytical queries can be made on live data in real time.

From the talk, we know that people are interested in indexing and querying live data. Fractal Tree indexes, with insertions that run up to two orders of magnitude faster than B-tree insertions, are an optimal technology for solving the data-ingest problem on large data sets. (Here are more details about Fractal Tree algorithm performance.)  Through this blog and ongoing discussions, we look forward to hearing more about these applications and welcome comments and feedback.

The talk describes how MySQL with TokuDB can provide a path to more energy-efficient database implementations. It’s a theoretical talk. That is, rather than presenting results from an existing implementation, it provides food for thought about future possibilities.

Here’s an executive summary of the talk.

Disks use a substantial fraction of the computing power in a typical database application. Although different workloads and configurations can give very different values, somewhere around 1/3 to 2/3 of the total energy consumed by the computing unit seems like a good ballpark.

Computation is only one part of the power equation for a data center. However, many other components (such as cooling) consume power roughly proportionally to (or at least correlated with) computation. Thus, my analysis of power consumed by computation can give insight into how other parts of the system are affected.

Typically B-tree-based databases are configured with many small-capacity disks rather than a small number of large capacity disks. A 120GB disk consumes roughly half of the power of a 2TB disk, even though it is about 17 times smaller. Using larger-capacity disks has the potential to reduce the power consumed by disks by as an order of magnitude in Watts per GB.

So why not use large capacity disks? Well, B-tree-based storage engines scale with seek time. Increasing the number of spindles drives up the number of random seeks per second in the system.

Fractal-tree-based storage engines (such as TokuDB) scale with bandwidth rather than with disk seeks. (Bandwidth scales as the square root of disk capacity.) Consequently, a well-balanced system based on fractal trees can use fewer larger-capacity disks.

Cutting the power consumption of disks (there are a couple of ways to measure power consumption, as explored in the talk itself) can have a big impact on the overall power consumption of the system.

I’ve left out most of the details. That’s what the talk is for.

Comments welcome!