This document discusses how to scale relational databases by sharding. Sharding involves partitioning or splitting large databases across multiple machines to improve performance and allow for unlimited scaling. The key aspects of sharding covered are: - Sharding partitions data into independent chunks that can be placed on separate hardware resources. Each partition functions as its own database. - Various sharding techniques exist like sharding by a hash of the primary key, by ranges of primary keys, or by other columns. The choice depends on query patterns. - Sharding allows scaling simply by adding more hardware resources without replacing existing systems. It provides high availability since the failure of one shard does not impact the entire database.

1. Session ID:
Prepared by:
How to scale relational databases ?
Think: Sharding
4829
Maxym Kharchenko
Gluent.com

2. Whoami
• Started as a database kernel developer
• Then: ORACLE DBA for 15+ years
• Now: Developer at Gluent (past: amazon.com)
• OCM, ORACLE Ace Associate, AWS Developer
• Blog: intermediatesql.com
• Twitter: @maxymkh

3. The cool things that we do at Gluent
3
Gluent
Oracle
Teradata
NoSQL
Big Data
Sources
MSSQL
App
X
App
Y
App
Z
We glue these
worlds together!

4. The cool things that we do at Gluent

5. Relational databases are best for OLTP,
because they are ACID
Unfortunately,
relational databases cannot scale
Conventional wisdom

6. Riding Moore’s Law
(a.k.a: “traditional” database scaling)
2013 2014 2015 2016 2017
HW
overrun
here !
You are
here !

7. Traditional database scaling
Old System
New System
2013 2014 2015 2016 2017
Replace
HW
here !

8. But now: Data grows faster!
Old System
New System
2013 2014 2015 2016 2017

9. Moore’s Law:
The future ain’t what it used to be!
Old System
New System
2013 2014 2015 2016 2017

10. Let’s move the database to a bigger box

11. Scaling up …

12. Scaling up …

13. Scaled!

14. One machine is just not enough anymore

15. Use more machines

16. So, why don’t we use RAC ?

17. So, why don’t we use RAC ?

18. So, why don’t we use RAC ?

19. Clusters are hard

20. Clusters are hard
And expensive
- Need top-of-the-line HW
- And super smart engineers
- And additional license $$$$$$$$$

21. Solution: Shared nothing architecture
a.k.a. “Sharded”

22. Sharded architecture in a nutshell
=
$$$$$ $$

23. Split your data into small
independent chunks
Run each chunk
on cheap commodity hardware

24. The Basics

25. Sharding is, basically, partitioning

26. Sharding is, basically, partitioning

27. Except, each “partition” is a database

28. Practical table design for sharding

29. Let’s “shard” a simple table
CREATE TABLE books (
id number PRIMARY KEY,
title varchar2(200),
author varchar2(200)
);

30. CREATE TABLE books (
id number PRIMARY KEY,
title varchar2(200),
author varchar2(200)
) SHARD BY <method> (<shard_key>) (
SPLIT SIZE evenly
SPLIT LOAD evenly
PREFER SINGLE SHARD ACCESS
DISCOURAGE DATA MOVE
USING <N> DATABASES
);
Let’s “shard” a simple table
Not a “real”
ORACLE command
(yet) 

31. Hey, let’s shard it by “name” range
SHARD BY LIST (first_letter(author))
(
…
SPLIT SIZE evenly
);
A-G
H-M N-T
U-Z

32. Hey, let’s shard it by “id” range
SHARD BY RANGE (id) (
…
SPLIT LOAD evenly
);
1-100 101-200 201-300 301-400

33. Hashes are your friend
SHARD BY HASH (id) (
SPLIT SIZE evenly
SPLIT LOAD evenly
);

34. But (especially for OLTP)
be sure to chose the right hash column
SHARD BY HASH (id) (
PREFER SINGLE SHARD ACCESS
);
SELECT title FROM books
WHERE id = 34567876;

35. But (especially for OLTP)
be sure to chose the right hash column
SHARD BY HASH (id) (
PREFER SINGLE SHARD ACCESS
);
SELECT title FROM books
WHERE author = 'Isaac Asimov'
ORDER BY title;

36. SHARD BY HASH (author) (
PREFER SINGLE SHARD ACCESS
);
0 1 2 3
SELECT title FROM books
WHERE author = 'Isaac Asimov'
ORDER BY title;
But (especially for OLTP)
be sure to chose the right hash column

37. Think about eventual re-sharding
SHARD BY hash(author) (
DISCOURAGE DATA MOVE
USING 4 DATABASES
);
0 1 2 3

38. Think about eventual re-sharding
SHARD BY mod(hash(author), 4) (
DISCOURAGE DATA MOVE
);
0 1 2 3

39. Discourage data move
SHARD BY mod(hash_function(author), 6)(
DISCOURAGE DATA MOVE
);
0 1 2 3
4 5

40. Major resharding is a PITA
Hash Mod/4
1 1
2 2
3 3
4 0
5 1
6 2
7 3
8 0
9 1
10 2
11 3
12 0
Hash Mod/4 Mod/6
1 1 1
2 2 2
3 3 3
4 0 4
5 1 5
6 2 0
7 3 1
8 0 2
9 1 3
10 2 4
11 3 5
12 0 0

41. Solution: Logical shards
SHARD BY mod(hash(author), 1200) (
DISCOURAGE DATA MOVE
);
DB 1 DB 2 DB 3 DB 4

42. Solution: Logical shards
SHARD BY mod(hash(author), 1200) (
DISCOURAGE DATA MOVE
);
DB 1 DB 2 DB 3 DB 4
DB 5

43. Accessing your sharded data

44. Which database ?
SELECT title FROM books
WHERE author = 'Isaac Asimov'

45. Which database ?
SELECT title FROM books
WHERE author = 'Isaac Asimov'
Hash(author)
Lookup (hash)

46. Executing the query
def shard_query(sql, binds, shard_key):
""" Execute query in the correct db
"""
shard_hash = hash(shard_key)
logical_bucket = mod(shard_hash, TOTAL_BUCKETS)
physical_db = memcached_get_db(logical_bucket)
execute_query(physical_db, sql, binds)

47. Sharding your ORACLE data

48. Standbys
Unsharded StandbyShard 1 Shard 2
Apps
Read Only
Drop non-qualifying data Drop non-qualifying data

49. MViews
Shard1
Apps
Tab
A
Shard 2
MV
A
Tab
A
Create materialized
view …
as select …
from a@shard1
Drop
materialized view
…
preserve table
Read Only

50. Moving “data head”
Shard 1
Apps
Shard 2
Logical
Shard
Physical
Shard
(1,2,3,4) 1
(5,6,7,8) 2

51. Time Logical
Shard
Physical
Shard
2015(1,2,3,4) 1
2015(5,6,7,8) 2
Shard 1
Apps
Shard 2
Moving “data head”

52. Time Logical
Shard
Physical
Shard
2015(1,2,3,4) 1
2015(5,6,7,8) 2
2016(1,2) 1
2016(3,4) 3
2016(5,6) 2
2016(7,8) 4
Shard 2
Apps
Shard 3 Shard 4Shard 1
Moving “data head”

53. So, why shard ? Money!

54. Why shards are awesome
• (potentially) Unlimited scaling
– 100s or 1000s of shards “in range”
• Once routed in, “it’s pure ORACLE”:
– Transactions, ACID, foreign keys etc
• Better maintenance:
– Smaller data, smaller load
• Eggs not in one basket:
– Even if a shard is down, “most of the system” is still up
• “Apples to apples comparison” with other shards

55. Why shards are NOT so great
• More systems
– Power, rack space etc
– Needs automation … bad
– More likely to fail overall
• Some operations become difficult:
– Transactions across shards
– Foreign keys across shards
• More work:
– Applications, developers, DBAs
– High skill, DIY everything

56. Thank you!
Please, evaluate my session: 4829
maxym@gluent.com
Twitter: @maxymkh

57. Extras

58. Data to be “sharded” has to be simple

59. Your data has to be “simple”
Think this Not that

60. Not simple

61. Categorize your data

62. Then, take it apart

63. This is also known as splitting
“by Nouns” or “by Verbs”

64. Your data is ready for sharding
When it looks
like this
Or like this
(at the most)