7 ms·
Distributed SQL vs. NewSQL
- vearwhershuh 7y agoDoes anyone have good experiences with seamless sharding at the database layer? I'm old school and I'd be strongly inclined to look for a simple cut that allowed me to shard at the app layer, but I'd love to hear an alternative view.
- derekperkins 7y agoVitess is awesome if you're using MySQL.
- willvarfar 7y agoI know this is basically an ad for yugabyte, but it’s a nice summary nonetheless.
- themoop 7y agoYugabyte has great articles in general and seems almost to be good to be true what I have read. It is just missing a bit of independent third party reviews but it does look interesting. Anyone with hands on experience?
- fizwhiz 7y agohttps://jepsen.io/analyses/yugabyte-db-1.3.1 https://jepsen.io/analyses/yugabyte-db-1.3.1
- deleted 7y ago[deleted]
- rdtsc 7y agoFrom your link: > 2019-09-05: YugaByte’s blog post states YugaByte DB “passes Jepsen tests”. We feel obligated to state that YugaByte DB’s Jepsen test suite does not pass, though it may in the future. Race conditions in YugaByte DB’s schema system can cause correctness errors. For example, inserting rows into a freshly-created table with DEFAULT values may result in the values for those columns initialized to NULL instead. We can also now confirm that this issue affects all default values, not just DEFAULT NOW(). It also appears that DDL race conditions might, under certain conditions, render tables completely unusable. Yikes. I understand the need for marketing and making their product look good but it's going a bit too far saying they pass the tests when they didn't. I can easily see potential customers pausing when encountering that kind of attitude from YugabyteDB's developers. "What else are they dishonest about..." kind of idea.
- willvarfar 7y agoI don’t know the case at yugabyte but, in general, the outright lies by sales has nothing to do with the integrity of the developers.
- gauravahuja 7y agoDevelopers are responsible for fair benchmarks.
- dilloc 7y agoYugabyte v. Cockroach analysis: https://www.cockroachlabs.com/blog/unpacking-competitive-benchmarks/ https://www.cockroachlabs.com/blog/unpacking-competitive-ben... disclaimer: I work at cockroach
- pm90 7y agoNice. Seems a bit disingenuous on yugabyte to claim they’re better performant in light of this. Just want to say that I love your docs. Haven’t used cockroachDB just yet but the docs are clean, easy to follow, devoid of marketing and focused on facts.
- bithavoc 7y agoSecond that, the CockroachDB documentation is excellent. All the DDL and DML statements are clearly documented and with examples, that's really cool.
- themoop 7y agoThanks, that is exactly the kind of third party analysis I was looking for to add some color to all of Yugabyte's claims
- Nican 7y agoOh good. I had not seen this blog post from CRDB, and I had asked this exact question 4 months ago: https://news.ycombinator.com/item?id=21007562 https://news.ycombinator.com/item?id=21007562
- bithavoc 7y agoI tried Yugabyte a few weeks back, the TServer kept crashing while my backend was creating some very simple tables. I'm stuck with CockroachDB for the time being.
- grizzles 7y agoHave you tried comdb2? I've heard good things. Idk why it isn't more popular.
- ddorian43 7y agoIt doesn't have sharding.
- akhilcacharya 7y agoI didn't know it was used outside of Bloomberg...
- vvern 7y ago> I'm stuck with CockroachDB for the time being. Would you care to share any negative experiences you've had with CockroachDB? What is motivating your desire to look elsewhere?
- bithavoc 7y agoA few weeks back after my attempt to switch to Yugabyte I decided to commit to CockroachDB in a dedicated cluster with TLS, my backend runs migrations including creating the database but only admins and root are able to create databases but because TLS was enabled my root user didn't work anymore. I was not able to create more admin users because that's part of the RBAC Enterprise offering. The database was there but the authorization system triggers before IF NOT EXISTS condition, so I had to make changes to make it work in production. I honestly thought that if I stayed away from Enterprise features then I would be fine, but no: it seems like if I wanted to deploy my backend on-premise, the deployment process would have to include an step to run the CREATE DATABASE script out of band either before enabling TLS or via localhost(?) in a database node, otherwise I'm fucked unless the client buys CRDB Enterprise to smooth out the deployment process. That's a very extreme case of Open-Core money-squeezing shit I would like to stay away from. CockroachDB Core is fine as a product, the docs are up to date and it's not hard to operate, all that is appreciated it. I just don't think I'm the target user, unless you make a shit ton of money as you scale it will be hard to operate without: - Distributed Backups(Enterprise) - Follower Reads(Enterprise) (no, follow-the-workload doesn't cut it) - RBAC(Enterprise) Yugabyte offers all that in their open-source license, which is why I'm rooting for them, that in addition to Change Data capture(Enterprise offering in CockroachDB) is also included.
- dkhenry 7y agoI am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership with AWS showing how far you could push AWS Aurora using Vitess ( https://planetscale.com/news/planetscale-aws-benchmark https://planetscale.com/news/planetscale-aws-benchmark ) Secondly is the claim that there are no distributed transactions or cross shard joins. There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions. We do recommend that you are aware of the sharding mechanism as we will not trigger a cross shard transaction unless we need to. Finally they do say there is no Native Failover/Repair which is only technically accurate. We use a third party tool called orchistrator to do the fail overs, and we recommend you run that along side the cluster so yes its not "built in", but it will launch as part of our Helm Chart fully configured to automatically do native fail overs.
- gigatexal 7y agoVitess runs YouTube. Mic drop. Nothing else to say.
- gigatexal 7y agoTo be fair. There has been a lot of work to make it easier for mere mortals to run it. So take the complexity of it into consideration when evaluating it for use.
- espadrine 7y agoVitess is great. Although I am wondering whether the Planetscale achievement is partially attributable to the fantastic work put in the closed-source Aurora. In particular, it is an order of magnitude better than the displayed CockroachDB benchmark[0], with 81 c5d.9xlarge nodes instead of Vitess’ 64 r4.16xlarge. Can you still beat that with MySQL or MariaDB? [0]: https://www.cockroachlabs.com/docs/v19.2/performance.html https://www.cockroachlabs.com/docs/v19.2/performance.html
- jhugg 7y agoRe VoltDB: >In VoltDB, all replicas for a given shard are updated synchronously by the client application. This is where VoltDB pays a significant performance penalty for write operations when compared with Raft/Paxos-powered distributed SQL databases. Distributed consensus protocols like Raft and Paxos require writes to be sent to all replicas but commit as soon as a majority of replicas have acknowledged the request. Waiting for all replicas to respond is not necessary since the consensus can be established with a majority. Additionally, VoltDB does not detect network partitions by default and requires a special network-fault-protection mode to be configured. When a node of the cluster gets partitioned, the network-fault-protection mode comes into play. It negatively impacts cluster performance by increasing cluster recovery time for not only accepting writes on the shards whose replica was lost in the node partition but also for repopulating the data on the partitioned node when it joins back the cluster. Wow. Basically none of that is true.
- colanderman 7y agoYa. The stuff on NuoDB is basically all untrue or misleading as well (source: I work there). I wouldn't put too much stock in this self-promotion article.