5 ms·

Read-only performance for unknown kind of query with unknown size of dataset using memory-cache plugin. Hmmm… I don't see any meaningful information. Should I

• arekanderu 13y ago
  I think i agree with you.
  • eonil 13y ago
    Thanks for explicit agreement. It's hard to keep my opinion because I am usually minority.
• corresation 13y ago
  Yes, you should be impressed. Historically the overhead of SQL put a low ceiling on the potential performance of simple queries. Which is exactly why KV databases appeared in the first place, because a scalar value get in most RDBMS systems barely hit 1000 results per second, and that is being optimistic. That overhead was never optimized away because the classic use of the RDBMS was query conversations where each interaction was very expensive (e.g. large, complex queries), so optimizing it wasn't important. But, thanks to competition, most database systems have gotten fantastically more performant. Even using the TDS interface, I can get close to Redis performance with SQL Server now, while it was beaten by one if not two orders of magnitude a few versions ago. And in this case MySQL added the ability to use a much simpler, lighter memcached API in from of MySQL, for obvious reason -- the underlying database system is fast enough that it is of value. I should add that almost everyone who has commented thus far completely misunderstands what this is taking about. It is the Memcached API atop MySQL. Meaning you can talk to your database server through that API from any client programmed to talk to a memcached server. And that same data that you access via memcached (reading or writing) can be accessed in your normal SQL. Which is pretty cool.
  • jacabado 13y ago
    Could you elaborate on SQL Server vs Redis claim? Or throw some references? I am not doubting but just honestly asking. I've been discussing a possible Redis solution for complementing our current SQL Server. Our problem isn't that big, we need to serve 10k req/sec of a simple query, can SQL Server do that? Isn't the connection pool the bottleneck to handle loads of this scale?
    • corresation 13y ago
      we need to serve 10k req/sec of a simple query, can SQL Server do that Several years ago with SQL Server 2008 R2 I achieved 200,000+ simple queries per second (http://bit.ly/IlH2id http://bit.ly/IlH2id -- this is not a regimented benchmark by any measure of the imagination, but is only saying "validate before assuming" because you might find your install performs far better than you anticipate) using the standard TDS query interface. This was on pretty beefy hardware, and is obviously enormously contingent on the data being in memory (which you can force with 2012), however it blew me away and completely undermined an initiative we had to implement AppFabric / Redis or other solutions.
      • bsg75 13y ago
        > contingent on the data being in memory (which you can force with 2012) What is the mechanism to do this in MSSQL 2012?
        • jacabado 13y ago
          I haven't seen it on the new features of 2012, but I have seen it on some demos of 2014 Beta: http://stevenormrod.com/2013/09/an-overview-of-sql-server-2014-in-memory-oltp-hekaton/ http://stevenormrod.com/2013/09/an-overview-of-sql-server-20...
        • corresation 13y ago
          Whoops, I meant to say 2014.
• epo 13y ago
  No, you shouldn't be impressed. It only shows that some cacheing scheme can deliver data this quickly. One byte reads possibly, perhaps the same byte read one million times. Almost nothing to do with MySQL performance in fact.