Hey Nikita having a colorful html5 home page is not enough for a project to be performant
MySQL is bazillion times faster than MemSQL
141–148 of 148 posts
Re: MySQL is bazillion times faster than MemSQL
#142People should also look at - and benchmark - tokudb with its fractal tree indices.
Sadly for the development of databases their fractal tree technology is patent encumbered.
Re: MySQL is bazillion times faster than MemSQL
#143I think this whole conversation is making a mountain out of a molehill. When you're building sites which have enormous performance requirements, you take what you have and you force it to scale. You don't need to compare one tool to the other and find the perfect benchmark. Whatever you use, I promise you, you can make it perform as fast and scale as far as you need it to.
So just pick the tool that fits your requirements the best and stick with it. That being said, I also urge you to pick something free and open-source if you can. Some of the ways big sites have leveraged MySQL to the extent they have is due to the custom patchsets they apply. Closed-source solutions may not provide similar hotfixes or customization (and when it comes it's months later than they claimed they'd have it ready)
Re: MySQL is bazillion times faster than MemSQL
#144Earlier quoted context omitted.
... you'd think. However in practice most operating systems and/or file systems and/or disks cheat. fsync() is usually buffered in the hard disk itself. You can disable that and force the hard disk to truly write out on fsync, but that is so prohibitively slow that people rarely do that. If you want absolute durability, you'll have to have hard disks running on some battery buffered power supply, which is a common co…
First of all, ext(2|3|4) and XFS filesystems honor fsync. That's what all the noise about Firefox and SQLite was all about. Secondly the HP RAID controllers I'm familiar with disable the drive write cache by default, and throw dire warnings if you try to turn it on, and make you ACK your choice like: Without the proper safety precautions, use of write cache on physical drives could cause data loss in the event of a p…
The file system does, but does the hard drive?
But I agree, getting battery backed write caches is not that hard, it's just not a default config.
Re: MySQL is bazillion times faster than MemSQL
#145Earlier quoted context omitted.
I've actually written a compiler from database queries to native code (JIT'ed bytecode actually, but doesn't make a difference here) once. Some queries in databases are indeed CPU bound, but the general statement that well-optimized databases turn to be CPU bound is not correct like that. It all depends on the use case. If you're thinking full table scans with complicated processing on a database that's entirely in m…
Get by id queries are majority when the database is used as a key-value store, and the only reason to such an underuse of RDBMSes is precisely because under heavy load some of them have hard time doing proper queries, with joins, subqueries and all the stuff databases are designed for.
It's not "underusing" an RDBMs, those are just the lions share of queries in many applications. Also note that a join say from some parent item by ID to children who have a parent_id makes essentially two lookups by ID in two indices, so the same reasoning applies; this is not just SELECT * FROM bla WHERE id = :x.
Re: MySQL is bazillion times faster than MemSQL
#146Why is "written to hard disk" considered to be "durable"? Isn't that just a higher likelihood of "durability"?
> Isn't that just a higher likelihood of "durability"? It's much, much, much more likely to have a memory failure (a crash anywhere from thread to hardware) than a hard drive failure. I don't mind them claiming that as durability.
Well you have to come up with some way to measure it. How about "time I expect this data to be retrievable"?
So you can measure memory and process durability in hours to days, and spinning disk durability in years. I don't know how long SSDs last yet.
Say, (just making up numbers) you expect your servers to run 10 days without a reboot or crash, and your disks to last 5 years before failing. That means writing to memory is about 0.005479 as durable. So it's not great, but it's not zero either.
An interesting thought experiment: how many machines replicating data only in RAM does it take to be more durable than one machine with a spinning disk?
Re: MySQL is bazillion times faster than MemSQL
#147Earlier quoted context omitted.
>And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Whereas MySQL, SQL Server, Postgress, Oracle - all of these products evaluate queries by interpreting their respective tree representations of your SQL queries. This sounds like absurd cargo culting. I've never designed a database but parsing the SQL can not have ever been the…
Actually, it can have a significant impact but it's a corner case. It's a moot point though - as an example, SQL Server stores plans in a memory cache. [1] 1. http://www.sqlteam.com/article/what-query-plans-are-in-sql-s... edit: incidentally, one of the corner cases I can think of is joining 10 tables, which gives you 10! combinations for the query processor to work through. This is irrelevant in MemSQL, because you…
Interested in knowing why this has been voted down! A response would have been more useful. Would love to know what is inaccurate about my comment.
Re: MySQL is bazillion times faster than MemSQL
#148Earlier quoted context omitted.
You seem to be missing the main reason why people have an issue with MemSQL. The issue are quotes like this on your website and video: "MEMSQL IS 30 TIMES FASTER THAN MYSQL." It's an extremely invalid and biased comparison. You're quite literally comparing the speed of writing to RAM versus the speed of writing to disk. If you didn't make such ridiculous assertions, people would accept your product for the actual awe…
Hi Tim, we're not comparing "the speed of writing to RAM versus the speed of writing to disk." You can run InnoDB with a buffer pool large enough to keep the entire database in memory and we'll still outperform it significantly. We're actually working on a blog post right now with that comparison.
Does 'significantly' means '30 times' here?