41–46 of 46 posts
Earlier quoted context omitted.
Why? If a single node fails, you still have the data on 2 other nodes. Nothing is lost. Of course, assuming you have a reliable UPS.
Because the data may not have replicated to the other nodes yet. As the parent comment noted, you could synchronously write to all replica nodes, but thats a big performance penalty and not partition tolerant.
Earlier quoted context omitted.
>These two projects solve totally different problems No they don't. This is the wavy-hands NoSQL defensive shield that reeks of insincerity. If you show Cassandra or Redis or some other solution replacing a MySQL install, well that's just awesome, but don't dare compare if it doesn't come out the winner. A lot of people have workloads that could work in VoltDB, a classic RDBMS, or Cassandra, equally. There are worklo…
Why not compare it to Redis instead? They are both in-memory snapshotting stores, sure Redis does less but it is still a closer solution. But, Redis would probably be faster.
This reads like marketing-blogspam to me. These two projects solve totally different problems, and the author acknowledges it, yet he still goes on to highlight benchmarks where VoltDB is 10-20x faster than Cassandra. Of course it's going to be! It's an in-memory store! So why benchmark against Cassandra? It's got a lot of buzz around it, of course. What a better way to shove your name into the "NoSQL" ring. Blech. W…
From their white-paper apparently DBMS systems spend 35% of their time doing buffer management, 17% doing logging, another 19% doing latching and finally 21% doing locking. This leaves only 7% for "useful work". In comparison, VoltDB has 95% capacity for useful work. Reads even more like marketing blogspam!
Earlier quoted context omitted.
That's like benchmarking Berkeley DB vs. MySQL. They are on totally different levels of complexity. You can't compare memory-only db performance against a disk based db, period.
>You can't compare memory-only db performance against a disk based db, period. But...you can. What do you mean you can't compare? Clearly you can, however mortified you might be at that prospect. A reasonable motorcycle can go from 0-60 in about 4 seconds. A reasonable car can do it in about 9 seconds. But you need to carry two passengers so the car is your only option, and such a comparison doesn't matter to you , b…
Earlier quoted context omitted.
>You can't compare memory-only db performance against a disk based db, period. But...you can. What do you mean you can't compare? Clearly you can, however mortified you might be at that prospect. A reasonable motorcycle can go from 0-60 in about 4 seconds. A reasonable car can do it in about 9 seconds. But you need to carry two passengers so the car is your only option, and such a comparison doesn't matter to you , b…
Of course you can compare them. You can compare the speed of Oracle on a huge RAC cluster vs. text files on an Amiga 500 floppy drive. But no one would, because it's stupid and worthless. I guess that's what I meant: this is a stupid and worthless article.
Our point, which perhaps I made poorly, was twofold. 1. You can be both fast and SQL. Nothing about the language itself was ever the bottleneck. 2. VoltDB isn't just for big complicated transactions. You can use SQL for KV-type workloads and perform.
There's 100 other reasons to pick one data layer over another, and the best tool will be different for different problems.