﻿1
00:00:00,120 --> 00:00:00,790
‫About koans.

2
00:00:00,810 --> 00:00:02,010
‫Is there anything bad on this?

3
00:00:02,040 --> 00:00:05,390
‫Well, you saw you saw that go guys.

4
00:00:05,550 --> 00:00:07,470
‫See how complex our clients get.

5
00:00:07,650 --> 00:00:13,530
‫It's so complicated that clients becomes very complicated because they are aware of this sharding thing

6
00:00:13,530 --> 00:00:18,770
‫and they need to know is like, oh, this is what is in this chart and this input is in this jar.

7
00:00:18,780 --> 00:00:21,390
‫Well, you can use consistent hatcheting to hide that.

8
00:00:21,390 --> 00:00:25,140
‫But still, the awareness of the shot has become really complicated.

9
00:00:25,140 --> 00:00:31,320
‫As you start building a huge application, this becomes really nasty, becomes really nasty to have

10
00:00:31,320 --> 00:00:33,870
‫a complex complexity into the client.

11
00:00:33,880 --> 00:00:41,550
‫So the tests, which I think I'm going to make a video about to take from YouTube that allows you to

12
00:00:41,550 --> 00:00:45,930
‫do sharding on the spot and it's hitting from me.

13
00:00:45,930 --> 00:00:51,090
‫It's a back and shouting and the client just makes the way and does the sharding for you, which is

14
00:00:51,090 --> 00:00:52,350
‫pretty cool tech.

15
00:00:52,590 --> 00:00:52,990
‫Right.

16
00:00:53,130 --> 00:00:55,410
‫So that's that's potentially going to talk about that.

17
00:00:56,130 --> 00:00:58,260
‫Transactions across Shahd is a problem.

18
00:00:58,380 --> 00:01:01,730
‫How do I do like to insource.

19
00:01:01,740 --> 00:01:04,290
‫That happened to have two on the two tables.

20
00:01:04,310 --> 00:01:04,630
‫Right.

21
00:01:04,740 --> 00:01:10,500
‫And I want them to do a atomically that's almost impossible because way you're essentially doing two

22
00:01:10,710 --> 00:01:16,410
‫two database transactions, two separate database atomic transactions.

23
00:01:16,470 --> 00:01:17,520
‫It's almost impossible.

24
00:01:17,520 --> 00:01:18,600
‫It's very hard to do.

25
00:01:19,140 --> 00:01:22,790
‫So you can't do transactions very effectively with Sharding Ram.

26
00:01:23,070 --> 00:01:23,420
‫Right.

27
00:01:23,610 --> 00:01:26,160
‫I mean, if you do it on the same show, that's yes.

28
00:01:26,160 --> 00:01:26,970
‫You can do that.

29
00:01:27,420 --> 00:01:28,650
‫Rollbacks are very hard.

30
00:01:28,650 --> 00:01:32,680
‫Let's just say, oh, I want to insert in this table and then I want to insert in detail.

31
00:01:32,700 --> 00:01:33,960
‫But something bad happened.

32
00:01:33,960 --> 00:01:35,130
‫Let's roll back everything.

33
00:01:35,130 --> 00:01:36,540
‫Well, what does that mean?

34
00:01:36,540 --> 00:01:42,720
‫You're going to rollback this transaction, also rollback the other transaction, despite it being one

35
00:01:42,720 --> 00:01:45,930
‫logical transaction, complicating stuff.

36
00:01:45,930 --> 00:01:46,320
‫Right.

37
00:01:46,590 --> 00:01:49,890
‫Roll back some very hard schema changes.

38
00:01:49,890 --> 00:01:55,410
‫Let's say I want to add another feel to my your RL table, I don't know, date or something.

39
00:01:55,650 --> 00:02:01,500
‫I have to add it in all the Shah like I make a change in all the shards and you can just roll through

40
00:02:01,500 --> 00:02:03,840
‫all this change slowly if you want to.

41
00:02:03,840 --> 00:02:11,250
‫But it's a little bit dangerous if you miss adding one schema and one shard, but you add it to the

42
00:02:11,250 --> 00:02:11,970
‫other shards.

43
00:02:12,360 --> 00:02:15,660
‫Joynes I've no idea how to do joins code database.

44
00:02:15,670 --> 00:02:16,930
‫Is that even possible.

45
00:02:17,100 --> 00:02:17,490
‫Right.

46
00:02:17,760 --> 00:02:19,380
‫It just becomes very hard to do.

47
00:02:19,380 --> 00:02:20,210
‫Joynes right.

48
00:02:20,220 --> 00:02:23,670
‫That's why you might use horizontal partition instead of sharding.

49
00:02:24,030 --> 00:02:30,060
‫So your stuff that's one benefit are horizontal partitioning, not human resources.

50
00:02:30,360 --> 00:02:30,720
‫Right.

51
00:02:31,050 --> 00:02:37,450
‫So so you essentially have the two tables in the same database and then you can join them.

52
00:02:37,460 --> 00:02:37,680
‫Right.

53
00:02:37,790 --> 00:02:45,150
‫Instead of having the tables across multiple databases and how that sort of thing has to be something.

54
00:02:45,150 --> 00:02:46,170
‫You know, Nicoya.

55
00:02:46,170 --> 00:02:53,370
‫So if you're if you're querying for something, the key, the partition key, the shot in key in our

56
00:02:53,370 --> 00:02:55,110
‫case was that you are elide.

57
00:02:55,530 --> 00:02:56,550
‫That's what we know.

58
00:02:56,550 --> 00:02:56,970
‫Right.

59
00:02:57,090 --> 00:02:59,640
‫And that's based on that we know which database to hit.

60
00:02:59,640 --> 00:03:05,270
‫But what what what if I want to query on some other field that I have no knowledge on?

61
00:03:05,670 --> 00:03:11,010
‫So that is expensive because now you have no knowledge, you don't have the key.

62
00:03:11,250 --> 00:03:21,080
‫So you forced to hit all the databases to know which key right where where this data reside as an example

63
00:03:21,080 --> 00:03:28,950
‫would be like if you have a customer West and customer E on two shards and you searching by name, Aflac

64
00:03:29,790 --> 00:03:31,470
‫name has nothing to do with short.

65
00:03:31,470 --> 00:03:33,140
‫So you have to query both shards.

