2
00:00:06,133 --> 00:00:10,467
о том, чего стоило нам масштабировать YouTube.

3
00:00:10,467 --> 00:00:12,200
Но поскольку у нас есть только пол часа,

4
00:00:12,200 --> 00:00:14,634
то слишком углубиться в подробности я не смогу.

5
00:00:14,634 --> 00:00:16,767
Но некоторое представление о том,

6
00:00:16,767 --> 00:00:19,367
чего нам стоило создать

7
00:00:19,367 --> 00:00:22,634
один из крупнейших сервисов в мире - вы получите.

8
00:00:22,634 --> 00:00:25,267
Итак схема моего доклада будет примерно такой - 

9
00:00:25,267 --> 00:00:27,534
сначала немного поговорим в историческом контексте,

10
00:00:27,534 --> 00:00:28,868
в качестве введения.

11
00:00:28,868 --> 00:00:31,067
Затем о масштабируемости.

12
00:00:31,067 --> 00:00:32,767
О том, с какими проблемами столкнулись,

13
00:00:32,767 --> 00:00:36,968
какие уроки вынесли, а в конце перейдем к вопросам и ответам.

14
00:00:36,968 --> 00:00:39,501
Этот график--

15
00:00:39,501 --> 00:00:41,334
Вы часто могли видеть график такой формы.

16
00:00:41,334 --> 00:00:44,834
В контексте этой презентации данный график может 

17
00:00:44,834 --> 00:00:47,334
представлять несколько вещей.

18
00:00:47,334 --> 00:00:49,701
Возможно--

19
00:00:49,701 --> 00:00:52,200
Возможно он отображает цену за литр бензина,

20
00:00:52,200 --> 00:00:54,067
но я не собираюсь про это рассказывать.

21
00:00:54,067 --> 00:00:57,434
В google хорошо кормят, поэтому--

22
00:00:57,434 --> 00:00:59,601
Это правда,

23
00:00:59,601 --> 00:01:01,033
но и об этом я не стану говорить.

24
00:01:01,033 --> 00:01:04,601
Я всё еще страдаю от этого.

25
00:01:04,601 --> 00:01:07,934
На самом деле график показывает 

26
00:01:07,934 --> 00:01:11,968
количество ежедневных просмотров в течение жизни сервиса.

27
00:01:11,968 --> 00:01:15,133
Мы показали замечательный рост.

28
00:01:15,133 --> 00:01:16,601
Интересно, как в некоторых точках,

29
00:01:16,601 --> 00:01:19,367
когда мы добавляли больше машин или чего-либо,

30
00:01:19,367 --> 00:01:22,000
увеличивали пропускную способность, ускоряли сервис,

31
00:01:22,000 --> 00:01:24,367
или добавляли интересные фичи,

32
00:01:24,367 --> 00:01:29,267
то график определенно "выстреливал" вверх.

33
00:01:29,267 --> 00:01:32,334
Ок, итак краткая история сервиса YouTube.

34
00:01:32,334 --> 00:01:35,033
Мы основались в феврале 2005-го.

35
00:01:35,033 --> 00:01:38,067
Спустя 8 месяцев мы получили первый 

36
00:01:38,067 --> 00:01:41,033
венчурный капитал в октябре 2005-го, так мы

37
00:01:41,033 --> 00:01:42,467
перебрались в офис.

38
00:01:42,467 --> 00:01:46,334
И одна из самых интересных проблем масштабируемости,

39
00:01:46,334 --> 00:01:48,968
одна из самых интересных инженерных проблем с которой мы столкнулись - 

40
00:01:48,968 --> 00:01:52,267
это сохранение наших мониторов  сухости в нашем новом офисе.

41
00:01:52,267 --> 00:01:55,868
Как только мы переехали туда, сразу же начался дождь,

42
00:01:55,868 --> 00:01:59,067
в принципе, это не проблема, когда ты в здании.

43
00:01:59,067 --> 00:02:00,968
Вот только у нас было 

44
00:02:00,968 --> 00:02:04,100
семь или восемь протечек в различных местах.

45
00:02:04,100 --> 00:02:06,367
А мониторы мы получили новенькие,

46
00:02:06,367 --> 00:02:07,534
большие 24-дюймовые мониторы...

47
00:02:07,534 --> 00:02:10,501
Поэтому мы не хотели,

48
00:02:10,501 --> 00:02:12,801
чтобы они сломались из-за короткого замыкания.

49
00:02:12,801 --> 00:02:16,334
После 20-30 минут

50
00:02:16,334 --> 00:02:17,701
поиска различных методов борьбы с водой,

51
00:02:17,701 --> 00:02:20,167
мы взяли полиэтилен,

52
00:02:20,167 --> 00:02:21,734
от мебели из IKEA.

53
00:02:21,734 --> 00:02:23,934
Мы смастерили желоб из него

54
00:02:23,934 --> 00:02:27,367
и использовали мусорное ведро для слива.

55
00:02:27,367 --> 00:02:30,167
Нам хватило и полиэтилена, и ведер,

56
00:02:30,167 --> 00:02:34,334
чтобы справится с огромными 

57
00:02:34,334 --> 00:02:35,734
потоками воды.

58
00:02:35,734 --> 00:02:37,367
Я думаю--

59
00:02:37,367 --> 00:02:38,834
Я думаю, что я даже разок вернулся обратно в офис,

60
00:02:38,834 --> 00:02:41,167
чтобы убедиться, что ведра не переполнены.

61
00:02:41,167 --> 00:02:43,767
Очень интересные ситуации

62
00:02:43,767 --> 00:02:45,734
происходили в то время.

63
00:02:45,734 --> 00:02:48,801
Буквально 5 месяцев спустя

64
00:02:48,801 --> 00:02:51,100
мы перешагнули предел в 30 миллионов просмотров в день.

65
00:02:51,100 --> 00:02:53,234
Это всего-то спустя год после основания.

66
00:02:53,234 --> 00:02:55,601
Удивительные цифры.

67
00:02:55,601 --> 00:02:58,300
И я расскажу немного о том, чего нам 

68
00:02:58,300 --> 00:02:59,467
стоило добиться таких результатов.

69
00:02:59,467 --> 00:03:01,467
Спустя пару месяцев 

70
00:03:01,467 --> 00:03:03,434
мы более чем утроили этот показатель.

71
00:03:03,434 --> 00:03:04,801
Очень неплохо.

72
00:03:04,801 --> 00:03:06,467
Вот, что удивительно.

73
00:03:06,467 --> 00:03:08,300
Мы бы добавили 5%--

74
00:03:08,300 --> 00:03:10,734
Мы моли бы увеличить емкость каналов на 5% или 10% 

75
00:03:10,734 --> 00:03:14,000
и получили бы такой же, если не больший прирост трафика,

76
00:03:14,000 --> 00:03:15,934
это удивительно.

77
00:03:15,934 --> 00:03:18,934
Спустя еще 2 месяца мы были приобретены Google.

78
00:03:18,934 --> 00:03:20,200
И что мне больше всего нравится - 

79
00:03:20,200 --> 00:03:21,200
нас стали бесплатно кормить.

80
00:03:21,200 --> 00:03:23,868
Для меня это было счастьем.

81
00:03:23,868 --> 00:03:26,434
Невероятно, но еще до приобретения гуглом, мы 

82
00:03:26,434 --> 00:03:28,200
уже были в десятке крупнейших сайтов

83
00:03:28,200 --> 00:03:29,834
по версиям различных счетчиков.

84
00:03:29,834 --> 00:03:32,934
В десятке среди всех веб-сайтов.

85
00:03:32,934 --> 00:03:35,567
Ошеломляющий успех, учитывая,

86
00:03:35,567 --> 00:03:40,801
что нам было всего-то 1.5 года к тому времени.

87
00:03:40,801 --> 00:03:43,968
Мы были четвертыми по версии Alexa по состоянию на 3ий квартал 2007,

88
00:03:43,968 --> 00:03:46,434
а также по версиям других счетчиков.

89
00:03:46,434 --> 00:03:49,667
На сегодня цифры обновились,

90
00:03:49,667 --> 00:03:51,901
но последняя информация, которую я слышал, была о 

91
00:03:51,901 --> 00:03:53,300
аплоаде 10 часов видео в минуту.

92
00:03:53,300 --> 00:03:54,601
Сейчас уже скорее всего 13 часов.

93
00:03:54,601 --> 00:03:59,000
И сотни миллионов просмотров в сутки.

94
00:03:59,000 --> 00:04:00,367
Это невероятное количество просмотров.

95
00:04:00,367 --> 00:04:02,667
Точных цифр я не могу назвать, но--

96
00:04:02,667 --> 00:04:06,367
Это запредельные цифры.

97
00:04:06,367 --> 00:04:08,501
Итак, быстренько. 
Состав команды до приобретения был таков:

98
00:04:08,501 --> 00:04:10,834
Два сис-админа.

99
00:04:10,834 --> 00:04:13,067
Два разработчика, включая меня,

100
00:04:13,067 --> 00:04:14,801
следящие за тем, чтобы сервис выдерживал нагрузки.

101
00:04:14,801 --> 00:04:17,400
Два разработчика сервисов.

102
00:04:17,400 --> 00:04:20,033
Два сетевых инженера и один DBA.

103
00:04:20,033 --> 00:04:24,501
И, к сожалению, ни одного руководителя.

104
00:04:24,501 --> 00:04:26,100
Хотя сейчас у нас их два.

105
00:04:26,100 --> 00:04:29,334
Так что традиция пар сохраняется.

106
00:04:29,334 --> 00:04:32,033
Вот мой алгоритм для управления быстрорастущим сервисом.

107
00:04:32,033 --> 00:04:35,334
Начинаете с нахождения и исправления "узких мест".

108
00:04:35,334 --> 00:04:39,000
Выпиваете напиток по вкусу.

109
00:04:39,000 --> 00:04:40,400
Я не советую ничего.

110
00:04:40,400 --> 00:04:42,434
Так что пейте то, что вам нравится.

111
00:04:42,434 --> 00:04:44,100
Затем немного спите, а потом замечаете еще что-то,

112
00:04:44,100 --> 00:04:45,367
и всё начинаете снова.

113
00:04:45,367 --> 00:04:46,467
Обычно так происходит с быстрорастущими

114
00:04:46,467 --> 00:04:48,267
сервисами, я думаю.

115
00:04:48,267 --> 00:04:50,400
Одна из ключевых фраз, которая была у нас на начальной стадии - 

116
00:04:50,400 --> 00:04:52,767
это "хорошо иметь такие проблемы"

117
00:04:52,767 --> 00:04:55,300
А спустя некоторое время можно было услышать, что-то типа

118
00:04:55,300 --> 00:04:58,801
"Я убью следующего, кто это скажет".

119
00:04:58,801 --> 00:05:01,701
[из зала]: этот код многопоточный?

120
00:05:01,701 --> 00:05:04,734
Do: А это отличный переход к следующей части.

121
00:05:04,734 --> 00:05:08,734
Потому что в этом конкретном случае у нас сочетается 

122
00:05:08,734 --> 00:05:10,234
сон и выпивка.

123
00:05:10,234 --> 00:05:13,133
Это один из наших админов

124
00:05:13,133 --> 00:05:15,868
до приобретения гуглом.

125
00:05:15,868 --> 00:05:20,567
Итак, давайте перейдем к делу,

126
00:05:20,567 --> 00:05:22,367
представим поток запросов.

127
00:05:22,367 --> 00:05:25,033
Все начинается с конечного пользователя.

128
00:05:25,033 --> 00:05:29,000
Затем запрос идет от пользовательского браузера 

129
00:05:29,000 --> 00:05:31,634
к балансировщикам нагрузки NetScaler.

130
00:05:31,634 --> 00:05:34,300
А уже от них к веб серверам.

131
00:05:34,300 --> 00:05:37,000
Это банк веб-серверов  в колокейшене YouTube.

132
00:05:37,000 --> 00:05:41,400
Эти машины не поддерживают какое-то конкретное состояние.

133
00:05:41,400 --> 00:05:43,234
Они работают по принципу "один упал,

134
00:05:43,234 --> 00:05:45,834
а сайт в порядке".

135
00:05:45,834 --> 00:05:51,100
На этих машинах Апач принимает запросы

136
00:05:51,100 --> 00:05:53,400
с NetScalers.

137
00:05:53,400 --> 00:05:55,767
Он проверяет динамический это запрос или нет.

138
00:05:55,767 --> 00:05:57,167
Если запрос динамический,

139
00:05:57,167 --> 00:06:00,367
то он передается через fast СGI

140
00:06:00,367 --> 00:06:02,701
к локальному серверу приложений.

141
00:06:02,701 --> 00:06:04,534
Многопроцессный сервер приложений крутится на той же машине,

142
00:06:04,534 --> 00:06:06,100
и написан на Python,

143
00:06:06,100 --> 00:06:08,968
Python мы выбрали

144
00:06:08,968 --> 00:06:10,400
для всего кода приложений.

145
00:06:10,400 --> 00:06:14,200
Python собирает информацию с различных 

146
00:06:14,200 --> 00:06:15,367
источников.

147
00:06:15,367 --> 00:06:18,167
От RPC,

148
00:06:18,167 --> 00:06:20,701
от  mem cache серверов,

149
00:06:20,701 --> 00:06:23,734
которые хранят информацию запрашиваемую от БД,

150
00:06:23,734 --> 00:06:28,033
и от других относительно дорогих источников данных.

151
00:06:28,033 --> 00:06:30,567
И, естественно, от наших баз данных,

152
00:06:30,567 --> 00:06:32,934
для информации, которая не кешируется

153
00:06:32,934 --> 00:06:36,734
или не нашлась в кеше.

154
00:06:36,734 --> 00:06:40,000
Для видео у нас предусмотрено два различных

155
00:06:40,000 --> 00:06:41,300
места хранения.

156
00:06:41,300 --> 00:06:42,834
Первое - это наш CDN.

157
00:06:42,834 --> 00:06:46,234
Это проект, созданный внутри Google.

158
00:06:46,234 --> 00:06:49,601
И этот CDN служит нескольким целям.

159
00:06:49,601 --> 00:06:52,367
Он хранит контент,

160
00:06:52,367 --> 00:06:55,067
который наиболее популярен на сайте YouTube.

161
00:06:55,067 --> 00:06:57,567
Например мега-хиты и видео,

162
00:06:57,567 --> 00:07:00,601
которые могут быть не так популярны в США

163
00:07:00,601 --> 00:07:02,767
могут быть хитом в Европе.

164
00:07:02,767 --> 00:07:04,567
К примеру,

165
00:07:04,567 --> 00:07:06,601
может некоторые интересные футбольные ролики,

166
00:07:06,601 --> 00:07:08,801
которые в Европе более популярны.

167
00:07:08,801 --> 00:07:12,234
CDN обслуживает все эти видео.

168
00:07:12,234 --> 00:07:16,901
Он контролирует, что существует несколько копий видео

169
00:07:16,901 --> 00:07:19,367
для QoS и надежности.

170
00:07:19,367 --> 00:07:21,934
И также убеждается, что видео

171
00:07:21,934 --> 00:07:23,601
относительно близко к пользователю.

172
00:07:23,601 --> 00:07:26,434
Чтобы не приходилось получать его через множество сетевых элементов.

173
00:07:26,434 --> 00:07:27,901
Типа множества маршрутизаторов 

174
00:07:27,901 --> 00:07:30,801
и трансатлантический канал.

175
00:07:30,801 --> 00:07:33,234
А остальные видео

176
00:07:33,234 --> 00:07:36,534
хранятся на колокейшене YouTube,

177
00:07:36,534 --> 00:07:38,701
в различных местах в США.

178
00:07:38,701 --> 00:07:39,934
По крайней мере пока.

179
00:07:39,934 --> 00:07:42,634
Мы рассматриваем и другие страны,

180
00:07:42,634 --> 00:07:46,534
но пока они все находятся в США.

181
00:07:46,534 --> 00:07:47,534
Ключевые технологии.

182
00:07:47,534 --> 00:07:48,734
Мы используем Linux,

183
00:07:48,734 --> 00:07:50,901
а именно SuSE Linux.

184
00:07:50,901 --> 00:07:54,901
Различные версии в линейке 10.x.

185
00:07:54,901 --> 00:07:57,868
Мы используем apache, как я упомянал ранее

186
00:07:57,868 --> 00:08:02,167
для обработки запросов с сайта youtube,

187
00:08:02,167 --> 00:08:04,400
а также и с мобильной версии сайта,

188
00:08:04,400 --> 00:08:06,400
а также для кое-чего другого и API.

189
00:08:06,400 --> 00:08:10,200
Для видео мы используем lighttpd,

190
00:08:10,200 --> 00:08:11,601
так как он очень быстро справляется

191
00:08:11,601 --> 00:08:14,968
с большими файлами.

192
00:08:14,968 --> 00:08:16,901
Он уделывает Apache вчистую, когда дело касается

193
00:08:16,901 --> 00:08:19,567
большого количества соединений,

194
00:08:19,567 --> 00:08:23,400
высокой их скорости и большого количества видео.

195
00:08:23,400 --> 00:08:26,334
Ой, я имел ввиду большого размера видео.

196
00:08:26,334 --> 00:08:28,834
MySQL используется для хранения метаданных.

197
00:08:28,834 --> 00:08:33,067
Это пользовательская информация,

198
00:08:33,067 --> 00:08:36,200
типа имени пользователя,

199
00:08:36,200 --> 00:08:38,167
хэш версии пароля и так далее.

200
00:08:38,167 --> 00:08:39,367
В таком духе.

201
00:08:39,367 --> 00:08:42,000
Я упомянал Python--

202
00:08:42,000 --> 00:08:44,100
вышло так, что Python

203
00:08:44,100 --> 00:08:45,267
стал очень удачным для нас выбором

204
00:08:45,267 --> 00:08:46,334
в качестве языка программирования,

205
00:08:46,334 --> 00:08:48,634
потому что, особенно на раннем этапе,

206
00:08:48,634 --> 00:08:51,300
было так трудно найти новых работников,

207
00:08:51,300 --> 00:08:53,100
тем более когда мы были небольшой командой.

208
00:08:53,100 --> 00:08:55,934
У нас не было специалиста по подбору персонала.

209
00:08:55,934 --> 00:08:59,701
Было куда проще выписать чек

210
00:08:59,701 --> 00:09:02,767
на 10 новых железок, чем

211
00:09:02,767 --> 00:09:06,000
найти одного-двух талантливых инженеров,

212
00:09:06,000 --> 00:09:08,434
которые сходу бы включились в работу.

213
00:09:08,434 --> 00:09:09,701
Так что мы пошли на компромисс,

214
00:09:09,701 --> 00:09:11,234
поймали удачный момент для рынка,

215
00:09:11,234 --> 00:09:13,734
и увеличивали свою эффективность

216
00:09:13,734 --> 00:09:15,567
в другой области.

217
00:09:15,567 --> 00:09:17,467
Может  код и слегка медленнее,

218
00:09:17,467 --> 00:09:19,767
но менее восприимчивый к переполнениям стека

219
00:09:19,767 --> 00:09:22,200
и другим неприятным вещам, которые вы знаете

220
00:09:22,200 --> 00:09:23,534
по другим языкам программирования.

221
00:09:23,534 --> 00:09:25,734
И, конечно же, технологии Google.

222
00:09:25,734 --> 00:09:27,167
Мы используем некоторые технологии

223
00:09:27,167 --> 00:09:30,000
о которых вы могли читать или которые уже видели.

224
00:09:30,000 --> 00:09:32,000
Очевидно, что поиск - одна из ключевых технологий.

225
00:09:32,000 --> 00:09:33,634
Помимо поиска

226
00:09:33,634 --> 00:09:37,501
мы используем BigTable для хранения превью видео.

227
00:09:37,501 --> 00:09:42,267
Для внутреннего файлового хранилища используется GFS.

228
00:09:42,267 --> 00:09:45,634
Мы используем Protocol Buffers, исходный код которых был недавно открыт.

229
00:09:45,634 --> 00:09:48,400
И еще несколько технологий Google в целом.

230
00:09:48,400 --> 00:09:50,501
Масштаб всего этого увеличивается со временем

231
00:09:50,501 --> 00:09:52,834
по мере того, как мы сталкиваемся со специфичными проблемами,

232
00:09:52,834 --> 00:09:55,334
которые требуют больших вычислительных мощностей

233
00:09:55,334 --> 00:09:56,968
и распределенных вычислений,

234
00:09:56,968 --> 00:10:00,868
того, чем обладает инфраструктура Google.

235
00:10:00,868 --> 00:10:03,767
Что касается наших баз данных,

236
00:10:03,767 --> 00:10:06,267
мы начали с одной и, очевидно,--

237
00:10:06,267 --> 00:10:07,968
как Ami сказала, мы начали с одной главной репликации,

238
00:10:07,968 --> 00:10:09,801
одной репликации для бэкапа

239
00:10:09,801 --> 00:10:12,968
и репликации для отчетов.

240
00:10:12,968 --> 00:10:15,701
Но мы быстро выросли из этих возможностей.

241
00:10:15,701 --> 00:10:18,868
Сейчас у нас есть множество вертикальных разделов,

242
00:10:18,868 --> 00:10:22,434
что, по сути, означает, что мы берем часть сайта,

243
00:10:22,434 --> 00:10:24,968
которая отделена от всего остального.

244
00:10:24,968 --> 00:10:27,901
И у этой части сайта нет

245
00:10:27,901 --> 00:10:28,934
большого числа внешних зависимостей.

246
00:10:28,934 --> 00:10:31,501
Мы берем ее и

247
00:10:31,501 --> 00:10:34,033
мы закидываем эту часть на отдельные

248
00:10:34,033 --> 00:10:35,601
машины с базами данных,

249
00:10:35,601 --> 00:10:36,868
и, возможно, даже на отдельные машины с веб-серверами.

250
00:10:36,868 --> 00:10:38,834
И мы говорим: "Хорошо, это может масштабироваться само по себе.

251
00:10:38,834 --> 00:10:40,868
Это не должно мешать остальной части сайта."

252
00:10:40,868 --> 00:10:42,868
То же самое для остальных частей.

253
00:10:42,868 --> 00:10:45,667
Для частей сайта, которые были достаточно большими

254
00:10:45,667 --> 00:10:49,901
и которые было сложно отделить,

255
00:10:49,901 --> 00:10:51,634
как, например, метаданные пользователей

256
00:10:51,634 --> 00:10:53,300
и ассоциированные метаданные видео,

257
00:10:53,300 --> 00:10:57,100
мы использовали горизонтальное разделение.

258
00:10:57,100 --> 00:11:01,501
Как будто у нас есть множество баз данных с одной схемой,

259
00:11:01,501 --> 00:11:03,701
но разными наборами пользователей.

260
00:11:03,701 --> 00:11:06,634
Так что, одна n-ая часть часть пользователей на этом разделе.

261
00:11:06,634 --> 00:11:08,300
Одная n-ая здесь, одна n-ая на том.

262
00:11:08,300 --> 00:11:10,834
И мы сделали так просто потому,

263
00:11:10,834 --> 00:11:12,934
что это выглядело самым масштабируемым способом.

264
00:11:12,934 --> 00:11:14,767
Кроме того, у нас есть база данных, которая позволяет нам

265
00:11:14,767 --> 00:11:20,267
связать пользователей с этими разделами.

266
00:11:20,267 --> 00:11:23,868
Так что, обычные операции, такие как просмотр видео

267
00:11:23,868 --> 00:11:26,100
и просмотр канала пользователя

268
00:11:26,100 --> 00:11:28,234
выполняются гораздо быстрее, чем это могло бы быть.

269
00:11:28,234 --> 00:11:33,801
Если бы нам приходилось сканировать каждую из баз данных.

270
00:11:33,801 --> 00:11:36,334
С этими изменениями в масштабируемости

271
00:11:36,334 --> 00:11:38,801
перед нами вставало множество испытаний.

272
00:11:38,801 --> 00:11:41,267
Получалось, что как только мы наращивали мощности,

273
00:11:41,267 --> 00:11:43,734
сразу возникало нечто, что могло высосать ее всю.

274
00:11:43,734 --> 00:11:46,501
Первым таким фактором стал непредсказуемый и бурный рост.

275
00:11:46,501 --> 00:11:49,200
Это удивительно, но как я уже говорил,

276
00:11:49,200 --> 00:11:53,000
было не важно на сколько мы увеличивали производительность,

277
00:11:53,000 --> 00:11:57,901
сразу же возникали новые пользователи, поглощающие её.

278
00:11:57,901 --> 00:12:00,033
Это лестно и поощрительно,

279
00:12:00,033 --> 00:12:01,868
но в то же время это определенно проблема,

280
00:12:01,868 --> 00:12:03,267
т.к. на раннем этапе

281
00:12:03,267 --> 00:12:05,067
у нас был небольшой бюджет

282
00:12:05,067 --> 00:12:06,667
до приобретения.

283
00:12:06,667 --> 00:12:08,000
и даже после приобретения

284
00:12:08,000 --> 00:12:09,834
всё что мы могли сделать,

285
00:12:09,834 --> 00:12:12,567
так это обеспечить некоторый запас производительности,

286
00:12:12,567 --> 00:12:14,467
который потом съедался

287
00:12:14,467 --> 00:12:16,000
с ростом сервиса.

288
00:12:16,000 --> 00:12:18,133
И это интересная задача,

289
00:12:18,133 --> 00:12:20,701
не имея достаточно большого количества лишних машин,

290
00:12:20,701 --> 00:12:22,634
не тратя больших денег сразу,

291
00:12:22,634 --> 00:12:26,634
обеспечить работу сервиса под наплывом пользователей.

292
00:12:26,634 --> 00:12:28,934
"Пылких" пользователей.

293
00:12:28,934 --> 00:12:32,601
Мы даже не могли представить на раннем этапе,

294
00:12:32,601 --> 00:12:34,934
что некоторые пользователи будут закачивать

295
00:12:34,934 --> 00:12:38,167
тысячи и тысячи, и тысячи видео,

296
00:12:38,167 --> 00:12:41,767
и люди захотят вести видео блоги

297
00:12:41,767 --> 00:12:42,801
каждой секунды их жизни.

298
00:12:42,801 --> 00:12:43,834
Что-то вроде того.

299
00:12:43,834 --> 00:12:44,934
Для этого наш сайт и придуман.

300
00:12:44,934 --> 00:12:47,567
Однако это говорит лишь о том, что нам

301
00:12:47,567 --> 00:12:49,000
надо работать чуть усерднее в таких случаях,

302
00:12:49,000 --> 00:12:50,701
чтобы справится 

303
00:12:50,701 --> 00:12:52,801
с такими пользователями

304
00:12:52,801 --> 00:12:54,601
Новые возможности.

305
00:12:54,601 --> 00:12:58,501
Пару лет назад ниша видео в сети была в новинку,

306
00:12:58,501 --> 00:13:00,667
и считалось за счастье возможность проигрывать видео,

307
00:13:00,667 --> 00:13:04,467
без установки специального софта

308
00:13:04,467 --> 00:13:06,534
или чего-то такого.

309
00:13:06,534 --> 00:13:09,033
Но планка теперь поднята высоко.

310
00:13:09,033 --> 00:13:10,234
Я имею ввиду, что теперь

311
00:13:10,234 --> 00:13:13,067
недостаточно предоставить повсеместный доступ к видео,

312
00:13:13,067 --> 00:13:15,534
мгновенность, API и все такое.

313
00:13:15,534 --> 00:13:17,067
Это и так подразумевается.

314
00:13:17,067 --> 00:13:21,400
Теперь нужно внедрять рекомендационные алгоритмы

315
00:13:21,400 --> 00:13:23,868
социальные графы и услуги,

316
00:13:23,868 --> 00:13:26,734
которые требуют довольно много процессорного времени.

317
00:13:26,734 --> 00:13:28,901
Поэтому, естественно, очень трудно соблюсти баланс

318
00:13:28,901 --> 00:13:31,267
между пользовательским взаимодействием, новыми фичами

319
00:13:31,267 --> 00:13:34,067
и увеличением производительности сервиса.

320
00:13:34,067 --> 00:13:35,934
Расширяя программные и аппаратные границы.

321
00:13:35,934 --> 00:13:38,934
Про это я расскажу чуть позже.

322
00:13:38,934 --> 00:13:42,100
Однако, как правило, если вы работаете на пределе программных

323
00:13:42,100 --> 00:13:44,801
и аппаратных ресурсов, то скорее всего вы потерпите неудачу.

324
00:13:44,801 --> 00:13:46,901
Вот пара примеров,

325
00:13:46,901 --> 00:13:52,167
когда мы попадали в такие ситуации.

326
00:13:52,167 --> 00:13:56,367
В таких случаях определение узких мест становится не очевидным.

327
00:13:56,367 --> 00:14:01,300
Мы направляем багрепорты нескольким вендорам,

328
00:14:01,300 --> 00:14:03,767
которые поддерживают наши open source продукты,

329
00:14:03,767 --> 00:14:06,634
потому что иногда требуется свежий  взгляд

330
00:14:06,634 --> 00:14:07,767
на некоторые проблемы.

331
00:14:07,767 --> 00:14:10,234
И получается ситуация, что мы направляли им багрепорты,

332
00:14:10,234 --> 00:14:11,434
а в ответ получаем: "Серьезно?"

333
00:14:11,434 --> 00:14:14,234
После чего они несколько дней пытаются воспроизвести баг.

334
00:14:14,234 --> 00:14:16,501
И так и не могут предложить

335
00:14:16,501 --> 00:14:17,834
рабочего решения для нас.

336
00:14:17,834 --> 00:14:20,801
На этом этапе начинается интересное,

337
00:14:20,801 --> 00:14:22,701
вы начинаете гуглить,

338
00:14:22,701 --> 00:14:25,334
искать по блогам,

339
00:14:25,334 --> 00:14:27,067
и не находите ничего похожего

340
00:14:27,067 --> 00:14:29,067
на возникшую проблему.

341
00:14:29,067 --> 00:14:31,667
Это ставит вас в очень интересную ситуацию.

342
00:14:31,667 --> 00:14:34,968
И некоторые из проблем можно решить,

343
00:14:34,968 --> 00:14:36,734
имея некий запас производительности.

344
00:14:36,734 --> 00:14:39,033
Некоторые программы у нас

345
00:14:39,033 --> 00:14:40,367
работают в таких режимах,

346
00:14:40,367 --> 00:14:45,834
которые вряд ли подразумевались их разработчиками.

347
00:14:45,834 --> 00:14:49,000
Вот пример проблемы, с которой мы сталкивались.

348
00:14:49,000 --> 00:14:51,467
Если вам не видно, то там написано

349
00:14:51,467 --> 00:14:53,400
"Мы не можем больше принять видео.

350
00:14:53,400 --> 00:14:54,634
Слишком много видео файлов."

351
00:14:54,634 --> 00:14:59,334
Это сообщение пришло в 2:24 ночи 22 октября.

352
00:14:59,334 --> 00:15:01,767
Я вообще-то уже спать собирался.

353
00:15:01,767 --> 00:15:06,434
Так что это было не очень приятное письмо в тот момент.

354
00:15:06,434 --> 00:15:09,868
Наши лимиты по аплоаду подошли к концу.

355
00:15:09,868 --> 00:15:13,200
После непродолжительного дебаггинга

356
00:15:13,200 --> 00:15:15,334
мы поняли,

357
00:15:15,334 --> 00:15:17,567
что сделали глупую,

358
00:15:17,567 --> 00:15:20,133
стартаперскую ошибку,

359
00:15:20,133 --> 00:15:23,067
размещая 

360
00:15:23,067 --> 00:15:26,100
превью для каждого видео файла

361
00:15:26,100 --> 00:15:28,067
в отдельном подкаталоге.

362
00:15:28,067 --> 00:15:29,467
Но все подкаталоги были

363
00:15:29,467 --> 00:15:32,100
частью плоской структуры каталогов.

364
00:15:32,100 --> 00:15:35,100
Таким образом мы получили десятки тысяч файлов в одном каталоге.

365
00:15:35,100 --> 00:15:37,000
Не очень хорошая идея.

366
00:15:37,000 --> 00:15:40,133
Так мы уперлись в ограничение узлов на каталог,

367
00:15:40,133 --> 00:15:43,100
по крайней мере в системе Ext3, которую мы использовали.

368
00:15:43,100 --> 00:15:45,601
Очень неприятная ситуация.

369
00:15:45,601 --> 00:15:47,868
Это не что-то вроде--

370
00:15:47,868 --> 00:15:49,434
Не надо быть семи пядей во лбу,

371
00:15:49,434 --> 00:15:50,701
чтобы понять, что не стоит хранить

372
00:15:50,701 --> 00:15:51,934
много файлов в одном каталоге.

373
00:15:51,934 --> 00:15:54,934
Но мы не хотели замедлять темпы роста,

374
00:15:54,934 --> 00:15:58,133
и проблему было не так уж сложно устранить.

375
00:15:58,133 --> 00:16:00,100
Так мы перешли к древовидной структуре.

376
00:16:00,100 --> 00:16:01,434
Иерархической структуре.

377
00:16:01,434 --> 00:16:02,801
Не подумайте, что было приятно этим заниматься

378
00:16:02,801 --> 00:16:03,801
в ту ночь.

379
00:16:03,801 --> 00:16:04,834
Вот так.

380
00:16:04,834 --> 00:16:06,834
И работать под давлением

381
00:16:06,834 --> 00:16:09,901
того, что ни одно видео не может загрузится в данный момент.

382
00:16:09,901 --> 00:16:12,267
Так что было совсем не весело.

383
00:16:12,267 --> 00:16:14,734
Вот еще случай,

384
00:16:14,734 --> 00:16:16,834
касательно моего недавнего комментария

385
00:16:16,834 --> 00:16:20,100
насчет "работы на пределе возможностей",

386
00:16:20,100 --> 00:16:21,767
мы работали на пределе возможностей нашей БД,

387
00:16:21,767 --> 00:16:23,334
так как еще не спланировали инфраструктуру

388
00:16:23,334 --> 00:16:24,601
для ее грамотного разбиения.

389
00:16:24,601 --> 00:16:25,934
Это сложная проблема.

390
00:16:25,934 --> 00:16:27,501
Так что это письмо--

391
00:16:27,501 --> 00:16:28,767
Или даже пост,

392
00:16:28,767 --> 00:16:30,567
а точнее параграф от CNET,

393
00:16:30,567 --> 00:16:35,100
относился к периоду нашего down time.

394
00:16:35,100 --> 00:16:37,033
Началось всё в 7:30 и продолжалось 5 часов.

395
00:16:37,033 --> 00:16:40,968
Было очень неприятно.

396
00:16:40,968 --> 00:16:43,734
А еще более неприятным был не столько само падение БД,

397
00:16:43,734 --> 00:16:46,501
сколько звонки от моих родителей, которые интересовались

398
00:16:46,501 --> 00:16:48,000
в порядке ли я?

399
00:16:48,000 --> 00:16:49,934
Понимаете?

400
00:16:49,934 --> 00:16:51,701
Пытались меня морально поддержать.

401
00:16:51,701 --> 00:16:54,300
Но я просто должен был с этим разобраться.

402
00:16:54,300 --> 00:16:56,200
Так что--

403
00:16:56,200 --> 00:16:58,834
Мы посмотрели в логи

404
00:16:58,834 --> 00:17:00,734
и обнаружили, что ошибка была от MySQL.

405
00:17:00,734 --> 00:17:02,968
Ошибка была связана с несовпадением контрольных сумм.

406
00:17:02,968 --> 00:17:04,234
А причина--

407
00:17:04,234 --> 00:17:07,200
Когда MySQL читает данные с диска--

408
00:17:07,200 --> 00:17:09,667
Существует контрольная сумма,

409
00:17:09,667 --> 00:17:12,667
для каждой страницы, размером 16К примерно,

410
00:17:12,667 --> 00:17:14,701
хранимая на диске.

411
00:17:14,701 --> 00:17:17,234
И когда MySQL пытается прочитать данные с диска, 

412
00:17:17,234 --> 00:17:20,334
то он вычисляет контрольную сумму, а затем 

413
00:17:20,334 --> 00:17:21,400
сравнивает ее с той, которая хранится на диске,

414
00:17:21,400 --> 00:17:23,734
чтобы убедится, что ничего страшного не 

415
00:17:23,734 --> 00:17:25,701
произошло между диском и процессом, 

416
00:17:25,701 --> 00:17:27,601
и данные исправны.

417
00:17:27,601 --> 00:17:29,667
Вышло так, что они не совпали,

418
00:17:29,667 --> 00:17:31,300
и MySQL убил себя на этом месте.

419
00:17:31,300 --> 00:17:33,834
Причем он не просто падал,

420
00:17:33,834 --> 00:17:36,133
а еще и требовал 4-5 часов на восстановление,

421
00:17:36,133 --> 00:17:38,033
в зависимости от количества транзакций

422
00:17:38,033 --> 00:17:40,834
и количества изменений,

423
00:17:40,834 --> 00:17:42,033
еще не записанных на диск.

424
00:17:42,033 --> 00:17:46,801
Восстановление займет 4 или 5 часов.

425
00:17:46,801 --> 00:17:48,901
В тот момент, как и у многих,

426
00:17:48,901 --> 00:17:50,601
у нас не было отдельного инженера DBA.

427
00:17:50,601 --> 00:17:52,634
Он только-только присоединился к нам.

428
00:17:52,634 --> 00:17:53,701
И еще не сильно владел MySQL.

429
00:17:53,701 --> 00:17:56,200
Поэтому я его подменял.

430
00:17:56,200 --> 00:17:59,267
Мы испробовали все возможные способы,

431
00:17:59,267 --> 00:18:02,067
чтобы определить, что вызывало ошибку.

432
00:18:02,067 --> 00:18:04,334
Мы искали по всей сети.

433
00:18:04,334 --> 00:18:05,534
Находили множество вопросов, оставшихся без ответов.

434
00:18:05,534 --> 00:18:07,534
Решения той проблемы мы не нашли.

435
00:18:07,534 --> 00:18:11,534
Мы лихорадочно стали заказывать

436
00:18:11,534 --> 00:18:12,901
разное железо,

437
00:18:12,901 --> 00:18:16,701
которое бы не обладало такими проблемами.

438
00:18:16,701 --> 00:18:17,934
Мы думали, что может это железная проблема,

439
00:18:17,934 --> 00:18:20,701
ведь не у всех она проявлялась,

440
00:18:20,701 --> 00:18:21,934
при огромном количестве пользователей MySQL.

441
00:18:21,934 --> 00:18:23,834
А некоторые пользователи будут даже покрупнее нас.

442
00:18:23,834 --> 00:18:27,334
И после продолжительного ожидания,

443
00:18:27,334 --> 00:18:29,367
мы наткнулись на одну запись в блоге.

444
00:18:29,367 --> 00:18:32,234
Именно этот пост, написанный в тот самый день,

445
00:18:32,234 --> 00:18:37,400
говорил, что проблема, на которой я застрял, 

446
00:18:37,400 --> 00:18:38,801
была в карте расширения.

447
00:18:38,801 --> 00:18:40,267
В переходнике (riser card).

448
00:18:40,267 --> 00:18:43,534
Мы недавно, в целях повышения производительности

449
00:18:43,534 --> 00:18:46,868
перешли с более высоких 4U машин

450
00:18:46,868 --> 00:18:48,734
на 3U, так как в 3U серверах

451
00:18:48,734 --> 00:18:52,234
можно было получить более быструю IO подсистему.

452
00:18:52,234 --> 00:18:54,100
По крайней мере для нашего вендора оборудования.

453
00:18:54,100 --> 00:18:59,000
А более низкий корпус не позволял

454
00:18:59,000 --> 00:19:01,400
использовать полноразмерные карты расширения,

455
00:19:01,400 --> 00:19:03,434
например, используемый нами контроллер нагрузки.

456
00:19:03,434 --> 00:19:05,267
Поэтому нам приходилось использовать riser карту,

457
00:19:05,267 --> 00:19:07,234
чтобы карта расширения помещалась там,

458
00:19:07,234 --> 00:19:10,467
где для нее было достаточно места.

459
00:19:10,467 --> 00:19:12,567
А вышло так, что связка 

460
00:19:12,567 --> 00:19:15,067
из riser карты и контроллера нагрузки

461
00:19:15,067 --> 00:19:17,534
могла приводить к интересным флуктуациям

462
00:19:17,534 --> 00:19:19,901
напряжения, что могло вызвать инверсный бит

463
00:19:19,901 --> 00:19:21,033
время от времени.

464
00:19:21,033 --> 00:19:22,667
Вот что именно и происходило.

465
00:19:22,667 --> 00:19:24,067
С данными на диске было все в порядке.

466
00:19:24,067 --> 00:19:25,701
Мы валидировали их после падения.

467
00:19:25,701 --> 00:19:26,834
Все было ОК.

468
00:19:26,834 --> 00:19:28,400
Но где-то между--

469
00:19:28,400 --> 00:19:30,901
Где-то при чтении битов с диска

470
00:19:30,901 --> 00:19:32,767
происходили ошибки.

471
00:19:32,767 --> 00:19:34,701
Было очень трудно в 

472
00:19:34,701 --> 00:19:38,033
эти пару-тройку дней-- или вернее недели.

473
00:19:38,033 --> 00:19:40,067
И последнее--

474
00:19:40,067 --> 00:19:41,267
Следующее о чем я хочу рассказать - 

475
00:19:41,267 --> 00:19:42,534
одно из моих любимых.

476
00:19:42,534 --> 00:19:44,868
У нас опять не хватало места на дисках.

477
00:19:44,868 --> 00:19:46,701
Были проблемы с вендором,

478
00:19:46,701 --> 00:19:49,067
пытавшимся всё уладить вовремя.

479
00:19:49,067 --> 00:19:50,868
Рост был просто взрывным.

480
00:19:50,868 --> 00:19:53,534
И мы верно поступили,

481
00:19:53,534 --> 00:19:55,501
сделав заказ на новые машины заблаговременно.

482
00:19:55,501 --> 00:20:00,234
И мы сказали "Ну, давайте сделаем новую доставку".

483
00:20:00,234 --> 00:20:03,834
Проблема была в том, что поставка ушла не по адресу.

484
00:20:03,834 --> 00:20:07,000
Она ушла--

485
00:20:07,000 --> 00:20:08,467
Вообще-то я не думаю--

486
00:20:08,467 --> 00:20:10,033
что это было правдой.

487
00:20:10,033 --> 00:20:13,267
Мне кажется кто-то просто прикупил себе новый BMW.

488
00:20:13,267 --> 00:20:15,868
Просто напросто кто-то купил себе машину.

489
00:20:15,868 --> 00:20:18,067
Ситуация опять была сложной.

490
00:20:18,067 --> 00:20:20,434
Мы выкарабкивались. Пытались найти обходные пути.

491
00:20:20,434 --> 00:20:23,100
Было неприятно, имея 40 машин

492
00:20:23,100 --> 00:20:24,400
стоимостью дюжину тысяч долларов каждая,

493
00:20:24,400 --> 00:20:27,467
и политику принимать видео всегда,

494
00:20:27,467 --> 00:20:30,801
осознавать, что всё может сломаться.

495
00:20:30,801 --> 00:20:33,701
Ок, пора закруглятся.

496
00:20:33,701 --> 00:20:36,567
В общем базовым подходом в масштабировании сервиса

497
00:20:36,567 --> 00:20:37,868
было написание простого кода.

498
00:20:37,868 --> 00:20:40,067
Мы проверяли, что куски кода достаточно понятные,

499
00:20:40,067 --> 00:20:44,033
чтобы их было просто оптимизировать,

500
00:20:44,033 --> 00:20:46,100
просто отлаживать

501
00:20:46,100 --> 00:20:47,300
и производить рефакторинг.

502
00:20:47,300 --> 00:20:49,133
Мы постоянно работали

503
00:20:49,133 --> 00:20:50,634
над всем на чем возможно.

504
00:20:50,634 --> 00:20:54,534
ПО, базы данных, кеш и т.д.

505
00:20:54,534 --> 00:20:57,100
Мы оптимизировали конфигурационные файлы

506
00:20:57,100 --> 00:20:58,367
по много раз.

507
00:20:58,367 --> 00:21:00,100
Оптимизировали буферную память OS.

508
00:21:00,100 --> 00:21:02,834
Даже настройки RAID.

509
00:21:02,834 --> 00:21:05,267
Использовали коктейль из программного и аппаратного RAID

510
00:21:05,267 --> 00:21:06,601
для наших баз данных.

511
00:21:06,601 --> 00:21:08,701
Мы оптимизировали их на предмет занимаемой памяти.

512
00:21:08,701 --> 00:21:10,300
Так что практически всё.

513
00:21:10,300 --> 00:21:12,367
Это был многократный процесс.

514
00:21:12,367 --> 00:21:15,234
Последнее, что внесло свою лепту в успех

515
00:21:15,234 --> 00:21:16,767
это, я думаю, действительно классная команда.

516
00:21:16,767 --> 00:21:19,601
Я действительно горжусь тем, что я часть этой команды.

517
00:21:19,601 --> 00:21:21,234
Было весело.

518
00:21:21,234 --> 00:21:24,167
Было прикольно,

519
00:21:24,167 --> 00:21:26,467
когда мы отмечали 100 миллионов

520
00:21:26,467 --> 00:21:28,200
просмотров в день.

521
00:21:28,200 --> 00:21:32,167
Мы решили заказать немного бургеров,

522
00:21:32,167 --> 00:21:33,467
и этот ресторанчик

523
00:21:33,467 --> 00:21:35,501
подавал шампанское с бургерами...

524
00:21:35,501 --> 00:21:37,734
Весело было =).

525
00:21:37,734 --> 00:21:40,701
Хорошо, у меня осталось еще немного времени,

526
00:21:40,701 --> 00:21:45,701
может есть какие-то вопросы?

527
00:21:45,701 --> 00:21:49,767
из зала: [неразборчиво]

528
00:21:49,767 --> 00:21:50,767
Do: Простите?

529
00:21:50,767 --> 00:21:55,968
из зала: [неразборчиво]

530
00:21:55,968 --> 00:21:58,534
Do: Да, мы наняли его на небольшой период,

531
00:21:58,534 --> 00:22:00,133
это нормально.

532
00:22:00,133 --> 00:22:02,634
из зала: Сколько ему потребовалось

533
00:22:02,634 --> 00:22:05,200
времени, чтобы понять, что дело в переходнике?

534
00:22:05,200 --> 00:22:06,801
D0: я думаю--

535
00:22:06,801 --> 00:22:09,601
вообще-то мы нанимали его не для конкретно данной проблемы.

536
00:22:09,601 --> 00:22:12,734
Вышло так, что он помогал другому клиенту.

537
00:22:12,734 --> 00:22:14,901
И просто написал о случае

538
00:22:14,901 --> 00:22:16,400
с одним из клиентов.

539
00:22:16,400 --> 00:22:18,734
Мы забыли спросить у него,

540
00:22:18,734 --> 00:22:22,234
сколько времени у него это заняло.

541
00:22:22,234 --> 00:22:24,901
Но у нас это заняло определенно много времени,

542
00:22:24,901 --> 00:22:26,601
чтобы найти причину,

543
00:22:26,601 --> 00:22:27,868
так как пришлось переключать все RAID карты

544
00:22:27,868 --> 00:22:29,334
во всех машинах, а это не веселое занятие,

545
00:22:29,334 --> 00:22:32,868
учитывая то, что базы данных продолжают работать.

546
00:22:32,868 --> 00:22:34,467
Да.

547
00:22:34,467 --> 00:22:37,534
из зала: Не могли бы немного рассказать о конвертации контента?

548
00:22:37,534 --> 00:22:42,567
Как вы принимаете, проверяете и подтверждаете контент--

549
00:22:42,567 --> 00:22:45,167
Do: Ок, мы принимаем--

550
00:22:45,167 --> 00:22:46,634
это как раз то, что постоянно меняется,

551
00:22:46,634 --> 00:22:47,934
но вот как мы поступали с момента

552
00:22:47,934 --> 00:22:49,701
более ли менее окрепшего состояния -

553
00:22:49,701 --> 00:22:53,801
мы получали контент через HTTP POST

554
00:22:53,801 --> 00:22:57,400
от браузера, или от API, не суть.

555
00:22:57,400 --> 00:23:01,334
Затем мы выполняем пару действий. 

556
00:23:01,334 --> 00:23:03,100
Мы как бы идентифицируем видео,

557
00:23:03,100 --> 00:23:05,801
чтобы убедится, что это видео вообще.

558
00:23:05,801 --> 00:23:08,133
Некоторые заливают PowerPoint файлы

559
00:23:08,133 --> 00:23:09,767
и всякое такое.

560
00:23:09,767 --> 00:23:11,267
Мы не поддерживаем такие типы.

561
00:23:11,267 --> 00:23:16,601
Затем в ход идут определение битрейта, определение источника и т.д.

562
00:23:16,601 --> 00:23:19,534
Мы проводим еще некоторые измерения,

563
00:23:19,534 --> 00:23:22,801
а затем пропускаем сквозь транскодер,

564
00:23:22,801 --> 00:23:25,801
используя собранные данные.

565
00:23:25,801 --> 00:23:28,767
После чего--

566
00:23:28,767 --> 00:23:31,801
мы берем транскодированный файл

567
00:23:31,801 --> 00:23:33,501
и копируем на машины

568
00:23:33,501 --> 00:23:35,601
с которых он будет раздаваться.

569
00:23:35,601 --> 00:23:37,767
Есть и другие форматы--

570
00:23:37,767 --> 00:23:40,033
у нас используется H.264.

571
00:23:40,033 --> 00:23:41,767
Есть форматы 

572
00:23:41,767 --> 00:23:43,434
для мобильных телефонов и так далее.

573
00:23:43,434 --> 00:23:45,334
Это происходит после

574
00:23:45,334 --> 00:23:47,434
исходного получения FLV файла,

575
00:23:47,434 --> 00:23:51,100
также как и HQ версии.

576
00:23:51,100 --> 00:23:53,567
В общем так всё и происходит.

577
00:23:53,567 --> 00:23:55,534
Да?

578
00:23:55,534 --> 00:23:59,434
из зала: Вы не могли бы вернуть назад слайд с Apache еще раз?

579
00:23:59,434 --> 00:24:00,934
Do: Простите, не расслышал вопрос.

580
00:24:00,934 --> 00:24:03,667
из зала: Вы не могли бы вернуть назад слайд с Apache еще раз?

581
00:24:03,667 --> 00:24:07,100
Do: Давайте попробуем.

582
00:24:07,100 --> 00:24:10,334
Этот?

583
00:24:10,334 --> 00:24:11,601
Хорошо.

584
00:24:11,601 --> 00:24:13,200
Он мелковат,

585
00:24:13,200 --> 00:24:17,868
но я думаю, что поговорил о нем достаточно.

586
00:24:17,868 --> 00:24:19,167
Да.

587
00:24:19,167 --> 00:24:21,501
 из зала: Вы вообще делите базы данных?

588
00:24:21,501 --> 00:24:23,300
Вы их разделяете?

589
00:24:23,300 --> 00:24:26,300
Могу представить, у вас есть огромные таблицы

590
00:24:26,300 --> 00:24:29,801
для некоторых самых давних пользователей.

591
00:24:29,801 --> 00:24:32,334
И есть сто миллионов компаний,

592
00:24:32,334 --> 00:24:33,601
пользующихся вашими услугами,

593
00:24:33,601 --> 00:24:35,334
так что они, естественно, очень впечатлены.

594
00:24:35,334 --> 00:24:37,267
Вам приходится разделять базы данных?

595
00:24:37,267 --> 00:24:39,501
(неразборчиво)

596
00:24:39,501 --> 00:24:40,801
Do: Конечно, конечно.

597
00:24:40,801 --> 00:24:42,467
Я уже говорил об этом немного

598
00:24:42,467 --> 00:24:44,067
во время предыдущего слайда, где

599
00:24:44,067 --> 00:24:46,767
мы использовали комбинацию из вертикального разделения

600
00:24:46,767 --> 00:24:50,534
для случаев, когда таблица управляема.

601
00:24:50,534 --> 00:24:51,801
Размер управляемый.

602
00:24:51,801 --> 00:24:54,634
Трафик может быть довольно большим.

603
00:24:54,634 --> 00:24:57,701
Но для вещей, у которых и размер, и трафик

604
00:24:57,701 --> 00:25:00,534
создают проблемы,

605
00:25:00,534 --> 00:25:02,133
мы используем горизонтальные разделы,

606
00:25:02,133 --> 00:25:05,300
где у нас находится набор главных баз данных

607
00:25:05,300 --> 00:25:07,567
с различными наборами данных в каждой из них.

608
00:25:07,567 --> 00:25:11,767
И каждая из них имеет реплики, которые могут обрабатывать запросы на чтение

609
00:25:11,767 --> 00:25:14,133
эффективным образом.

610
00:25:14,133 --> 00:25:15,434
Итак, вот так мы справляемся с этим.

611
00:25:15,434 --> 00:25:17,267
И затем нам надо обратится к базе данных для сопоставления

612
00:25:17,267 --> 00:25:21,400
пользователей и видео для каждого из этих разделов.

613
00:25:21,400 --> 00:25:22,801
Я ответил на Ваш вопрос?

614
00:25:22,801 --> 00:25:24,567
из зала: Типа того.

615
00:25:24,567 --> 00:25:26,067
Я говорил с некоторыми людьми из High Five

616
00:25:26,067 --> 00:25:27,200
и они говорили, что на самом деле они

617
00:25:27,200 --> 00:25:29,734
пошли еще дальше, чем простое 

618
00:25:29,734 --> 00:25:33,267
разбиение на несколько таблиц.

619
00:25:33,267 --> 00:25:35,200
Они использовали...

620
00:25:35,200 --> 00:25:37,934
Точнее не использовали MySQL, из-за того, что при индексации MySQL

621
00:25:37,934 --> 00:25:39,968
получаются слишком большие накладные расходы.

622
00:25:39,968 --> 00:25:42,901
Поэтому я был удивлен, что вы использовали MySQL.

623
00:25:42,901 --> 00:25:44,467
И мне было интересно,

624
00:25:44,467 --> 00:25:46,601
как вы решаете эти проблемы.

625
00:25:46,601 --> 00:25:49,367
Do: Я думаю, что наше решение для этого

626
00:25:49,367 --> 00:25:50,501
в том, чтобы разделять еще больше, я так думаю.

627
00:25:50,501 --> 00:25:52,267
Это очень помогает,

628
00:25:52,267 --> 00:25:55,434
потому, что, как мы обнаружили, у базы данных есть золотая середина.

629
00:25:55,434 --> 00:25:59,067
Ее довольно тяжело найти.

630
00:25:59,067 --> 00:26:00,701
Я сидел и подбирал эмпирически,

631
00:26:00,701 --> 00:26:02,267
просто пробуя как все работает.

632
00:26:02,267 --> 00:26:05,467
Оказалось, что не обязательно все данные должны целиком помещаться в памяти.

633
00:26:05,467 --> 00:26:07,400
А только те данные, которые могут потребоваться в течение 

634
00:26:07,400 --> 00:26:08,634
определенного промежутка времени.

635
00:26:08,634 --> 00:26:10,968
Рабочее множество, другими словами.

636
00:26:10,968 --> 00:26:14,868
Мы обнаружили, что соотношение памяти и диска --

637
00:26:14,868 --> 00:26:16,501
возможно, ключевая вещь для масштабирования.

638
00:26:16,501 --> 00:26:17,667
И еще несколько других,

639
00:26:17,667 --> 00:26:19,734
таких как индексация и другие вещи,

640
00:26:19,734 --> 00:26:21,801
которые мы подкручивали со временем.

641
00:26:21,801 --> 00:26:24,234
Ага, последний вопрос.

642
00:26:24,234 --> 00:26:25,734
из зала: А Вы разработали

643
00:26:25,734 --> 00:26:28,167
некий тулкит для

644
00:26:28,167 --> 00:26:31,567
осуществления масштабирования?

645
00:26:31,567 --> 00:26:32,667
Do: Эм, нет.

646
00:26:32,667 --> 00:26:34,167
Многое из того, что мы сделали

647
00:26:34,167 --> 00:26:36,400
можно считать доморощенным.

648
00:26:36,400 --> 00:26:37,734
У нас очень тонкий слой

649
00:26:37,734 --> 00:26:40,434
поверх DBAPI из Python .

650
00:26:40,434 --> 00:26:42,234
MySQL Python.

651
00:26:42,234 --> 00:26:45,033
И мы просто сделали начальный слой,

652
00:26:45,033 --> 00:26:46,767
работающий с одной базой данных.

653
00:26:46,767 --> 00:26:49,067
И потом, когда прошло время, мы...

654
00:26:49,067 --> 00:26:50,367
что хорошо в Python'е,

655
00:26:50,367 --> 00:26:52,367
и других высокоуровневых языках такого типа,

656
00:26:52,367 --> 00:26:54,334
это то, что у нас есть--

657
00:26:54,334 --> 00:26:56,300
мы используем эту штуку под названием Декоратор.

658
00:26:56,300 --> 00:26:58,467
поверх всех функций базы данных.

659
00:26:58,467 --> 00:27:01,067
Это просто посредник.

660
00:27:01,067 --> 00:27:02,701
Прокси для функций.

661
00:27:02,701 --> 00:27:05,834
И это дает вам данные, которые вам нужны,

662
00:27:05,834 --> 00:27:07,701
чтобы общаться с базой данных.

663
00:27:07,701 --> 00:27:10,667
А раз у нас есть этот слой,

664
00:27:10,667 --> 00:27:13,234
то мы могли просто подключать разные вещи.

665
00:27:13,234 --> 00:27:15,033
И мы использовали немного Python'овской магии,

666
00:27:15,033 --> 00:27:16,601
чтобы сделать работу с этими вещами прозрачной,

667
00:27:16,601 --> 00:27:19,200
так, чтобы 99% кода нам не пришлось менять,

668
00:27:19,200 --> 00:27:22,667
что довольно хорошо.

669
00:27:22,667 --> 00:27:24,968
Ок, кажется у меня

670
00:27:24,968 --> 00:27:26,767
к сожалению, кончилось время на вопросы,

671
00:27:26,767 --> 00:27:28,133
спасибо за то, что слушали.

672
00:27:28,133 --> 00:27:31,868
[аплодисменты]