Fractal Tree Indexes: Theory and Practice

my plan is to talk a little more area and practice at the end but just to understand what a fractal tree index is my school how it works what its strengths are and then we'll talk some practice howl at toki tech we've applied frankly three indexes some of my sequel world with a product called ODB and we are currently applying it to the Montville woody be they as yet-to-be-named product the vp of engineering so protect contact it was up there I'd love to talk databases so anyone wants to contact me feel free also in the audience sitting to my left is Bradley Kussmaul who's one of the founders so I only Franklin three indexes at a level I think most of us will appreciate and understand in a new way but certainly uh another level of depth if someone wants to grab Bradley later in the day he can take it down a level so let's pop some in theory at a very high level what I wanted to discuss is well your basic be treated as a data structure and how it applies to indexing and we'll look at how these trees are used by nodb from which is that my sequel storage engine for for helping it get its job done how we've applied fractal trees to our tofu TV storage engine for my sequel and then I'll discuss in a few slides the way I seem on would you be storage at the moment and how we're applying fractal tree indexes to as well we'll do some simple scenarios we're just going to build a simple tea trees we're not going to get into things like with emerge more complex areas of how they work so in a very high level this is what the tree looks like I assume most people here if you're interested in data structures it's pretty simple straightforward when I was a great Wikipedia page if you want a little more on detail but this is the picture that we'll use throughout the first 20 or 30 slides here from a vocabulary perspective beech trees are good they're helping you store and find things in a in a rapid way so if you look at this picture what looks like a pyramid scheme here each of these rectangular areas with this refer to as a note anything above the bottom will call internal notes the very bottom is what we call leaf node so the internal nodes in a beech tree are really more about searching it's a path so it's a way to understand if you want to look something up the internal notes help you get there the leaf nodes themselves are going to store the actual data for these examples you can see on top there's these lines in the middle of these those pivots so that lets you know at the top I had a number the number five for example it helps me understand the writer in the left of that pivot there's pointers that take me down the tree itself down to the bottom and will when I say actual data will become pretty simple to understand so a very simple example this is a bee tree that's got a we're just going to put one value in these eternal notes as things get more complex and this value would be you can make it if why did you want so notice maybe a much more complex picture but understand how things are working here my rule is greater than or equal to you can have any rule you want but if you look at this the internal notes are compacting so the very top we have the number 22 - search for something anything I straight forward either greater than or equal to 22 when I go to write or less and I go to the left down the bottom of these leave notes for storing values and you can see there's multiple values in these leaf nodes normally you're gonna store these in some kind of sorted order so when you get down there you can look them up efficiently but nice simple fill down B tree for example purposes how this relates to databases what do you do any dates you put things in you you take them with updates where you do a lot of searching so in this example that we wanted to find the value we wanted to ask our database what it's is 25 does it exist so the path we take is highlighted in red the value 25 I started the room it's greater than 22 I go to the right it's less than 99 I go to that left pointer I land in a leaf node that has two values 22 and 25 and lo and behold at five yes 25 is there and hopefully my system invite programmed this even not experienced programmer this would be relatively performing very simple operation if I want to insert something it's a similar operation I have to first understand where I would put one insert so 15 I'm to the left of 22 to the right of 10 I'll and in that leaf node at the bottom there's already the values 10 20 and I store 15 in the middle so it retains its sorted properties there so so be trees get a little more complicated when they get large from a performance perspective if you're in a very simple example that many values that's you could probably store that in a certain number of bytes with databases they get bigger you store million Rose there's some some technologies that do a really fantastic job and they keep you in memory and they have their performance characteristics something like my sequel for example you build a prototype website it runs very quickly and then you you get a people start using your website it gets traction and things suddenly can fall apart quickly but what this slide is trying to show that with the database especially at some point of time your your internal nodes hopefully those all fit in memory box there one or more leaf nodes may fit in grant but eventually some of these other these notes are gonna have to actually land on this and that's going to make it challenging when I go to search this B tree to find a value I'm gonna do I owe my disk my SSD spinning this EBS quality and you name it it's going to start to slow down the performance so at high level that's B tree talked a little bit about how I know DB which is a my single storage engine utilizes B trees to get its work done so nodb there's there's a primary key in most databases are gonna have a primary key on any table and then one or more secondary indexes what MTV does with the primary key is it stores it your data cluster so there's certain database technologies where the the raw data itself is is separate segmented from the index the index is on that data an example of that would be bombed with me be my eye Sam a storage engine for my sequel for example so they're going to put all your data in a heap type of store and they're gonna put the index separately in ODB clusters so what a clustering index is is the path as you can see here we're gonna still use the primary key itself for littering so in this example I have a table T where a is my primary key and I'd be in see if you look down at leave notes just to simulate what rows would look like we have two rows and that left most leaf node the primary key for a is about two in the second row the values for so I think you see you know very intimately ties together the primary key itself with the data that's stored there the real advantage to this this methodology is when I'm looking something up by primary key and go down my knee tree and once I find the row I have all the data I don't have to go somewhere else to get the rest of the world what it Ono's for secondary keys is it's towards the secondary key itself is used for ordering purposes and lookups but the payload or the value that's stored with it is actually just a point the primary key itself so as you can see here the left most node I have a row or value negative 5 comma 20 and what that represents is I have a B value of negative 5 primary key for that row is a value 20 I'm not sure I have this in of futures I have another future slice we can talk about the impact of that but it makes it challenging because things up using the secondary index all the secondary index is doing is providing the primary keys and as you can imagine the challenge then becomes I have to go look up the values for those primary keys and things can start to get inefficient in a hurry and this is this slide really points that out so an example here would be very simple SQL syntax I've had that same table example if I want to execute this query on let's select star so I want all columns from the table TV equals 12 to the left what I'm representing is my secondary index so I say go down this B tree and find me one one or more rows get me their primary keys where the value B is 12 I go down the tree following that red path that I need find that for the value 12 I have a primary key of 10 and for the value 12 I have a primary key value too so I think those two pka's and I go for primary key index and I do the same thing I want to find P a 10 and to go down - dips into this III and get the star for my query which is going to be the values for ABC things get a little more complicated as you have more columns in your tables but what this really points out is something people in the nodd world call a it's almost like a hidden joint so even though this is a very simple single table SQL statement behind the scenes it's almost like I'm doing a joint in that I have to go get information twice I get values from the secondary ethics and then go into the primary to get the rest of the row if I want to do an insert there's two things to be done here since I have two indexes on this table so the primary key value is eight nine ten so the what I'm doing here is I'm evaluating that note if that Meno is remembering have to read it in to get it well you know does it's a little bit clever is in secondary index I haven't answered the w-9 value for language of the primary key so you know five five years ago or so came up with a concept to say hey I need to maintain the secretary index but believed of data on big databases might not be in memory and if it's not I want to buffer that at some future point I might do some IL and bring that that doe game but for now let's put it in this small secondary buffer they call that secondary key buffer and what that did for you know when I get my benchmarking on an OTB I find inside it adds a tremendous performance boost to what they don't have about this because prior to this on big data and I've always had to be in the leaf notes on all indexes on tables and it really slowed down the workload especially on assertions keep in mind though as you can see there's a buffer in the upper right hand corner there it buffers inserts updates and deletes to this index but fruits are always limited in size there's trade-offs you can make the buffer bigger but figure buffers don't always need better performance itself when that buffer overflows it has to be empty so sometimes you're just delaying the inevitable by trying to make that too big so let's talk about how fractal trees work and how they might change what we just looked at for first edition IBM db2 similarities between a fractal tree index and a b-tree that it would use so the first the similarities are obvious or the data anomaly notes just like you no idea I'm going to use the primary key it's going to be clustered just like you know was the large differences we have here are highlighted below one is you can see on those internal nodes there's a big rectangle next to them called message buffer so you know on secondary indexes have this little mess or just a buffer of some basic operations on that country we have very large internal little buffers and they can think about Burke a lot more than just inserts updates and deletes the other difference between us and I know is the note size so this is we're trying to scale we put a Franklin tree and X next to it you know DB B tree what you would notice is our note size four megabytes MB B's is 16 kilobytes so it's significantly larger notes but a lot more and our message buffers a lot more in our these notes which can lend themselves to some interesting characteristics from from an SQL perspective that we'll talk about later so just like when they don't give me the primary key notes secondary key looks very similar so these are these are fractal trees where we have actually done a message buffering yet they're just almost identical to a beefy tree implementation where we starting at different is when we actually operate on these so these internal message buffers what they allow us to do is this buffer just about anything so on the annual example when I did this insertion on the right and my primary key I had actually I'm sorry I'm 11 my primary key on the nopp I had actually one of when the operation was done I had to physically put values eight nine ten down into the leaf dough but effective treatment less after that the message buffer so our recommendation doesn't have to be anything more than that we wanted to insert the value eight nine ten we just put that in the root note and we do the the same operation over the secondary index we insert an eight and a nine that's going to be durable it's going to be journal it's performed acid and immediately we're going to return to the user that the insertion is complete and by capturing that message we have enough information in a moment later the user asks for that Roman can give it right back but we've buffered everything instead of with buffering secondary that's maintenance the other interesting thing to know here is our our buffers are different than as you can see we're inserting new leaks and inserts and updates but there's a message of copy we do buffer message call that column so in OB when you want to have a column that's a big walking ugly operation that contained your database offline for quite some time then in fractal tree we can just inject a message that says it's this table we want to add in column C for it's a big int we'll just take that as a messenger we'll apply it at some later time down to the actual data itself and if you ask for C for on a row we can materialize it but we don't have to actually do the work so as it says there are lots of operations any messages yeah it's four megabytes remember this is a simple example now our beech tree we only have a branching factor of two in this example our actual implementation I think branching factor is 16 so the message buffers are broken down into yes so that's so really what we're doing here is were part of it it's we're deferring i/o but the i/o operation is going to be complete very well aggravated so eventually the buffers have copper and overflowing pushed down the level those buffers put down level so by the time of the message is to the left there next to the 10 if all those messages had to push left really one aisle at this to get that leaf node in the memory and then we will find potentially hundreds of operations against the custom much more sequential range can handle very little to talk a little bit among the storage here so Mambo is a popular document storage no sequel system and again though it contains each REITs and what does is similar to my eyes Sam so if we look to the left monocle has primary key so if we wanted to hit certain Nova collection called food the value 55 and we want how about I'm sorry collection called test and then the Edgewood food who's gonna have 55 and create an index on that behind scenes of magalie you end up the 2d treaties point index is the primary key and everything in gets a document ID so there's a series of document ID store to the left there and down the leaf nodes there's a pointer and the pointer goes up into the memory map keep so there's a a large ever-growing set of files and file system that represent the doctors themselves but nothing about the document beyond primary or secondary indexes is ever stored eight days Samantha's gonna use pointers to get to that member mette to pulled out the day go through your document if you do a lookup secondary and that's the same thing they're going to next about food and then have a pointer up into that heap as well what we're working on is removing that eat so they look at what's going on here just like we did with the top would be me for my sequel and the primary key and expertness we're going to still maintain that document ID underscore hid but we're gonna actually store the document self clustered into the primary key and then secondary indexes we're going to store the ID value and do the same thing we would do for my secret little something up secondary indexes it's going to take a a jump over the primary key to get its value which you made up with here is rather than two indexes and heat in our world it's going to be two frankly four units so talk some practice here Tobin Edie is a action on my CD storage engine think thinking of EB it's how we run it on my sequel five five five five my sequel five six it's coming supports acid MVCC runs on Linux some very high level advantages that people talk about and I've got some benchmarks and slides coming up to show these things there's some performance advantages we do quite a bit on compression compared to other technologies and for my sequel in particular we're adding our performance advantages one thing to think about here is we talked about deferring IO and we do it in the SQL world if you look at lvl VB operates almost any operation replace it to insert ignore when you do an updating we do an insert on duplicate key update you know he always wants to do a read before right so it's always going to try to find an existing row and use the data that it gets from the existing row to actually perform the update operation in our world since we have this messaging infrastructure we allow you to do certain operations without incurring any i/o at all the easiest example to think about is is number 3 there the update statement so if I have a website tracking application I might come his buddy the sub a operational update my table help it hammer I said it's equal to X plus 1 which is we techcom what my sequel wants to do it doesn't middle DB for that particular statement is it's going to go to the table hit counter and it's going to look up a row we're site equals death totally teched-out comp so it's gonna take a dip in get the entire set of row data back and what it ends up building is a is a it's going to physically perform the mutation on the road that meets that criteria many multiple rows so it's going to take a dip into the table it's going to pull out any rules that need that criteria it's going to get the current value of hits it's going to add one to that value and it's going to go back into the primary key and physically I think the rows themselves in totally TV we've turned that into a message so under under certain conditions and this one's an easy one for us to optimize we're just going to put a message in the top of the fractal tree that says you know we're citing a joke okay calm just something it's plus one as long as the developer doesn't care about the number of affected roads and most applications don't no one really cares what this was or what it's going to be until something comes along later it says give me hits for and the value to us is when we go to do the operation to figure out that value we can apply this message and actually do the the update itself so we're just gonna answer a message in the top and get to work I'm going to show some benchmark numbers to have a little warning here I am a vendor i bench mark for a living the example I use here is we had a race and John came in first it's in second and Frank third Frank and certainly say F finish third the ten was having the last benchmark saw her in my mind the necessary evil in this world but I'm happy to talk about what i bench marked I try to be fair and fully disclose the things I'm benchmarking but but certainly I think benchmarks have a bad name you know you know so here's the classic first venture initially when WT was being created a big advantage of the product was indexed insertion so have a single table have multiple columns in that table each with their own indexes I believe high bench has five or six pounds in the base table it maintains three secondary advances and with this in what this benchmark is intended to show is if I take that table and i just insert as much data as quickly as possible how fast could totally be run over the long haul adjusting this data and what you'll see here I wish I had a math pointer but somewhere early on certainly wait wait before 200 million rows were inserted in the beginning there it was the green mark you know per second 30,000 inserts per second but at some point around the 100 million insertion mark the the indexes themselves the working data set here became greater than ma'am and I became very very quickly I owe them and the rate controller that this is running on is only capable of summoning iOS per second you know completely crashes it comes down to I think the eggs and fruit but I know Vivi was like 407 per second Tok woody it's it makes some performance penalty when it started to fall out and everybody pretty much stabilized out there right there around 16,000 inserts per second so this is a native 2020 x-factor speed up here for this particular benchmark but what it shows is for this type of workload if I'm doing you know rapid insertions you know as the ability to buff for some of these inserts tobu this is buffering much of the work and not having to do for every single the compression front what's interesting about tofu TV versus you know is just how much compression we can achieve as compared to other technologies and the reasons are very specifically they don't need the I think a lot of it that falls back to you know was never intended to do compression they try to have that as a feature very much further along a new products development cycles they probably would like to but a few things here so that starts with a small block they're going to compress 16 kilobytes we're going to be compressing something somewhere near 4 megabytes if you've ever played around with compression technologies wins it car and you mean it certainly bigger things compress better as the compressor has a chance to look for repetition inside what it's compressing but a big disadvantage Ino has is it's it's it's block size on disk is fixed so even though it's starting with a small 16k clock as a DBA when you want to do compression you tell it what's my target so on this you can tell you know make your make your blocks a kilobyte to kill like 80 kilobytes and if you do the math it's pretty simple to think okay like if I'm going to go for a four page block size on this you know starting with 16 K I'll every better the four types of depression because minimally I'm going to use that for people like Caesar like to compress better so you're already going to have how much compression you can do I think the bigger problem with with compression in something like Italy is what happens when you miss so if you take that 16 K we try to compress it therefore and the compression only achieves 3.5 times so you're it ends up of the five K clock it has no choice but to split those two blocks and recompress the operation that put some pretty significant data on performance there's a slide coming up that shows that around us I missus ice is variable we take that at large know that we're beginning with we compress it what it looks like when it's done VLANs on this exactly that way we also support multiple compression algorithms with various trade-offs so you know supports zealand compression internally we also support lzma which is a better compression or LC which is that much much faster but lightweight compression technology what does that do to performance as I mentioned when you know goes to compressor block and misses it has to split impressive awkward so back to that original graph we don't go out but it's far at this point in the benchmark so who's doing seven fifteen thousand and six percent I'm the president was at four thousand but it simply said in on try for two to one compression that ain't a font size it's painted 5x penalty and fruit but and then try to get half this small again and almost another fifty percent so it really affect the performance turning on compression the compression achieved especially depending on your data type this is log data so it's something I got off of the websites of actually log files just loaded them into the various technology so if we started out with a six and a half feet size on disk if I told you know go for two to one compression and achieved it almost good job I said go for one we've got a spot on Kobe and that's the part of our leg regression models just plopping it it's open e V we got amazing these messages allow us to do things online in an operational way I assume there's some my steeple users here right now but as you're probably aware in my sequel JD SEMA is is a very expensive operation so adding dropping and expanding columns you want to get into make it big adding an index these operations in it in the vanilla my sequel may be very long time and then block the table that's being operated on those read on infiltration of the process has to work around in the field I've seen people do a couple of things one is my favorite location slave take it offline do the operation that's up to the master and then trade places did the operation all over again there's also some helper tools as nominally a schema change tool there's my sequel five states that has some of this in it I think they're useful and helpful they certainly have serious io CPU and RAM consequences they're gonna they're still rewriting the table in the background the other challenge is the new column you don't get it until the end of the operation where with Toby needs it's available immediately I think you know this last point is important many developers and database folks are considering some of these no sequel solutions just because they don't want these limitations for example on TV when you want to do that from you know collection we just do it when you store the document they're all existing documents don't need to be rewritten because they don't actually and I think a lot of people are taking a look at these other texts just to see what could be done there so if we look at one of these operations we want to add a column the t1 who would have column C for the example we should hire Italy these get a lock the table the entire operation those are you only so at least you could read the table if you need it too it's kind of physically rebuild the indexes even though they really weren't involved in the process - oh goody we're gonna drop a message in the root note and we're done you immediately have that the columns they grab the patient get back to work as that last bullet says over time that message is slowly gonna work its way down the triangle tree and when it eventually hits the reitman the leaf node is going to rewrite need those undefined instead of SAT as a bulk operation to do what he did in the meantime through it's being processed by that mess yeah so anytime it's a good point when you go to do a query the query city but not leave them to get the base note itself but the insert might still be a message in the head not that made it down so that's somewhere every and above that might be an ADD column and above that like the ability message so it's been a materialize a stack of message applications at the very top of which might be that delete at which point the user gets 0 rows down since that all has to be done so what if there's a problem where you have something like you've done an altar table to add a column but then you insert something you don't name the column or something I mean how long you have to wait to get an error back for something like that because if it just goes in the message here like the insert just goes the message queue does it check the stack for the schema and what it should be my sequel is still about so when you do that operation the message lands in the root node of the tree but we still up from my sequel perspective have to modify the tables metadata so my sequel is still the source of truth in terms of what the schema looks like so does that happen right away so that's new and there's gonna be you know there's gonna be a blocking operation for any moment because we have to take a metadata lot with my sequel we have to update the the schema for that table and then give the table back to my sequel to get back but to your point in alert when you do that query what we the benefit we've just done to ourselves at that leave notice now in memory so should it mean time so these messages have pushed all the way to the bottom then we will apply all the messages so that leaves nobody gets dirty and the next checkpoint it gets written out to disk it's nice but we don't really there's another operation what's going on the back and the cleaner threads job is to just keep an eye on these trees and to just always wait for things to push you know it might be creating a problem because if your system is idle for a period of time it would make sense when I start pushing some of these messages so there are activities going on in the background try to scrub these trees yeah and we did another difference between us and it'll be B we've checkpoint freedom so our checkpoint operation by default it's every 60 seconds we're gonna write anything any dirtiness entry it's gonna get rid of the disk here you know BB I think is more it tends to delay that that operation so there's certain operations in in Nou in theory in an hour if you run the rate benchmark you get dirty for dat cash and when you go to shut down you're gonna be sitting there for a very long time we're with us it's only gonna let you get about 60 seconds away from where it was at the last checkpoint and get working in the background that end columnist is probably not much more than the bytes yes we check the whole tree so the other thing to keep in mind here is there's no there's no getting around the the edge case for that type of operation so if I did if I had that column and two billion row table I can give it back like that you say select star from table where equals five I'll give you back that the default value for that column if your very next statement was updating table name said that new column equal 5 semicolon and you want to hit the whole table there's no way around the expense of that operation so frankly tree doesn't save you from the fact that if you're mutating two billion rows those mutations but if you want to update two billion rows like one at a time that's still we have something we call hot indexing and X is in the background that's going to build an index so traditional my sequel what you want to have an index to to Nov be it's gonna lock the table I'm gonna go read only for the duration of that operation and depending on how the new table is that take hours it could take days it's really just as fast as your hardware supports with us with our messaging architecture we're able to to create this in the background so a created nice operation it starts creating me and thanks for the background the index is going to be available when it's when the indexing operations that the table is fully available if you do show process lists we can do a very good feel for how long it's gonna be more that index is actually I didn't want to show any more tofutti benchmarks but I did want to show a couple so these these particular benchmarks were run off the but last year but they show up very similar characteristic to what we saw the comparison so the same thing here I just you have brought indexed insertion I'm going to put documents in a collection of the index multiple fields mono quickly drops very significantly lower levels of performance on this particular server once the database what they will tell you is sighs your mom goes server appropriately you want to have a server that's got the amount of physical RAM that's equivalent to the working data set working data sets at work it doesn't mean you've got to a two gigabyte two terabyte database that need two terabytes of RAM but turning needs to fit in main memory so when this benchmark it looks very similar the token version was slightly faster when it was completely in memory but it pretty much leveled off at the 7000 document inserts per second and the Mambo quickly came down the recent aqua version doesn't find all the right is that because it was starting to get the performance levels where very long time to get out to the 200 inserts there's a flipside of this insertion performance so I did a hit a second benchmark where I was inserting data and once per minute I would have a second thread wake up and do the scan of the thousand documents that were an index scan of a thousand documents so this first example is paid like by using up the non covering in this so it's prepared this is the query latency of that thread that once for anyway something goes up it's adaptive as you can see here there weren't that many documents it was mostly in memory performance was definitely oh geez once the data was larger than ran that heck was actually doing I owe for the inserts plus having a new label for the queries they got much worse and the scale on this is logarithmic so when I had the scale of this as many the graphs were really hard to read so the example here is 100 milliseconds latency for us and ten thousand milliseconds when I changed it to be covering I went into and I added additional attributes my index so that the queries can be covered covering index is an index where they be satisfied by the index itself it doesn't have to actually go back to anything mama looked a lot better what was interesting to me was the kind of mountain that's created and they seem to be leveling off to something a little more friendly at some point I want to run this one out to see with that but that certainly is still at least the scam on this one is it much more usable but your query latency was five milliseconds the second query on some of these benchmark three is something that that model has the ability imago you can have a field as an array and the array if you index that field that creates what's called a multi key insert what I wanted to see was to try to try to be a little more fair and really fascinated mixing performance let's let's create a document that has anything array of a hundred elements I think mom though probably not recommend to do this unless you had a really large server randomizing the graphically so I do that same index insertion benchmark from the first example but instead of instead of a field metal he has one value past 100 values as you can see here again the trend likto who is do the maintain level of performance and keep that come on the line here went out without one and a half visitors per second 35 billion insertions so what it really shows is that the strength of indexing of cracking treats when you're doing 100x the amount of indexing it really affect your insertion that is it for my slides certainly happy to take questions we were showing the difference between financial and in fact that they experienced rapid mixing this you some mayor about the beach baby that you see within the same so confusing is all the examples of so be treating at was so the and then if you making sighs those buffers in a certain way pushing messages down theoretically under worst case well so we're looking side for one of those buffers there as well that speaking training chatroulette streets all the way back back to layers is either the MySQL fractal tree stuff or the DB Faculty's job tree stuff opens are so they both close sorcerer that's on the model France experiment I thought you I thought you had posted something where he'd committed something to source and I wasn't sure if this was it no I admitted I created my Nexus bench against person so from a my sequel perspective we are the fractal tree engine is a shared library and we had to patch my sequel to get certain aspects of functionality so all our my sequel patches are available with the source on our website to create a storage engine you have to write handwritten our handler tennis believe the source is fully available on our website as well so certainly if someone work were interested in writing a writing their own storage engine it might be interesting to look at our implementation to handle it but the fractal tree is engine itself is closed and we do have a couple of our users prefer to take our take the source and take the shared library and compile and Link themselves not many but the ones that do what success is doing that we put out a single tar ball any other questions it's embrace our complexion what should their attention person hear someone from tennis no we have a session but I don't think that's from someone at attention yeah we are thinking about it the name because it won't see when I blog about it it's it's a lot of words to say MongoDB plus frankly free indexes takes up a lot of space just just call it web scale fracked fracking

Channel: tcation

Views: 6,987

Rating: 4.5999999 out of 5

Keywords: opendbcamp, mysql, fractal, btree, data structures, tokutek, tim callaghan

Id: c-n2LGPpQEw

Length: 45min 22sec (2722 seconds)

Published: Tue Mar 19 2013

Reddit Comments

[u/kxra]

Here's some scepticism from the btrfs maintainer (follow the whole thread for counter-arguments): http://thread.gmane.org/gmane.comp.file-systems.btrfs/16484