|Showing entries 1 to 30 of 43||Next 13 Older Entries|
Warning: this is a mixture of historical content, biases, stupid marketing and unknown/proprietary/closed source technologies. Proceed with caution.
NuoDB marketing was sending out this message, encouraging me to blog (they were looking for bloggers too):
And while Facebook sharded MySQL 4000 times, even they call it a “fate worse than death.”
We’ve seen this phrase before and it did not come from us. For whatever reason NewSQL echo chamber is repeating this with less and less truth in it. In various whitepapers (all behind registration walls) they mention some analyst estimates and try to put a parallel between operating costs of large companies and something a new developer would do, as if everyone is living under same constraints.
I don’t know if NuoDB is a good technology for the[Read more...]
Last weekend I attended my first Fosdem conference. It was great to finally visit the conference that might be the biggest open source conference in the world. It's also an amazing experience how our Belgian friends pull off such a magnificent event purely with volunteer effort. You might say the conference itself is very much open source: free entry, created by volunteers. Organizers estimated that this year there were 7000+ attendees on campus. A hard data point was over 2300 simultaneous devices connected to Wifi.
I presented an introduction to Galera Cluster for MySQL. Due to problems with my personal laptop, I had to resort to an old version of the same presentation I had uploaded to Slideshare last year. (This is a variation of the old rule: The best way to backup your code is to publish it online as open[Read more...]
InnoDB Storage Engine: Data from BLOB columns could be lost if the server crashed at a precise moment when other columns were being updated in an InnoDB table. (Bug #12704861)
A short discussion with Baron at Henrik's blog has stirred my eloquence.
Baron points to a great post by Josh Berkus where Josh contemplates the database clustering issues from a novel viewpoint. The post is really insightful. But I'm going to top that (albeit not so skilfully).
In his post Josh maintains that existing PostgreSQL clustering solutions do a poor job satisfying user needs because developers concentrate too much on technological choices and too little on use cases, which he identifies three: Transactional User, Analytic User, Online User. And all developers need to do is just make three (only three) clustering solutions that would satisfy each of those use cases well. And all
It's been long known that Galera optimistic replication and enterprise-size databases are a match made in heaven. Today we're going to get a little closer to testing this statement.
We'll have look at how Galera can scale out Sysbench OLTP complex 60 million rows workload in EC2. This is a first proper benchmark for 0.8 series and also the first benchmark of MariaDB/Galera port, so I'll start modest, just to see how it goes. I chose m1.large instances with 7.8Gb of RAM for server nodes and c1.xlarge instance for a client - I don't want the client to be a bottleneck.
For comparison I have also measured performance of a stock standalone MariaDB 5.1.55 server. I used the standard my.cnf that comes with MariaDB Debian package with the following alterations:
Neither is ext3. Nor ext4. Nor btrfs. And thus, none of these will work on dual-Primary DRBD. Nor active-active shared storage. Nor any synchronously replicated active-active SAN. And we’re telling you very clearly.
So if you choose to ignore all warnings and put ReiserFS on dual-Primary DRBD, and mount it from two nodes, you’ve just signed up for wrecking your data. And when that happens, don’t come whining. And don’t blame DRBD or any other of the technologies you may be choosing to employ while ignoring the documentation.
It's frustrating seeing examples of MySQL being slow as an example of why you should use NoSQL. If you have an invested interest in comparing two technologies that are already apples to oranges, the least you can do is optimize both. If you can't do it, don't share it.
This came out of a talk on Cassandra. "MySQL" is not on the slide, but it was mentioned in reference to MySQL:
SELECT * FROM tweets WHERE user_id IN (SELECT follower FROM followers WHERE user_id = ?) order by time_tweeted DESC LIMIT 40;Let me simulate that for you:
CREATE TABLE `tweets` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `info` text, `time_tweeted` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), INDEX[Read more...]
./configure --enable-thread-safe-client --with-plugins=partition,csv,blackhole,myisam,heap,innodb_plugin --without-plugin-innobase --with-fast-mutexes --with-extra-charsets=all[Read more...]
Over three years ago I wrote about how you cannot use a stored procedure in a subquery. Well, it’s 2010, and I’m still annoyed by this and a handful of other things.
I was just working today on a report consisting of a series of queries, taking about a minute to generate. Some of the data would be created in a temporary table and queried against multiple times for performance reasons, and ultimately spit out into a CSV file for someone to examine later. I also would like to be able to return the result set, and perform queries on it, which is much faster than querying a view.
Dear interweb, if you have no idea what you’re writing about, keep it to yourself, don’t litter into the tubes. Some people may not notice they’re eating absolute crap and get diarrhea.
This particular benchmark has two favorite parts, that go with each other together really well:
I didnt change absolutely any parameters for the servers, eg didn’t change the innodb_buffer_pool_size or key_buffer_size.
If you need speed just to fetch a data for a given combination or key, Redis is a solution that you need to look at. MySQL can no way compare to Redis and Memcache. …
Seriously, how does one repay for all the damage of such idiotic benchmarks?
P.S. I’ve ranted at benchmarks before, and will continue doing so.
Over the last 5 years, I’ve read so many articles about how X doesn’t scale. PHP, MySQL, SQL Server, Apache, you name it – everything gets a bad rap. Everyone has a different idea of scale and size, and sadly most people think their site with 1 million page views a month can’t handle the load because whatever technology they chose to use supposedly doesn’t scale.
Guess what folks – the problem probably isn’t the language you chose, or the database you’re using. Unless you’re actually big (many millions of pageviews per day), you can usually run just fine with a straight up LAMP stack on a few servers. The real issue is that your dev team has no idea how to write software or use the tools they have available.
At this point, I wonder – what is everyone’s expectation? At what point does someone[Read more...]
|Showing entries 1 to 30 of 43||Next 13 Older Entries|