Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles of Sharding for Relational Databases

citusdata.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Principles of Sharding for Relational Databases

#21

Post by freels »

brianwawok wrote: post #12
jchanimal wrote: post #7

Earlier quoted context omitted.

There is a new generation of relational databases that are native to multi-node operation, and don't require sharding. I'm speaking of tech like Google Spanner and my employer, FaunaDB. Now you don't have to shard. More info on how we accomplish distributed transactions. https://fauna.com/blog/distributed-consistency-at-scale-span...

P.S. Google Spanner and FaunaDB both shard. They can call it something else. But unless every node has all data on it, it is sharded.

It is true that Spanner and FaunaDB partition a cluster's dataset across multiple nodes but it's handled transparently by the database. Whenever I've heard the term "sharding" it's usually in reference to the application-level sharding described in the article.

Partitioning the dataset isn't really novel these days (Cassandra, Riak, Mongo et al do the same of course), but what is a significant difference is that both Spanner and FaunaDB implement ACID transactions distributed across partitions. It no longer matters for application correctness what partition key you choose if you can involve any arbitrary set of records in an single transaction.

Re: Principles of Sharding for Relational Databases

#22

Post by morgo »

AznHisoka wrote: post #4

I find the "you don't want to shard" camp quite annoying. Of course, I don't want to shard! Who does?! It adds complexity, both implementation-wise and operational. But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

I'm the original author of the linked post you refer to.

Perhaps the title is click bait, but at the time I was meeting with a lot of users looking for someone else's problems.

5TB could still easily be single server territory. It depends more on the queries.

My point is just that some workloads are better solved with (some) vertical scaling first.

Re: Principles of Sharding for Relational Databases

#23

Post by novembermike »

dboreham wrote: post #18
jchanimal wrote: post #7

Earlier quoted context omitted.

There is a new generation of relational databases that are native to multi-node operation, and don't require sharding. I'm speaking of tech like Google Spanner and my employer, FaunaDB. Now you don't have to shard. More info on how we accomplish distributed transactions. https://fauna.com/blog/distributed-consistency-at-scale-span...

_You_ don't have to, but someone does.

Right, but it's the default state of the database.

Re: Principles of Sharding for Relational Databases

#24

Post by berns »

jchanimal wrote: post #7
AznHisoka wrote: post #4

I find the "you don't want to shard" camp quite annoying. Of course, I don't want to shard! Who does?! It adds complexity, both implementation-wise and operational. But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

There is a new generation of relational databases that are native to multi-node operation, and don't require sharding. I'm speaking of tech like Google Spanner and my employer, FaunaDB. Now you don't have to shard. More info on how we accomplish distributed transactions. https://fauna.com/blog/distributed-consistency-at-scale-span...

The title tag of Spanner home page reads: Cloud Spanner | Automatic Sharding with Transactional Consistency at Scale

Re: Principles of Sharding for Relational Databases

#25

Post by quantumf »

ozgune wrote: post #8
rsolari wrote: post #3

Earlier quoted context omitted.

Thanks for writing the post. Sharding is something I’m consudering at my current job. How long do these sharding projects usually take? Do you know of any posts that break down the steps in more detail?

Timeframes for sharding projects vary quite a bit. If you have a B2B database, we find that sharding projects usually take between one to eight weeks of engineering (not clock) time. Most take two to three weeks. A good way to tell is by looking at your database schema. If you have a dozen tables, you'll likely migrate with one week's of effort. If your database has 250+ tables, then you'll take about eight weeks. Wh…

I think you're understating how tough it can be.

There are applications that

  * are mature and complex

  * with 100s of tables

  * serving millions of users

  * have to be broken into multiple micro-services

  * have developer resource constraints
So you're easily looking at a 1-2 year project, not 1-8 weeks.

You've also ignored some of the complexities, such as resharding (moving data between shards), which may significantly add to the cost of the project.

Re: Principles of Sharding for Relational Databases

#26

Post by sigstoat »

AznHisoka wrote: post #4

I find the "you don't want to shard" camp quite annoying. Of course, I don't want to shard! Who does?! It adds complexity, both implementation-wise and operational. But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

http://www.fixstars.com/en/ssd/ ?

if all you need is a lot of data in a single database, there's basically nothing except for money between you and your goal. JBODs full of SSDs coming into a single machine via SAS will get you into petabytes, just with commodity hardware you can order from amazon.

i'm expect IBM could sell you a mainframe that'll do it for whatever capacity you care to name.

Re: Principles of Sharding for Relational Databases

#27

Post by gnaritas »

AznHisoka wrote: post #4

I find the "you don't want to shard" camp quite annoying. Of course, I don't want to shard! Who does?! It adds complexity, both implementation-wise and operational. But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

> But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

Drive capacity in a server is not limited to the size of a single drive. You can build a raid array any size you like by simply adding more drives.

Re: Principles of Sharding for Relational Databases

#28

Post by gnaritas »

metaphorm wrote: post #17
grw_ wrote: post #11

Earlier quoted context omitted.

Sorry if this is obvious, but why not use multiple drives?

because that is nearly a synonym for sharding? or did you mean just use a large capacity RAID setup? that will probably work fine for a lot of situations but it can expensive and introduce more latency for certain types of operations (but that might not matter, depends on context).

It's a server, you don't put databases on non RAID drives anyway, that'd be silly as the loss of a single drive would lose all your data. RAID setup isn't an option, it's how things are done by default for servers in order to ensure redundancy against a single disk failure.

Re: Principles of Sharding for Relational Databases

#29

Post by kakwa_ »

zbobet2012 wrote: post #20
AznHisoka wrote: post #4

I find the "you don't want to shard" camp quite annoying. Of course, I don't want to shard! Who does?! It adds complexity, both implementation-wise and operational. But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

You can _easily_ buy a box with 60+TB of SSD... http://www.dell.com/en-us/work/shop/povw/poweredge-r930 Some of us do need to shard for sure though (I have multi petabyte data sets).

Storing 60+TB of data is different than searching and doing complex computation on 60TB of data.

Also, operations on a such huge data set can be really painful. Think how to backup a DB like that safely, or how to update the engine.

Some slides (little old, 2014) about a huge postgres instance serving as a backend for leboncoin.fr (main classified advertising website in France).

https://fr.slideshare.net/jlb666/pgday-fr-2014-presentation-...

Basically, they bought the best hardware money could buy at the time to scale vertically, they, in the end, run in some issues and started thinking about sharding this huge DB.

Re: Principles of Sharding for Relational Databases

#30

Post by ttt111222333 »

ozgune wrote: post #2

Hey everyone, it's Ozgun. When I first wrote this blog post, it was much longer. Based on initial feedback, I edited out parts of it to keep the post focused. If you have any questions that aren't covered in the post, happy to answer them here!

> On the benefits side, when you separate your data into groups this way, you can’t rely on your database to join data from different sources or provide transactions and constraints across data groups.

How is it a benefit that you are no longer able to join data in your separate tables? Is this sentence a mistake?

Post reply on HN