4 ms·
What's the catch here? :)
by darkxanthos 11y ago
What's the catch here? :)
- deleted 11y ago[deleted]
- ericfrenkiel 11y agohttp://docs.memsql.com/latest/faq/#what-is-memsql-not-for http://docs.memsql.com/latest/faq/#what-is-memsql-not-for
- jhugg 11y agoIt seems like the improvements here are OLAP focused, and welcome ones at that, but the docs and product, if not the marketing, seem to be moving away from operational workloads. From my interpretation of the docs, there are no "transactions" in the Jim Gray / ACID sense of the word. MemSQL offers transactional semantics with READ COMMITTED isolation. This is not just not SERIALIZABLE, it's also not REPEATABLE-READ or SNAPSHOT-READ. For example, imagine a two statement transaction where statement 1 reads a counter value and statement 2 increments it. If two users run this transaction at the same time, the counter could lose an increment. This example is trivial and probably could be done in a single statement, but many other read-then-write operations could cause such an inconsistency. Unless I'm misunderstanding something.
- jamesblonde 11y agoWell if MemSQL supports locks, then you can implement any stronger isolation model using both locks and READ COMMITTED transactions. Do they support row-level locking?
- takeda 11y agoYes, but then you losing the performance benefits.
- seg-fault 11y agohttp://voltdb.com/john-hugg-work-volt http://voltdb.com/john-hugg-work-volt is this you at voltdb ?
- jhugg 11y agoseg-fault: Yep. That's me. You could take what I say with a skeptical eye because I work on a competing system, but it increasing appears that that's not actually true. VoltDB for transactions and ingestion-time analytics and MemSQL for deeper analytics might be a neat combo system. YMMV.
- nizamsql 11y agoHi @jhugg, a performant implementation of a counter usually does not read and update the value in separate statements within a transaction. Generally, people use UPDATE or INSERT...ON DUPLICATE KEY UPDATE (upsert) to implement this workload. In fact, transactional, high-throughput counters is an extremely common use-case for MemSQL [1]. As a matter of fact, even Oracle and MS SQL Server offer READ-COMMITTED as the default isolation level. Moreover, there are known issues with using SERIALIZABLE isolation in Oracle [2]. [1] - http://blog.memsql.com/high-speed-counters/ http://blog.memsql.com/high-speed-counters/ [2] - http://stackoverflow.com/questions/11826368/oracle-select-immediately-after-insert-in-serializable-transaction http://stackoverflow.com/questions/11826368/oracle-select-im...
- jhugg 11y agoYes. I know there are other ways to do simple counters. The counter-example broadly applies to multi-statement operations that feed the output of reads into writes, i.e. in general transactions. And yes, the defaults on many systems are low, but you can turn them up if you have a transactional workload. Read-committed might be fine for a Drupal backend, but it's not truly transactional. Related and neat post: http://www.bailis.org/blog/understanding-weak-isolation-is-a-serious-problem/ http://www.bailis.org/blog/understanding-weak-isolation-is-a... One of the relevant points Peter makes is that weaker isolation may work ok at low contention and low scale, which matches most DB workloads, but probably not the ones people on HN care about.