jhugg

32 ms·

271.
by jhugg 16y ago
I was referring to the Dynamo model for EC, not a particular software implementation. That model has next-to-zero traction in systems that handle non-trivial sums of money, and for good reason. That's not to say it's not great for lots of t
272.
by jhugg 16y ago
Asking what value a particular app gets from an ACID store vs a non-ACID store as part of a comprehensive analysis of two competing technologies is a GOOD THING. As for banks, exchanges, credit cards, packages, etc: When non-trivial sums of
273.
by jhugg 16y ago
This is not really very accurate. At their core, each of these systems use ACID databases (or very nearly if you nitpick about isolation levels in Oracle). Between databases and between companies, they've developed "eventually correct" sche
274.
by jhugg 16y ago
I hadn't really looked into Scalaris much. I see they're trying to provide transactions on a DHT. Cool. Something to keep an eye on.
275.
by jhugg 16y ago
You have to think about partitioning up front. In a sense, this is a prerequisite for our concurrency. So you're right. What I meant was, inside of a stored procedure itself, you never have to think about concurrent access to the data you a
276.
by jhugg 16y ago
Sorry. I didn't write it and I'll see what I can do about toning down the language. In the defense of the text, while some Key-Value stores provide atomic operations on individual values, I'm not aware of many that offer actual transactions
277.
by jhugg 16y ago
I am John Hugg. I do work for VoltDB. I am proud of our transaction isolaton. Not sure why this comment was a reply to me though. I've never claimed all NoSQL is EC, not all SQL/Relational is ACID. I totally agree there is a lot of unfortun
278.
by jhugg 16y ago
Posted this on Dan's blog, but will add here too: A counterpoint to the nobody really uses full isolation levels is VoltDB. Due to it’s unique single-threaded architecture, it can ONLY perform transactions with full serializability guarante
279.
by jhugg 16y ago
I totally concede that most consistent databases at scale are crap on the ops people. I would echo Mike's argument and claim that a nice ops story and true consistency are not totally orthogonal. There are a lot of practical reasons why the
280.
by jhugg 16y ago
There's a difference between what ops people see and what developers see. If the ops people have the same headache no matter what, why force the developers to think about consistency?
281.
by jhugg 16y ago
Not all of the distributed NoSQL systems give up consistency. Notably, H-Base and, in certain scenarios, MongoDB, both offer consistent atomic reads and writes of one thing, be it a row, supercolumn, document or whatever. You make a good po
282.
by jhugg 16y ago
Nice summary.
283.
by jhugg 16y ago
You really should have considered a semi-colon over a comma. ;-)
284.
by jhugg 16y ago
As somebody who knows Mike Stonebraker and works for one of his RDBMS companies, I can honestly say he says this stuff because he really believes that NoSQL is history repeating itself. Whether it's hierarchical databases, XML databases, ob
285.
by jhugg 16y ago
(From my comment on another thread) VoltDB is focused on mutating an in-memory dataset at ultra-high speed with full transactions and ACID. SciDB is focused on analyzing petabytes of scientific data in array form, where people care about th
286.
by jhugg 16y ago
VoltDB is focused on mutating an in-memory dataset at ultra-high speed with full transactions and ACID. SciDB is focused on analyzing petabytes of scientific data in array form, where people care about things like data provenance and accumu
287.
by jhugg 16y ago
My company just converted from an LLC to a C-Corp. The result was delicious sausage, but the making of said sausage is not something we'd repeat if given a choice.
288.
by jhugg 16y ago
If you're counting important things (money, inventory, etc), being up with the wrong answer can be worse than not being up.
289.
by jhugg 16y ago
The pie chart is based on this paper: http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08... . The pie chart numbers have been updated to reflect the right charts in the paper, but the graphic hasn't. We'll try to get that fixed f
290.
by jhugg 16y ago
I like this point. At VoltDB, we like to think we've removed a different set of features than many other scalable solutions, leaving a product that is useful for a set of problems that might not have a great option right now. That said, Vol
291.
by jhugg 16y ago
While VoltDB's persistence story is perhaps bleeding edge (active replication with rolling snapshots as a double backup), MySQL MEMORY storage has none.
292.
by jhugg 16y ago
This isn't a permanent problem. Working on it...
293.
by jhugg 16y ago
I didn't mean to claim anyone will be struggling to decide between VoltDB and Cassandra and then choose VoltDB based on the benchmarks we did. I think that's as ridiculous as you do. Our point, which perhaps I made poorly, was twofold. 1. Y
294.
by jhugg 16y ago
So if your entire data center loses power... If you have any notice (local UPS, etc), you snapshot to disk. If you have no notice, you lose some number of transactions depending on your data size, snapshot frequency and disk speed. Seconds
295.
by jhugg 16y ago
Not legally allowed to say due to the anti-benchmarking license the big vendors use. Maybe I can say it was the obvious one?
296.
by jhugg 16y ago
Also from that FAQ: "If the violation involves GPL-covered code that has some other copyright holder, please inform that copyright holder, just as you would for any other kind of violation of the GPL." FYI: VoltDB owns the copyright to the