1
00:00:00,480 --> 00:00:02,620
‫What is going on, guys?

2
00:00:02,640 --> 00:00:10,560
‫My name is Hossein, and this video I want to discuss, I caution that some of you asked me when do

3
00:00:10,590 --> 00:00:13,080
‫I shahade my database?

4
00:00:13,920 --> 00:00:17,610
‫And short answer for those who are impatient.

5
00:00:19,060 --> 00:00:23,980
‫Last thing you want to do is the Shard, your database, there are so many other things that you can

6
00:00:23,980 --> 00:00:27,820
‫do before complicating your life with.

7
00:00:28,750 --> 00:00:32,710
‫So with that said, let's just jump into it, guys.

8
00:00:33,460 --> 00:00:41,530
‫Sharding the idea of starting a database is I know it sounds that the that term sounds very sexy.

9
00:00:41,560 --> 00:00:42,210
‫Arrives as I.

10
00:00:42,220 --> 00:00:48,910
‫Oh, I'm sure magnetic resonance makes you sound intelligent, but if you think about what you're doing

11
00:00:48,910 --> 00:00:56,710
‫with Sharding, it is a very complex architecture and complex operation to implement.

12
00:00:57,040 --> 00:00:57,370
‫So.

13
00:00:58,600 --> 00:01:06,490
‫In order to talk about Shardey, as you have so many other things you can optimises, like why are you

14
00:01:06,490 --> 00:01:07,600
‫doing it to begin with?

15
00:01:07,600 --> 00:01:07,970
‫Right.

16
00:01:08,620 --> 00:01:09,010
‫So.

17
00:01:12,230 --> 00:01:20,720
‫Start over, you have a beautiful database, and I'm now talking about mostly relational databases,

18
00:01:20,720 --> 00:01:22,170
‫because that's my specialty.

19
00:01:22,310 --> 00:01:29,090
‫I very rarely work with no more SQL databases, but they work similarly.

20
00:01:30,140 --> 00:01:30,920
‫But here's the thing.

21
00:01:31,740 --> 00:01:37,980
‫And in relational databases, you have a single instance database, right, and you're probably building

22
00:01:37,980 --> 00:01:44,250
‫a Web application, so you need a Web server or an API framework such as Narges, Django, all that

23
00:01:44,250 --> 00:01:51,930
‫jazz go application, your custom application that essentially speaks HTTP protocol that talks to the

24
00:01:51,930 --> 00:01:55,680
‫browsers or some rest clients or.

25
00:01:56,720 --> 00:02:02,990
‫Any job, easy job, easy, but what is the thank you.

26
00:02:03,020 --> 00:02:03,410
‫Thank you.

27
00:02:03,590 --> 00:02:03,890
‫Yeah.

28
00:02:03,910 --> 00:02:09,470
‫So if you're anything that's basically SDB and you make requests and that request goes to the Web server

29
00:02:09,500 --> 00:02:18,050
‫and the Web server makes queries to the database and response gets her back responses and kind of changed

30
00:02:18,050 --> 00:02:22,910
‫the representation to something that the client understand could be JSON, XML, anything, and then

31
00:02:22,910 --> 00:02:24,130
‫ship it back to the client.

32
00:02:24,290 --> 00:02:26,190
‫That's their best representation.

33
00:02:26,300 --> 00:02:26,520
‫Right.

34
00:02:26,560 --> 00:02:27,710
‫Change the representation.

35
00:02:29,090 --> 00:02:29,510
‫All right.

36
00:02:29,510 --> 00:02:30,600
‫So that looks good.

37
00:02:31,640 --> 00:02:33,040
‫What's the problem with this?

38
00:02:33,530 --> 00:02:35,720
‫You get a lot of requests.

39
00:02:36,320 --> 00:02:38,090
‫A lot of people are reading.

40
00:02:38,180 --> 00:02:44,150
‫I say I was like, oh, I'm getting give me all these employees table or give me I'm reading this profile.

41
00:02:44,150 --> 00:02:45,800
‫I'm reading this for I'm reading this tweet.

42
00:02:45,800 --> 00:02:46,600
‫I'm reading this thing.

43
00:02:47,000 --> 00:02:52,550
‫So you're hitting that database a lot and you're reading a lot.

44
00:02:52,940 --> 00:03:00,020
‫Is it OK that you're reading from a table right at that table is large.

45
00:03:00,350 --> 00:03:05,330
‫It's getting large because you're inserting a lot of stuff in it has one million, two million, three

46
00:03:05,330 --> 00:03:09,680
‫million, four million twenty fourteen hundred million rows in it.

47
00:03:10,280 --> 00:03:15,890
‫And you might say Hosain doesn't matter because I have an index on it and that index is going to be

48
00:03:15,890 --> 00:03:16,790
‫smaller.

49
00:03:16,790 --> 00:03:17,200
‫Right.

50
00:03:17,360 --> 00:03:19,460
‫And I'm going to head to index because I'm smart.

51
00:03:19,850 --> 00:03:25,550
‫I am going to index the fields and I'm only creating based on those fields that are indexed.

52
00:03:25,760 --> 00:03:35,510
‫So my queries are fast, but then I can get you only so far because the larger the table gets, the

53
00:03:35,510 --> 00:03:43,530
‫larger the index gets and almost you're doing and full index can, which can also be slow.

54
00:03:43,940 --> 00:03:48,260
‫So the solution is not to just split everything into multiple servers.

55
00:03:49,230 --> 00:03:52,100
‫You're doing it, you're overengineering too early.

56
00:03:52,100 --> 00:03:56,900
‫And that's what the problem with most people are just overengineering too early.

57
00:03:56,900 --> 00:03:58,520
‫You can still do so much stuff.

58
00:03:58,520 --> 00:04:01,030
‫I hope you have this this is there a problem now, right?

59
00:04:01,190 --> 00:04:04,520
‫You have to identify with the problem first in order to solve it.

60
00:04:04,520 --> 00:04:08,700
‫You cannot just solve something that you don't know.

61
00:04:08,720 --> 00:04:09,740
‫The problem is right.

62
00:04:10,070 --> 00:04:11,180
‫Identify the problem.

63
00:04:11,180 --> 00:04:12,710
‫So let's say this is my problem.

64
00:04:13,040 --> 00:04:14,780
‫My reads are slow.

65
00:04:15,690 --> 00:04:17,120
‫I didn't say anything about right.

66
00:04:17,120 --> 00:04:20,690
‫Saslaw just reads because writing is always fast.

67
00:04:20,690 --> 00:04:29,240
‫You're in writing to the end of the table and even if you're using a B3 data structure index.

68
00:04:29,630 --> 00:04:30,260
‫Yeah.

69
00:04:30,380 --> 00:04:33,500
‫If you're using and it's this D that could be.

70
00:04:34,860 --> 00:04:40,830
‫Harmful for this is because you're rebalancing that tree sometimes if you're riding a lot, and that

71
00:04:40,830 --> 00:04:44,560
‫could cause some shifts in the desk at Stulz.

72
00:04:44,580 --> 00:04:49,110
‫Now, that is bad as Reed and LSM is optimized for Reed, but.

73
00:04:49,560 --> 00:04:49,890
‫Right.

74
00:04:49,890 --> 00:04:51,420
‫But that's another story.

75
00:04:51,810 --> 00:04:52,180
‫Right.

76
00:04:52,260 --> 00:04:53,970
‫So I'm reading a lot.

77
00:04:53,970 --> 00:04:59,610
‫Meile is getting slower and slower as long as it used to take one milliseconds now is like 20 and now

78
00:04:59,610 --> 00:05:00,910
‫it's 100 milliseconds.

79
00:05:01,620 --> 00:05:02,370
‫What do you do?

80
00:05:04,360 --> 00:05:05,920
‫Tables large, what do you do with it?

81
00:05:06,310 --> 00:05:09,750
‫There's something called most database's supports called partitioning.

82
00:05:10,630 --> 00:05:13,880
‫And I'm going to talk about just the horizontal partition.

83
00:05:13,930 --> 00:05:14,680
‫So imagine this.

84
00:05:14,800 --> 00:05:18,220
‫This is your table and I talk about horizontal and vertical partition.

85
00:05:18,250 --> 00:05:19,200
‫I'm going to reference the video here.

86
00:05:19,210 --> 00:05:19,810
‫Go check it out.

87
00:05:19,810 --> 00:05:24,040
‫But in a nutshell, you have a huge table, hundreds of millions of rows.

88
00:05:24,490 --> 00:05:28,750
‫You just slice it in half horizontally.

89
00:05:28,770 --> 00:05:31,180
‫That's that's the horizontally slice it in the middle.

90
00:05:31,480 --> 00:05:34,930
‫And you say this piece from this.

91
00:05:36,580 --> 00:05:44,380
‫I.D. to this ID go to this stable, right, and we're going to call this a partition and this idea to

92
00:05:44,380 --> 00:05:49,510
‫this idea goes to this table I'm going to go partition to and this this idea, this idea got to partition.

93
00:05:49,700 --> 00:05:56,770
‫So now you instead of having one table, you have three different tables that represent the whole logical

94
00:05:56,770 --> 00:05:57,340
‫table.

95
00:05:58,210 --> 00:06:07,300
‫But when you query, we can find out based on something called a partition key, which usually is that

96
00:06:07,330 --> 00:06:10,480
‫as the primary key of the table doesn't have to be there.

97
00:06:10,990 --> 00:06:15,160
‫But based on that, you can know which table to hit.

98
00:06:15,850 --> 00:06:19,500
‫Now you have smaller tables, you have 10 smaller tables.

99
00:06:20,020 --> 00:06:20,890
‫And guess what?

100
00:06:20,890 --> 00:06:28,480
‫With a little better knowledge from the client, we can know exactly which small table or partition

101
00:06:28,480 --> 00:06:28,860
‫to hit.

102
00:06:29,170 --> 00:06:36,190
‫And now I'm working with a smaller index and my queries will be fast instead of having this huge index.

103
00:06:36,430 --> 00:06:39,130
‫Now I have a smaller index and I know exactly where.

104
00:06:39,160 --> 00:06:40,000
‫Quite so.

105
00:06:40,000 --> 00:06:41,920
‫My queries are fast, just like that.

106
00:06:41,920 --> 00:06:45,100
‫By just enabling partitioning and most databases.

107
00:06:45,100 --> 00:06:50,260
‫Postgres, for example, does that blindly for you if you enable it.

108
00:06:50,440 --> 00:06:57,220
‫And the client doesn't have the even need the knowledge to know that, oh, I need to have this table

109
00:06:57,220 --> 00:06:58,150
‫table partition.

110
00:06:58,150 --> 00:06:58,720
‫Underscore what?

111
00:06:58,720 --> 00:07:04,630
‫No, it's just happened for you previously and all the releases you had to have this knowledge.

112
00:07:04,630 --> 00:07:06,600
‫Oh, this is the stable in the stable mistake.

113
00:07:06,910 --> 00:07:14,860
‫Remember, guys, I'm still in the same server as one instance, one database instance, but with little

114
00:07:14,860 --> 00:07:20,230
‫bit of a tweak of a feature of my database, I, I fix the problem.

115
00:07:22,120 --> 00:07:25,930
‫Right, you don't need charting when I talk about sharding in a minute.

116
00:07:25,960 --> 00:07:26,780
‫What does it really mean?

117
00:07:27,760 --> 00:07:28,180
‫But.

118
00:07:30,050 --> 00:07:39,110
‫You come back, you say, Hussein, no, that's not good, because, yes, I am, my singular reads

119
00:07:39,110 --> 00:07:45,200
‫are fast selecting staff from the stable and yet very fast now because I partition all that stuff.

120
00:07:45,530 --> 00:07:52,990
‫But my dad, a base server, cannot handle because all these TCP connection to a single server just

121
00:07:53,040 --> 00:07:53,720
‫read stuff.

122
00:07:54,080 --> 00:08:03,230
‫It's overwhelming my server and it's the file descriptors are blowing out of proportion and I cannot

123
00:08:03,230 --> 00:08:04,130
‫handle that anymore.

124
00:08:04,530 --> 00:08:04,800
‫Right.

125
00:08:05,690 --> 00:08:06,470
‫So what do you do?

126
00:08:06,720 --> 00:08:10,070
‫Well, I'm not even introducing the idea of caching.

127
00:08:10,070 --> 00:08:15,050
‫You can obviously introduce a layer of readiest cache and all that stuff, but.

128
00:08:16,040 --> 00:08:21,110
‫It comes with its own problems because you'll end up with inconsistency and you have to invalidate the

129
00:08:21,110 --> 00:08:23,960
‫cash and all that stuff, but you can't play with that.

130
00:08:25,040 --> 00:08:32,450
‫And without introducing that extra layer, I have some tricks up my sleeve to fix that problem.

131
00:08:32,670 --> 00:08:32,760
‫Right.

132
00:08:32,840 --> 00:08:40,140
‫And most of the stuff you guys know, it probably but application, why is nobody talking about this?

133
00:08:40,940 --> 00:08:43,430
‫You have a master backup.

134
00:08:43,700 --> 00:08:48,620
‫So and you some some databases have this by default.

135
00:08:48,660 --> 00:08:57,740
‫This this features where you have one master and create another server and make this server a backup

136
00:08:58,010 --> 00:09:05,570
‫of that master and what it will do as periodically the master will push the edits.

137
00:09:05,570 --> 00:09:05,950
‫Right.

138
00:09:05,960 --> 00:09:07,490
‫The rights to that.

139
00:09:08,380 --> 00:09:11,490
‫To the replica, to the back up, so you can create as many backup as you want.

140
00:09:12,830 --> 00:09:15,560
‫And multiple servers with partitions.

141
00:09:16,720 --> 00:09:17,230
‫And.

142
00:09:18,390 --> 00:09:27,510
‫Do all that stuff now, you segregated multiple servers, but you have one right to do a ride, you

143
00:09:27,510 --> 00:09:32,970
‫go to that dang server, you don't want to write in multiple servers.

144
00:09:32,970 --> 00:09:35,340
‫That will confuse a lot of things.

145
00:09:35,350 --> 00:09:39,120
‫And we're going to talk about it in a minute because reading is easier than writing.

146
00:09:39,870 --> 00:09:43,800
‫Reading is doesn't really cause conflicts or writing.

147
00:09:43,800 --> 00:09:46,300
‫If I'm writing to the same rule you.

148
00:09:46,410 --> 00:09:47,030
‫Yeah.

149
00:09:47,040 --> 00:09:48,270
‫In the seven different servers.

150
00:09:48,750 --> 00:09:49,580
‫Bad things happen.

151
00:09:49,860 --> 00:09:51,750
‫How do I reconcile these changes.

152
00:09:51,750 --> 00:09:52,040
‫Right.

153
00:09:52,090 --> 00:09:56,280
‫It just you can't solve it, but it becomes a very challenging problem to solve.

154
00:09:56,290 --> 00:09:59,170
‫So you want to avoid complex problems and why would you do it?

155
00:09:59,240 --> 00:10:03,000
‫Well, I'm gonna write to myself because my rights are not as bad.

156
00:10:03,030 --> 00:10:07,500
‫I don't I often barely write anything, but I read a lot.

157
00:10:07,890 --> 00:10:16,110
‫So you can just multiple servers, you have one master server and just push all that stuff to that.

158
00:10:16,960 --> 00:10:24,760
‫Replicas of the backup's and now your clients or the observers, but a reverse proxy, actually a proxy

159
00:10:24,760 --> 00:10:31,660
‫in Haertsch, anything you want and then start FUNNYE or you want to read, go to this database or,

160
00:10:31,660 --> 00:10:38,800
‫you know, read you get as the backup goes back up and now you're balancing the rights, but the rights

161
00:10:38,950 --> 00:10:45,370
‫still goes to this database that is the master and some people who will come says or know who.

162
00:10:45,630 --> 00:10:54,100
‫And you don't know me because I write a lot and I need to write a lot.

163
00:10:54,250 --> 00:11:03,070
‫And my single server that does the right no longer is sufficient is going to die because I write so

164
00:11:03,070 --> 00:11:03,340
‫much.

165
00:11:03,340 --> 00:11:03,700
‫Do it.

166
00:11:07,250 --> 00:11:16,520
‫Really doubt it first, because we're writing a lot, you will be writing a lot to saturate a single

167
00:11:16,520 --> 00:11:17,030
‫server.

168
00:11:17,720 --> 00:11:21,810
‫I'm assuming you have it big server that does that stuff right.

169
00:11:22,670 --> 00:11:25,370
‫But let's say you do your writing a lot.

170
00:11:25,670 --> 00:11:34,310
‫You still have some tracks before the final thing, which is Shati, you can do multiple replication,

171
00:11:34,730 --> 00:11:42,560
‫a two way replication, but have two masters on different regions in in in the US.

172
00:11:42,570 --> 00:11:43,940
‫This is very common.

173
00:11:44,180 --> 00:11:47,840
‫This is a U.S. E and this is a U.S. W.

174
00:11:48,230 --> 00:11:57,110
‫People from Florida writes to this server anything that has to do, customers with the with the E just

175
00:11:57,110 --> 00:12:01,190
‫deal with this, anything it has to do with custom of the West, deal with this and most of the time

176
00:12:01,190 --> 00:12:02,300
‫they don't overlap.

177
00:12:02,300 --> 00:12:02,720
‫Right.

178
00:12:03,620 --> 00:12:04,420
‫Really.

179
00:12:04,670 --> 00:12:10,610
‫So if you have this segregation, you use it to your advantage and then synchronization of this can

180
00:12:10,610 --> 00:12:14,350
‫happen very easily because you're barely going to have any conflict.

181
00:12:14,360 --> 00:12:15,850
‫And if you do, you're going to resolve it.

182
00:12:17,000 --> 00:12:25,490
‫And if this is so complex, you finally go and do sharding, which is the following sharding is the

183
00:12:25,490 --> 00:12:33,380
‫idea of having a single key C after all of these are exhausted.

184
00:12:34,360 --> 00:12:42,160
‫Right, come down and Lusardi, right, if and if all of this stuff is also done, goodo sharding,

185
00:12:42,160 --> 00:12:47,170
‫if none of them, then probably you don't have to do shonen because it's shorting is the most complicating

186
00:12:47,170 --> 00:12:48,540
‫thing to accomplish.

187
00:12:48,550 --> 00:12:53,850
‫And let's talk about what it's become easier these days, but let's talk about Sharding.

188
00:12:54,610 --> 00:12:56,290
‫So what is shocking?

189
00:12:56,290 --> 00:13:05,620
‫Sharding the idea of splitting like partition, like horizontal partitioning, but pull the tables that

190
00:13:05,620 --> 00:13:09,940
‫are partitioned, not in a single in a different table.

191
00:13:09,940 --> 00:13:12,480
‫In the same instance, same server.

192
00:13:12,790 --> 00:13:19,420
‫No, both those partitions or shards in a different server altogether.

193
00:13:19,870 --> 00:13:21,380
‫Wuk.

194
00:13:22,150 --> 00:13:22,780
‫Yeah.

195
00:13:25,070 --> 00:13:30,640
‫With partitioning, you can still do transaction, by the way, guys, the database supports transactions.

196
00:13:30,980 --> 00:13:38,900
‫Well, short thing for for what Sharding was sharding my, my, my tongue has been swallowed.

197
00:13:39,740 --> 00:13:40,880
‫Will sharding.

198
00:13:40,880 --> 00:13:42,550
‫You can all do transactions.

199
00:13:42,860 --> 00:13:44,450
‫Forget about transactions.

200
00:13:45,940 --> 00:13:46,870
‫Bye bye.

201
00:13:47,110 --> 00:13:52,820
‫Roll back all this beautiful comet stuff, as I said, at Tomasetti.

202
00:13:53,290 --> 00:13:53,860
‫Bye bye.

203
00:13:54,010 --> 00:13:55,160
‫No sharding for you.

204
00:13:55,180 --> 00:13:59,680
‫You cannot do all this because what do you do if you want to try to multiple shots?

205
00:13:59,710 --> 00:14:01,210
‫This is different servers, right.

206
00:14:02,200 --> 00:14:05,650
‫And you cannot maintain the asset transactions.

207
00:14:05,680 --> 00:14:12,070
‫I know some people don't like as a transaction and the favor the others with eventual consistency.

208
00:14:12,070 --> 00:14:15,550
‫But the old school kind of a guy.

209
00:14:17,050 --> 00:14:17,590
‫All right.

210
00:14:17,590 --> 00:14:26,920
‫So so what do you do is I am about to update customer number hundred and does the phone number 100,

211
00:14:27,040 --> 00:14:30,300
‫you say, OK, the client, you are the client, which is the world.

212
00:14:30,350 --> 00:14:32,260
‫So observer in this case is OK.

213
00:14:32,500 --> 00:14:36,820
‫Customer number one is between hundred, between one and ten thousand.

214
00:14:36,820 --> 00:14:42,490
‫So yeah, as server number one, let me establish the ECB connection with our number one and execute

215
00:14:42,490 --> 00:14:44,110
‫that right or the right.

216
00:14:44,450 --> 00:14:44,710
‫Right.

217
00:14:45,760 --> 00:14:48,790
‫And and you received another request.

218
00:14:48,790 --> 00:14:57,070
‫But this request has to do with customer number ten thousand and seventeen or seventeen is between 10000

219
00:14:57,070 --> 00:14:58,270
‫and 20000.

220
00:14:58,270 --> 00:15:05,440
‫And based on my sharding, arrange this a server to subject this connection to the server to and executed

221
00:15:05,590 --> 00:15:06,730
‫and come back and result.

222
00:15:07,180 --> 00:15:15,130
‫And yep, you might say, yeah, I'm going to use Pawling because I don't want to establish this connection

223
00:15:15,130 --> 00:15:20,140
‫every time Endris and I, I absolutely agree with you have to use pooling.

224
00:15:20,140 --> 00:15:22,840
‫You don't have to do this cold start of chickpeas.

225
00:15:23,140 --> 00:15:28,510
‫Hopefully one database platform will get to use quick and all this problems will go away and they could

226
00:15:28,510 --> 00:15:30,790
‫start and all that stuff, but.

227
00:15:32,710 --> 00:15:33,250
‫Yeah.

228
00:15:34,410 --> 00:15:41,310
‫Sharding is very complex, that logic that we just talked about is in your client application.

229
00:15:43,210 --> 00:15:44,830
‫That's hard, right?

230
00:15:45,370 --> 00:15:49,720
‫It's very hard because I made a video about Sharding guys and actually show you how it's done.

231
00:15:50,200 --> 00:15:50,890
‫Check it out here.

232
00:15:51,730 --> 00:15:53,850
‫But what do you do, guys?

233
00:15:54,190 --> 00:15:54,510
‫Right.

234
00:15:54,520 --> 00:16:03,010
‫This is do you do you really want to do this with your life and sacrifice rollbacks and comments and

235
00:16:03,010 --> 00:16:08,530
‫transactions and all this stuff just to do a stinking sharding?

236
00:16:08,950 --> 00:16:09,670
‫Just to do what?

237
00:16:09,670 --> 00:16:10,360
‫Scaling.

238
00:16:10,600 --> 00:16:12,050
‫You want to scale the rights?

239
00:16:12,400 --> 00:16:18,340
‫I agree it's beneficial, but sometimes it's an overkill.

240
00:16:18,370 --> 00:16:19,680
‫You get a really neat thing.

241
00:16:19,780 --> 00:16:21,520
‫Do you really need to, Shahd?

242
00:16:22,090 --> 00:16:22,520
‫Right.

243
00:16:24,250 --> 00:16:24,720
‫All right.

244
00:16:25,300 --> 00:16:34,000
‫That being said, YouTube ran into this problem, as you might as you might think, because YouTube

245
00:16:34,000 --> 00:16:34,320
‫is a.

246
00:16:35,330 --> 00:16:43,610
‫Millions, millions of videos which would billions of watch hours and hours uploaded, right, so thousands

247
00:16:43,610 --> 00:16:51,020
‫and thousands of hours are uploaded to this platform and comments and and I watched listen to a podcast

248
00:16:51,260 --> 00:16:54,440
‫with the lead of YouTube talking about how they solved it.

249
00:16:54,470 --> 00:16:56,780
‫They have a MySQL database on the back.

250
00:16:56,780 --> 00:16:58,400
‫And by the way, they manage all that stuff.

251
00:16:58,610 --> 00:17:01,940
‫And the videos are, I believe in I forgot where it is.

252
00:17:01,950 --> 00:17:02,660
‫Maybe it's three.

253
00:17:02,660 --> 00:17:03,440
‫I might be wrong there.

254
00:17:04,460 --> 00:17:06,620
‫Before that was before Google acquired it and all.

255
00:17:06,620 --> 00:17:07,190
‫That's not right.

256
00:17:07,190 --> 00:17:11,650
‫So they moved everything to YouTube, to Google infrastucture and all that stuff.

257
00:17:11,660 --> 00:17:19,370
‫But they for a long time they had a single MySQL server and they managed to do fine until the rights

258
00:17:19,370 --> 00:17:22,430
‫became absolutely disastrous.

259
00:17:22,760 --> 00:17:28,220
‫So they started doing what we talked about and until they couldn't handle.

260
00:17:28,220 --> 00:17:30,300
‫So they had to do Chardy, which is called.

261
00:17:30,320 --> 00:17:32,180
‫What we talk about is application level.

262
00:17:32,180 --> 00:17:39,560
‫Schoening, the application is aware of the Shahd, which is this piece of the partition, OK?

263
00:17:40,910 --> 00:17:47,560
‫And when you know, when you are aware that's a problem because you create a coupling and coupling is

264
00:17:47,570 --> 00:17:53,960
‫the worst thing you want in software because you want software to be as isolated as possible.

265
00:17:54,200 --> 00:18:01,070
‫You want software to have social anxiety, social distancing in these days through social distancing

266
00:18:01,070 --> 00:18:07,520
‫for software like Gabrielsson software apart, they shouldn't know stuff about each other.

267
00:18:08,120 --> 00:18:10,040
‫That's just a general idea about separate.

268
00:18:10,070 --> 00:18:11,840
‫Coupling is bad about software.

269
00:18:13,110 --> 00:18:19,410
‫Come back now, what they did, it's like they had this application level story for a long time and

270
00:18:19,410 --> 00:18:20,790
‫says, look, this is ridiculous.

271
00:18:20,790 --> 00:18:27,630
‫We cannot maintain this because if they want to change some logic and everything breaks, right, they

272
00:18:27,630 --> 00:18:34,110
‫want to forget about regarding the idea of rationing is like, oh, okay, I want to change the range

273
00:18:34,110 --> 00:18:36,450
‫from ten thousand because ten thousand is really low.

274
00:18:36,660 --> 00:18:38,910
‫Let's make it hundred thousand.

275
00:18:39,060 --> 00:18:39,380
‫Right.

276
00:18:39,390 --> 00:18:41,020
‫Each card has 100000 rolls.

277
00:18:41,050 --> 00:18:42,750
‫Oh, forget about that.

278
00:18:42,760 --> 00:18:46,560
‫Nobody can do that because I will break every single client.

279
00:18:46,770 --> 00:18:49,710
‫You've got to go to that client and yeah.

280
00:18:49,770 --> 00:18:50,540
‫So it's complicated.

281
00:18:50,580 --> 00:18:54,360
‫So they created this technology called Vitez and I'm going to reference it here.

282
00:18:54,510 --> 00:19:01,650
‫And the test is essentially a middleware that you send your query on top of my school and it's I believe

283
00:19:01,650 --> 00:19:05,370
‫it's open source and it's Cuban and Israelis and all that jazz.

284
00:19:05,670 --> 00:19:14,040
‫And you put it on your MySQL architecture and is going to do the magic sharding for you.

285
00:19:14,430 --> 00:19:21,360
‫And that is awesome, because you send a beautiful school query and they pass that query and they understand

286
00:19:21,360 --> 00:19:23,010
‫what charge to hit.

287
00:19:23,550 --> 00:19:30,870
‫And you don't need anything better than that if you absolutely need, because nothing's for free.

288
00:19:31,110 --> 00:19:38,370
‫If you want if you have the maintenance cost of implementing the test, go ahead and do it.

289
00:19:39,060 --> 00:19:41,190
‫Any technology you implement there is a cost for it.

290
00:19:41,850 --> 00:19:43,530
‫If you're ready, go ahead.

291
00:19:43,980 --> 00:19:47,910
‫But ask yourself, do you really need it?

292
00:19:48,480 --> 00:19:50,580
‫Sometimes you do not need it.

293
00:19:50,970 --> 00:19:56,250
‫I was an awful British accent impression.

294
00:19:57,840 --> 00:19:59,840
‫All right, guys, that's it for me today.

295
00:19:59,880 --> 00:20:04,140
‫We're all learning we're going to learn a lot and keep learning, guys.

296
00:20:04,470 --> 00:20:06,020
‫I see in the next one by.