CockroachDB: The Resilient Geo-Distributed SQL Database(muratbuffalo.blogspot.com)
muratbuffalo.blogspot.com
CockroachDB: The Resilient Geo-Distributed SQL Database
http://muratbuffalo.blogspot.com/2022/03/cockroachdb-resilient-geo-distributed.html
36 comments
I often see these “I raised this to sales team… but they are not listening”. The cost of the sales team (including sales engineers) working on an opportunity is not low. If you have a use case and explain to them how you want to use their product (and if you are serious enough to buy it at the end of evaluation if it satisfies your requirements. You must also have influence in your company to make decisions. Some random startup with little cash to spend on software is not going to get you far) then they will surely try to address each of your specific issues. If not they may tell you it’s not a good use case. Just saying something about compatibility doesn’t really give them (or any Enterprise software vendor) to really hear you.
This is not to say all companies are like that but that’s how it works in general in enterprise software. Every conversation is part of a Salesforce stage (whether we like it or not)
This is not to say all companies are like that but that’s how it works in general in enterprise software. Every conversation is part of a Salesforce stage (whether we like it or not)
> If not they may tell you it’s not a good use case.
That may is key here. I've never had a sales guy say ok this doesn't fit. They will go to great lengths to fit their square peg into your round hole.
That may is key here. I've never had a sales guy say ok this doesn't fit. They will go to great lengths to fit their square peg into your round hole.
That’s the job of sales engineer too in many cases. But a good account executive will tell you upfront if it’s not a good use case. If not you won’t buy at the end of evaluation and that has consequences for them (Companies need to predict quarterly revenues and by betting on a bad use case that person will have a bad projection of sales for that quarter or year which will ultimately be bad for them)
Examples?
There's a list here: https://www.cockroachlabs.com/docs/stable/postgresql-compati...
There is some Yugabyte marketing material that lists:
- expression based indexes
- partial indexes
- table functions
- stored procedures
- multidimensional arrays
- triggers
- user defined types
- temporary tables
- row level security
- column level privileges
- extensions
As being areas where cockroach is not pg compatible. That said, besides temporary tables I would consider all of these to be more advanced features.
- expression based indexes
- partial indexes
- table functions
- stored procedures
- multidimensional arrays
- triggers
- user defined types
- temporary tables
- row level security
- column level privileges
- extensions
As being areas where cockroach is not pg compatible. That said, besides temporary tables I would consider all of these to be more advanced features.
Expression-based indexes were added in the previous release. Partial indexes have been around for two releases. Those two combine pretty well. Temp tables exist and have existed for two years, but the implementation is not very good; they’re essentially regular tables which get cleaned up. UDFs exist in terms of enums but not records. Functions, procedures, and triggers are next up.
I’m not sure about that list. I’ve used partial indexes and users defined types with CockroachDB
Triggers for me, though you could argue those could/should be baked in the queries.
I would argue strongly for that. Triggers should be used rarely. If you need an update to cause some other side effect, make the whole process explicit in a stored procedure. Triggers can cause suprises and affect transactions in ways that are not always obvious.
Maybe I'm a sadist, but I love triggers. I can easily compare old and new values with them and call functions that also can do comparisons and if statements. Can I do all of this in query? Maybe, but it would look very ugly (especially if I forego the functions too). I only have one app interacting with the database, but if I had more the triggers would enforce data consistency too.
Triggers are hard to trace, I'll give you that. I try to test them pretty thoroughly via application unit tests though.
Triggers are hard to trace, I'll give you that. I try to test them pretty thoroughly via application unit tests though.
I 100% agree with you in all points. Triggers are incredibly useful and we shouldn't be scared of them, we should be careful though.
listen/notify
edit: https://github.com/cockroachdb/cockroach/issues/41522
edit: https://github.com/cockroachdb/cockroach/issues/41522
Out of curiosity, why write https://github.com/cockroachdb/pebble and not just use https://github.com/dgraph-io/badger?
A big reason seemed to be compatibility with the RocksDB on-disk file format.
https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/
https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/
Along with the other reasons, Badger is not that great. When you have the funding and presumably the developers they have, it makes sense to do something better.
Anywhere I can read more about issues with Badger?
Its issue trackers. There have been sad bugs going on years deep into the project. Maybe they’re all mopped up in 2022 but I wouldn’t count on it. Its design does well on a certain usage profile at the expense of mixed read/write or other workloads. Cockroach has more money and could throw better developers (more experienced) at the problem. Haven’t looked at Pebble though.
Never used badger but after discovering major perf issues in graphene graphql library for python, the issue tracker is sometimes a good place to look.
I found this one pretty quickly:
https://discuss.dgraph.io/t/db-write-latency-in-badgerdb-hig...
I found this one pretty quickly:
https://discuss.dgraph.io/t/db-write-latency-in-badgerdb-hig...
Well it says its SQL, not just a KV-store. That's a pretty ig difference to start.
Hmm? The pebble page doesn't say anything about SQL. It just says KV like Badger.
Did you miss the title? It literally says SQL in the title.
Pebble is a key-value store, not an SQL database.
No I don't see that either. document.title on the pebble Github page says:
'cockroachdb/pebble: RocksDB/LevelDB inspired key-value database in Go'in the article:
CockroachDB (or CRDB for short) consists of a distributed SQL layer on top of a distributed key-value store.
CockroachDB (or CRDB for short) consists of a distributed SQL layer on top of a distributed key-value store.
... and the question was about why they built the key-value store instead of using an existing one. The question clearly was about pebble, not CockroachDB, so why are you arguing about what CockroachDB is?
[deleted]
I really hope CockroachDB can continue to hire engineers from Australia. Would be one of the best companies to work for in the whole APAC region.
I wonder if they intend to open source the serverless model once it comes out of beta. Seems like an ideal model to run a multi tenant service.
Has anyone used Django with cockroachdb successfully? Are there major problems with migrations due to table alters being asynchronous?
Also, is the OLAP performance really that bad?
Also, is the OLAP performance really that bad?
to be fair the open source version does not support geo replication!
Its not and there's no clear roadmap for it to be.
I'm not talking about obscure edge-case stuff here, I'm talking about some pretty major low-hanging fruit that is there is Postgres and not there in CockroachDB.
Anyone who thinks they can magically drop Postgres for Cockroach will be sorely disappointed.
And yes I've raised it with CockroachDB salesdroids when they've "reached out" and all I get in return is the digital equivalent of a shoulder shrug.