201–210 of 213 posts
Earlier quoted context omitted.
You seem to specialize in willful ignorance and bike shedding to me.
While you specialize in presumptuous ad hominem attacks against strangers on the internet. I like my vice better.
Earlier quoted context omitted.
I can only go off what you wrote, stating you are deliberately ignorant. I was just reiterating what you proudly said. Do you really think saying you are a specialist, yet won't read about the topic you specialize in because you are scared of a benign name is reasonable? I forgot to mention the ridiculous hyperbole comparing 'cockroach' to racial slurs.
My point is that the name isn't benign. And my post was deliberately somewhat hyperbolic. I actually have read a bit about Cockroach, and if I saw a growing ecosystem that seemed relevant to my work, I would pursue it more. But as others have pointed out, the name creates unnecessary conflict and discomfort. In a world of perfectly rational humans, it wouldn't matter. In the real world, it makes it harder to get stak…
There are no such things as "perfectly rational humans" and if there were they would be rational and would not experience discomfort because of a name because that's irrational. A rational human would see the name as clefer if anything since cockroaches are quite enduring.
Earlier quoted context omitted.
I'm a little confused about how read speed is 2x slower than write speed. With respect to 'correctness', you're drifting into pyrrhic victory or 'not even wrong' territory at that point. When there are basic expectations of behavior that aren't being met, many of us would reject the idea that this code is 'correct'.
> I'm a little confused about how read speed is 2x slower than write speed. FWIW, you're also describing Cassandra and it seems to do fine in the marketplace.
Earlier quoted context omitted.
I submit "Bunker" as a more approachable name. Not only does it have the connotation of "survives nuclear bombardment", but also suggests "keep your stuff safe here" and "something you could entrust with your life".
The name "Bunker" also suggest that the developers are German nazis, since German nazis built a large amount of bunkers in Europe during WW2. .. so probably not a good name either, at least not in Europe. ;-)
Earlier quoted context omitted.
[Disclaimer: CockroachDB engineer here, working on performance and benchmarking] IIRC, in the case that aphyr refers to for these specific numbers, the reads are scans that span multiple shards[1], while the writes are writes to single shards. [1] even though aphyr says it's just a hundred rows, the tables are split into multiple shards because aphyr in this case was specifically testing our correctness in multi-shar…
Are read-only transactions handled without contention? I understand that a read-write transaction needs to be aborted if a later conflicting write is committed. But read-only transactions can view a snapshot of what was committed before they begin - you trade a little bit of latency for being conflict free. It doesn't even have to be the default as long as you offer it as an option, you might want this if you know yo…
Earlier quoted context omitted.
The networking isn't a problem if you only acknowledge a write when the underlying database says so. You could have a write succeed before you crash. But you won't lose an acknowledged write.
No, but when your requirement is to "never loose a write regardless of which server fails" you have to make sure the mutation was acknowledged by more than one server. So the least you have to do is to wait for a second server to confirm the write. But now what do you do when the network link between the two servers goes down in-between a write? The write might have already been applied on the first server or it migh…
We don't have auto-healing HA, you have 32 master databases which have replica databases underneath them with synchronous replication. Meaning things must be synced to both before the COMMIT OK is received by the client.
Then you do the sharding logic in the application.
No write can be sent back as being "OK" unless it's on disk on 2 servers which represent a vertical slice of our entire database structure.
We assume power-loss scenarios mostly, which means if it's on disk and not in vfs then we're fine- as power-loss is more likely than complete raid degradation or server disappearance, although the replicas help with that too.
You don't need quorum at all in this scenario, and no matter which database or client fails you will not lose data that you've acknowledged, even on immediate power loss to 50% of your entire infra.
Earlier quoted context omitted.
Right now not really. Cockroach perf don't allow you do have a big dataset given the performances.
You are misunderstanding this article. This is not a benchmark, this is a test of how correct the database is with distributed transactions and data in the worst conditions possible. These are not real-world performance numbers in any sense.
The problem is not just the performances, it's that distributing has a huge cost in term of servers and maintenance.
If you can write only 50 times a second, your data set won't get big enough to justify distributing it.
Put your millions of row in one server and be done with it. Cheaper, faster, easier.
There is a tendancy nowaway to make things distributed for the sake of it.
Distribution is a constraint, not a feature.
Earlier quoted context omitted.
Even if they manage to multiply this by 100 on the final release, it's still way weaker than a regular sql db. I hope they have another selling point than performance.
There is a better response to this up in this thread ( https://news.ycombinator.com/item?id=13661735 ). The test is testing the worst-case scenario of everything needing locking. CockroachDB uses an optimistic "locking" approach which makes this bad. But if you're use-case is strictly linearizable high-throughput reads good luck finding anything that is not a single-machine database.
Earlier quoted context omitted.
No, but when your requirement is to "never loose a write regardless of which server fails" you have to make sure the mutation was acknowledged by more than one server. So the least you have to do is to wait for a second server to confirm the write. But now what do you do when the network link between the two servers goes down in-between a write? The write might have already been applied on the first server or it migh…
You're taking the wrong approach. We don't have auto-healing HA, you have 32 master databases which have replica databases underneath them with synchronous replication. Meaning things must be synced to both before the COMMIT OK is received by the client. Then you do the sharding logic in the application. No write can be sent back as being "OK" unless it's on disk on 2 servers which represent a vertical slice of our e…
Since you said you don't have "auto healing HA" I assume you don't fail over, but discard/deny incoming writes until the master comes back up.
This is a valid approach, but, I don't see how it contradicts what I said at all:
- I said you can't get full ACID and HA failover at the same time with postgres
- Your scheme does not provide HA failover
So I assume this means cockroachDB currently (probably) meets its promised consistency levels. How does it compare to the usual default settings of PostgreSQL for example? - I think you get SERIALIZABLE, so the behaviour should be very reasonable. I understand the txn/s numbers are in a pathological scenario, but will these transactions block the whole db from moving faster or have unrelated transactions still normal…
All transaction interactions are localized to particular keys, so other transactions can proceed normally while there is contention in an unrelated part of the database.
(as for the acronym, we prefer CRDB instead of CDB)