3 ms·

The much-more-informative original blog post from MySQL's site, which RWW doesn't seem to link to for some reason: http://dev.mysql.com/tech-resources/articles

by seldo 16y ago

The much-more-informative original blog post from MySQL's site, which RWW doesn't seem to link to for some reason: http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-with-memcached.html http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-... What wasn't obvious to me from RWW's article is that this isn't actually memcached at all -- it's InnoDB, speaking the memcached protocol, to save having to create a whole new protocol and a bunch of new clients. Essentially, it's MySQL pretending to be memcache, but a memcache with persistence. Pretty cool!

vessenes 16y ago
Thanks for the link. For some reason, this release totally bugs me! This strategy from the MySQL team is exactly the opposite of what their customers need, in my opinion. The number of people using key-value stores because of their query semantics is dwarfed by those using them for their speed. What MySQL needs is the converse of this -- a way to lock tables / rows / query results to RAM for custom access patterns as determined by developers. "Helping customers preserve memcache investments" is just silly -- nobody would have made memcache investments if MySQL did what I just described above. Anyway, this should be a blog post rather than an HN comment, but, ... I'm surprised. I thought that the Oracle product managers were better than this.
- riffraff 16y ago
  but the mysql folks have already explained that accessing innodb without the overhead of SQL (both protocol and semantic) implies a huge difference in performances. So this goes in the direction of your implied problem: faster access to data.
  - vessenes 16y ago
    They do mention this in their press release -- no sql engine overhead, etc. My experience with MySQL (and Postgres and Oracle to a lesser extent) is that it is precisely the general-case optimizations built into the database that make the NoSQL use case really hard. Have you ever designed a large MySQL database that you wish to persist to disk but the use cases of your app require keeping the entire table in RAM? NoSQL implies a developer commitment to a certain, restricted set of use cases for data access (and sometimes storage). In exchange, you get extreme granularity over how the server stores and retrieves data. Once you do that, you frequently get at least an order of magnitude speedup in your data, maybe 2 orders, depending on the data and access patterns. I do not anticipate significant numbers of people dumping their redis or membase stores for this solution, because the press release strongly implies a 1.2-1.5x speedup for certain data access, not 10x-100x. 1.5x isn't good enough; if it were, people would have tuned MySQL some other way originally rather than moving architecture over to KV stores like they did. This will likely get uptake from people who are already committed to MySQL and occasionally want to use a KV store for certain data patterns. I would anticipate, though, that this will just make it easier for those folks to move their KV store out of MySQL once it scales. And that's not such a bad thing to offer to people, so I take back my earlier disappointment.
EGreg 16y ago
It's more than that. It allows you to mix and match the SQL interface with the memcached interface. It doesn't have to be persistent actually :)

by seldo 16y ago

vessenes 16y ago

Thanks for the link. For some reason, this release totally bugs me! This strategy from the MySQL team is exactly the opposite of what their customers need, in my opinion. The number of people using key-value stores because of their query semantics is dwarfed by those using them for their speed. What MySQL needs is the converse of this -- a way to lock tables / rows / query results to RAM for custom access patterns as determined by developers. "Helping customers preserve memcache investments" is just silly -- nobody would have made memcache investments if MySQL did what I just described above. Anyway, this should be a blog post rather than an HN comment, but, ... I'm surprised. I thought that the Oracle product managers were better than this.

riffraff 16y ago
but the mysql folks have already explained that accessing innodb without the overhead of SQL (both protocol and semantic) implies a huge difference in performances. So this goes in the direction of your implied problem: faster access to data.
- vessenes 16y ago
  They do mention this in their press release -- no sql engine overhead, etc. My experience with MySQL (and Postgres and Oracle to a lesser extent) is that it is precisely the general-case optimizations built into the database that make the NoSQL use case really hard. Have you ever designed a large MySQL database that you wish to persist to disk but the use cases of your app require keeping the entire table in RAM? NoSQL implies a developer commitment to a certain, restricted set of use cases for data access (and sometimes storage). In exchange, you get extreme granularity over how the server stores and retrieves data. Once you do that, you frequently get at least an order of magnitude speedup in your data, maybe 2 orders, depending on the data and access patterns. I do not anticipate significant numbers of people dumping their redis or membase stores for this solution, because the press release strongly implies a 1.2-1.5x speedup for certain data access, not 10x-100x. 1.5x isn't good enough; if it were, people would have tuned MySQL some other way originally rather than moving architecture over to KV stores like they did. This will likely get uptake from people who are already committed to MySQL and occasionally want to use a KV store for certain data patterns. I would anticipate, though, that this will just make it easier for those folks to move their KV store out of MySQL once it scales. And that's not such a bad thing to offer to people, so I take back my earlier disappointment.

EGreg 16y ago

It's more than that. It allows you to mix and match the SQL interface with the memcached interface. It doesn't have to be persistent actually :)