ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

mysql: All content tagged as mysql in NoSQL databases and polyglot persistence

MySQL KILL Command: How It Works

Have you ever tried to kill a query, but rather than just go away, it remained among the running ones for an extended period of time? Or perhaps you have noticed some threads makred with killed showing up from time to time and not actually dying. What are these zombies? Why does MySQL sometimes seem to fail to terminate queries quickly? Is there any way to force the kill command to actually work instantaneously?

Bookmarked.

Marco Tusa

Original title and link: MySQL KILL Command: How It Works (NoSQL database©myNoSQL)

via: http://www.dbasquare.com/2012/05/15/why-do-threads-sometimes-stay-in-killed-state-in-mysql/


MySQL Is Done. NoSQL Is Done. It's the Postgres Age

Jeff Dickey enumerates some of the new features available in PostgreSQL—schema-less data, array columns, queuing, full-text searching, geo-spatial indexing—concluding that PosgreSQL has now everything an application needs:

Postgres has taken the features out of all of these tools and integrate it right inside the platform. Now you don’t need to spin up a mongo cluster for non-rel data, rabbitmq cluster for queueing, solr box for searching. You can just have a single postgres server. That saves a huge ops headache since each of those clusters/boxes have to be durable, replicated, and scalable.

Sounds a bit too optimistic? As we’ve learned from the NoSQL space there are no silver bullets:

Now obviously, there’s a glaring downside with this approach: you get one box. Maybe a read slave or something, but really, you can’t scale it.

As you can imagine I disagree with most of the points, the only exception being that it is great to see so many useful features packaged with PostgreSQL—these are definitely going to make like easier for some of the developers.

But when talking about MySQL and NoSQL being done:

  1. MySQL is done, except it has a huge community, there are tons of developers very familiar with it, and last but not least MySQL powers massive deployments. This last part matters a lot.
  2. NoSQL is done, except many NoSQL solutions tackle different problem spaces providing optimal solutions for these by staying focused. Neither Oracle, nor MongoDB, nor PosgreSQL will be able to solve all problems. The wider range of problems they are covering, the less optimal solutions they are providing for corner case or extreme scenarios.

Original title and link: MySQL Is Done. NoSQL Is Done. It’s the Postgres Age (NoSQL database©myNoSQL)

via: http://dickey.xxx/mysql-is-done-it-s-the-postgres-age


Pinterest Architecture Numbers

Todd Hoff caught some new numbers about Pinterest architecture and from those the ones interesting from the data point of view:

  • 125 EC2 memcached instances, from which 90 for production and 35 for internal usage:

    Another 90 EC2 instances are dedicated towards caching, through memcache. “This allows us to keep a lot of data in memory that is accessed very often, so we can keep load off of our database system,” Park said. Another 35 instances are used for internal purposes.

  • 70 master MySQL databases on EC2

    • sharded at 50% capacity
    • backup databases in different regions

    Behind the application, Pinterest runs about 70 master databases on EC2, as well as another set of backup databases located in different regions around the world for redundancy.

    In order to serve its users in a timely fashion, Pinterest sharded its database tables across multiple servers. When a database server gets more than 50% filled, Pinterest engineers move half its contents to another server, a process called sharding. Last November, the company had eight master-slave database pairs. Now it has 64 pairs of databases. “The sharded architecture has let us grow and get the I/O capacity we need,” Park said.

  • 80 million/410TB objects stored in S3

  • no details about Redis

Original title and link: Pinterest Architecture Numbers (NoSQL database©myNoSQL)


NoSQL and Relational Databases Podcast With Mathias Meyer

EngineYard’s Ines Sombra recorded a conversation with Mathias Meyer about NoSQL databases and their evolution towards more friendlier functionality, relational databases and their steps towards non-relational models, and a bit more on what polyglot persistence means.

Mathias Meyer is one of the people I could talk for days about NoSQL and databases in general with different infrastructure toppings and he has some of the most well balanced thoughts when speaking about this exciting space—see this conversation I’ve had with him in the early days of NoSQL. I strongly encourage you to download the mp3 and listen to it.

Original title and link: NoSQL and Relational Databases Podcast With Mathias Meyer (NoSQL database©myNoSQL)


Benchmarking MySQL Replication With Multi-Threaded Slaves

Mat Keep about the multi-threaded slave replication available in MySQL 5.6:

The multi-threaded slave splits processing between worker threads based on schema, allowing updates to be applied in parallel, rather than sequentially. This delivers benefits to those workloads that isolate application data using databases - e.g. multi-tenant systems deployed in cloud environments.

Original title and link: Benchmarking MySQL Replication With Multi-Threaded Slaves (NoSQL database©myNoSQL)

via: https://blogs.oracle.com/MySQL/entry/benchmarking_mysql_replication_with_multi


Amazon RDS: The Good and Bad of Hosted MySQL

Mostly is good:

RDS is pretty awesome — it’s basically a highly available MySQL setup with backups and optional goodness like read-slaves. RDS is one of the best services as far as Amazon Webservices are concerned: 90% of what anyone would need from RDS, Amazon allows you to do with a couple clicks.

but:

Aside from the monitoring and backup quirks, one of the real pain points of Amazon RDS is that a lot of the collective MySQL knowledge is not available to us. The knowledge which is manifested in books, blogs, various monitoring solutions and outstanding tools like Percona’s backup tools are not available to people who run Amazon RDS setups.

Most of the time is difficult to get access to your preferred tools from small service providers. Amazon cannot afford to include in their operations all available tools for MySQL. But I’m pretty sure they have a prioritized list of the most requested ones.

Original title and link: Amazon RDS: The Good and Bad of Hosted MySQL (NoSQL database©myNoSQL)

via: http://till.klampaeckel.de/blog/archives/179-Hosted-MySQL-Amazon-RDS-and-backups.html


MariaDB 5.5 Connection Thread Pool

MariaDB-5.5.21-beta is the first MariaDB release featuring the new thread pool. Oracle offers a commercial thread pool plugin for MySQL Enterprise, but now MariaDB brings a thread pool implementation to the community!

I’ve checked the timestamp of the post and knowledge base article three times. It is 2012.

Original title and link: MariaDB 5.5 Connection Thread Pool (NoSQL database©myNoSQL)


A Story of MySQL and InnoDB at Facebook Told by Mark Callaghan

Just whetting your apetite for this interview with Mark Callaghan about MySQL, InnoDB, and his work at Facebook:

Q: How do you make MySQL both “less slow” and “faster” at the same time?

A: I ask questions like, “If I can make it do 10 things per second today, can I make it do 20 things per second tomorrow?” For example, we used to use an algorithm that is very CPU intensive to check database pages. Another person on my team, Ryan Mack, modified it to use hardware support on X86 processors so we could profile the servers in production to see what they were doing in these computing checksums.  We then realized that the newest CPUs had a faster way to do that, so we modified the MySQL to use the CRC32 for checksums. The hard part there was upgrading the servers on the fly from using the old check zones to the new checksums without taking the site down.

Exciting and scary.

Original title and link: A Story of MySQL and InnoDB at Facebook Told by Mark Callaghan (NoSQL database©myNoSQL)

via: https://www.facebook.com/notes/facebook-engineering/mysql-and-database-engineering-mark-callaghan/10150599729938920


The Benefits of the MySQL Memcached Plugin

Mario Beck:

But the memcached plugin to MySQL is a replacement or addition to the SQL interface to MySQL. So instead of using SQL queries in your application to persist or retrieve data from MySQL you can use the memcached interface. And what are the benefits?

  • Much higher performance (nb: reduced latency, higher throughput) Easier scalability via sharding Simpler application coding

Plus Baron Schwartz’s cogent addition:

I think a huge benefit you’re discussing, but not naming separately, is consistently. With memcached, you have two copies of the data, and the man with two watches never knows what time it is. With a memcached interface to MySQL, you have only one copy — and it is consistent. This is a huge win.

Original title and link: The Benefits of the MySQL Memcached Plugin (NoSQL database©myNoSQL)

via: http://mablomy.blogspot.com/2012/03/why-should-i-consider-memcached-plugin.html


Induction: SQL? NoSQL? Explore, Query, Visualize

Matt Thompson‘s Induction is a free OS X application allowing access and visualization of data stored in PostgreSQL, MySQL, SQLite, Redis, and soon MongoDB.

Some are asking for a common NoSQL query language, some are trying to put a tabular format on top of NoSQL data, and some are building an indirection layer as a tool.

Original title and link: Induction: SQL? NoSQL? Explore, Query, Visualize (NoSQL database©myNoSQL)

via: http://inductionapp.com/


Examples of Using MySQL in Interesting Ways

Maggie Nelson:

Here are a couple of examples of using MySQL in interesting (and it’s up to you whether unwise) ways:

  • MySQL as a graph database, like Twitter’s FlockDB.
  • MySQL as document store, like FriendFeed’s extremely custom schema design.
  • MySQL as a key/value store. This lets you play with NoSQL concepts using MySQL.

Such examples abound. In fact most of the companies known for their contributions or using NoSQL databases run some sort of interesting relational database deployment. Most of the time these examples are interpreted as clear proof that relational databases can solve any problem. Reality is different though: the engineers’ long time familiarity with relational databases allowed them to ingeniously overpass their limitations when lacking better alternatives. But with NoSQL databases getting more mature every day, less and less problems require acrobatic usages of relational databases.

Original title and link: Examples of Using MySQL in Interesting Ways (NoSQL database©myNoSQL)

via: http://phpadvent.org/2011/out-with-the-old-by-maggie-nelson


WhySQL: MySQL/InnoDB ACID Guarantees for Evernote

Dave Engberg has published on the Evernote Techblog a post explaining why the Atomicity, Consistency, and Durability characteristics of a single replicated MySQL/InnoDB deployment are essential to the way Evernote operates.

While it’s difficult to argue about a technical decision with so little details available, I still wanted to point out a couple of things:

  1. Atomicity: most of the NoSQL databases offer atomic operation at the level of a single record. For distributed systems that do not want to rely on 2PC, it is the multi-row atomic operations that are not supported.

    The example presented in the post does not require multi-row transactions, but rather guaranteed client operation ordering. This is achievable in most NoSQL databases.

  2. Consistency: the post talks about data consistency from the perspective of data integrity guarantees through usage of foreign keys.

    In the world of NoSQL similar behavior could be achieved by different data modeling solutions. Using Cassandra as an example for the notebook deletion scenario, one could store all the notes of a notebook in a single Cassandra row, thus making the delete operation safe.

    It’s also worth mentioning that many of the eventually consistent NoSQL databases offer different consistent read and write operations.

  3. Durability: with just a few known exceptions, most NoSQL databases offer strong durability guarantees.

In conclusion, based only on the few details of the post, one could easily argument that a NoSQL database would fit the bill. But most of the time the reality behind is much different, making technical decisions a tad more complicated.

Original title and link: WhySQL: MySQL/InnoDB ACID Guarantees for Evernote (NoSQL database©myNoSQL)

via: http://blog.evernote.com/tech/2012/02/23/whysql/