CockroachDB features about docs HOT 14 CLOSED

Note: still a work in progress!

Current benefits are:
Effortless consistency with a distributed database.
Why it matters?

• Existing distributed databases do not support consistency
• Consistency is needed to offer up great features like transactions and SQL
• Make it easier for developers to reason about their applications

How we do it?

• Layered architecture (brief intro to abstraction levels, with focus on storage - nodes, stores, ranges).
• Synchronous replication (Raft)
• Distributed transactions
  • Optimistic concurrency control
  • Discuss single phased commit versus two phased commit

How we compare?

• Consensus vs. Primary/Secondary replication
• Strong vs Eventual consistency

Simple scaling with automatic rebalancing, replication, and failover.
Why it matters?

• Scaling gets really complicated really fast
• Manual replication and sharding is costly for the business and increases the burden on developers
• Build an application and let the database handle scaling

How we do it?

• Add nodes with a single command
• Gossip protocol - rebalancing, replication, failover
• Self organizing -> discuss 3 nodes and 5 nodes situation

How we compare?

• Automated vs. manual sharding (and rebalancing)
• Automated vs. manual failover (and repair)

Familiar SQL interface [without manual sharding] for powerful data modeling and analysis.
Why it matters?

• SQL is time-tested. You don't have to retrain you team to use a new data modeling language
• Distributed database models are hard to reason with
• Ad-hoc analysis is easier with SQL - easier to introspect database

How we do it?

• Layered Architecture: More focus on SQL > KV?
• Standard relational concepts (tables, columns, indexes, views) with innovations (column families, interleaved tables)
• Pgwire compatibility (drivers/ORMs)

How we compare?

• SQL vs proprietary APIs
  @jseldess @kuanluo @jess-edwards @sploiselle

from docs.

Thanks Diana for the structure.

I mocked a wireframe of what this page looks like in my head:
https://invis.io/7B9DVZ8K8#/206251126_A

• The difference between the two screens in the InVision (A&B) is whether we want to include some links to blog posts/tech talks in the header module.
• I remember we wanted to have the page feels more like a blog post, so I left a module in the middle, imagining all the copy/images/simulations can go together like one blog post.
• Tabs for "How we do it" section as they might get quite long.
• Floating CTA buttons as people are reading.
• Have inbound sales CTA as well as the other two benefits called out at the bottom of the page.

Hopefully the wireframes would help you guys move forward with content - let me know if you have any questions, and am happy to set up some time for us to go over this together. Leaving comments either in InVision directly here is perfectly fine.

@dianasaur323 @jseldess @jess-edwards

from docs.

Thanks @kuanluo !

Overall, I think having this mock up is very helpful. In terms of how we were thinking about structuring it, I was talking to @jseldess about this, and I think I personally want to go along the line of how our sales deck does it - having a linear story of the architecture and then wrapping in the features / benefits and comparing it to existing solutions. In that context, how do you think that would effect the design of the website?

from docs.

This is a great start, @dianasaur323 and @kuanluo.

I really like Diana's idea to start with architecture, move to features/benefits, and then compare to existing solutions. I've expanded Diana's outline above with a few ideas, mainly:

Effortless consistency:

• Starting "How we do it?" with a brief intro to the layered architecture, but focusing on the physical storage (node, store, range) aspect and deferring more detail on the abstraction levels to the SQL "How we do it?" section.
• Added ideas for "How we compare?":
  • Consensus vs. Primary/Secondary replication
  • Strong vs Eventual consistency

Simple scaling:

• Added ideas for "How we compare?":
  • Automated vs. manual sharding (and rebalancing)
  • Automated vs. manual failover (and repair)

Familiar SQL

• Added ideas for "How we do it"?
  • Layered Architecture: More focus on SQL > KV?
  • Standard relational concepts (tables, columns, indexes, views) with innovations (column families, interleaved tables)
  • Pgwire compatibility (drivers/ORMs)
• Added an idea for "How we compare?"
  • SQL vs. proprietary APIs

Thoughts? @sploiselle, please feel free to chime in and help expand this outline. @spencerkimball and Diana's sales deck helps a lot, in case you haven't seen it.

from docs.

@jseldess great point on breaking out some of those SQL features and focusing more on KV stuff for effortless consistency. I agree on that point. I'm thinking that potentially a good way to go about this is to create a big list of all the "features" and then somehow map them into benefits that way. Maybe a post-it note session is in order?

from docs.

Per our convo, I removed the tabs so there's a single content area for all features to be blended together, and added use case area on top.

Link remain the same:
https://projects.invisionapp.com/d/main#/console/9638070/206316661/preview

from docs.

@dianasaur323, yes, a post-it note session would be productive! I'll put time on the calendar for early next week.

@kuanluo, I like the new mock with a single content area, since we may end up with more topics than we can show tabs for. But we can experiment with this once we have some content.

from docs.

@jseldess @kuanluo Kuan, thanks for editing the website mock-up! Agree with Jesse, and hopefully we will have some good content ideas soon!

from docs.

Sounds good! Look forward to it.

On Thu, Nov 17, 2016 at 5:39 PM, Diana Hsieh [email protected]
wrote:

@jseldess https://github.com/jseldess @kuanluo
https://github.com/kuanluo Kuan, thanks for editing the website
mock-up! Agree with Jesse, and hopefully we will have some good content
ideas soon!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABauk4ACkah3HpfmMSt0nAYdtSGcQ4zgks5q_NeagaJpZM4HbO8i
.

Kuan Luo
Design Lead /* Cockroach Labs*

Help us Make Data Easy! http://grnh.se/l4bqjc

from docs.

Quick note here: I was looking into how Datastax runs through their architecture - and they start at the cluster level, then dive into the node level. Food for thought on whether or not this format makes more sense.

from docs.

@dianasaur323, can you link to the Datastax material you were looking at?

from docs.

@jseldess it was actually a introduction to cassandra video they have on their website. You need to create an account to view it. Honestly, it was all very very high level. It's part of video 2. https://academy.datastax.com/courses/ds101-introduction-cassandra/ I think we can come up with a couple different formats on how to approach this during our post-it note session as well?

from docs.

@jseldess Is it possible to make this issue private? I didn't realize this issue was one in the docs repo.

from docs.

Copied the contents of this issue into https://github.com/cockroachlabs/website/issues/8. Let's continue there.

from docs.