System Design с Валерием Бабушкиным | Выпуск 1 | Собеседование | karpov.courses

Транскрипция видео:

• так алексей привет меня зовут валера сегодня с тобой пройдем замечательность на самом деле больше чем 45 минут 45 минут будет у зрителей возможно чуть больше а мостовой проведем может быть час с копейками по дизайнам какую-нибудь штуку интересно но прежде чем мы начнем дизайн какую-то штуку расскажи вообще почему ты здесь что-то делаешь заявки вы принимали на собеседовании просто было скучно на уроке я решил отправить где сейчас учительница не ну ты не искал какой урок поэтому учительница не узнают да и неплохо на я написала то

  00:00:01 - 00:01:13

• что стал победителем соревнования и джорни до который в этом году проходила а что там делал формально там международный конкурс по искусственному интеллекту для детей так и делать о том что у нас была задача у нас было две задачи я построил модель и проверять гипотезы чистил данные все такая задачка к да надо называлась официально подбор персонала у нас есть данные как описание вакансии вот заголовок вакансии какие-то еще табличные данные и надо было сначала предсказать что это за профессия а уже

  00:00:41 - 00:02:06

• затем какую зарплату могут ожидать люди из этой вакансии забавно потому что в шестнадцатом году мы в команде в которое у нас тоже были школьники но сейчас он уже не школьник тоже учатся ли в хакатоне на вот точно такую же тему видишь прошло пять лет задачах которых не изменились видимо эта проблема еще нормально не решена во первых когда мы так и не сказать чем nexia занимается алексей заниматься тем что у час вадинском классе и заканчивает школу но понятно уже мы видим как он учиться на уроках что

  00:01:24 - 00:02:37

• браузер в интернете подает заявки в разные места побеждает конкурсах что на сегодня собеседование обычно вообще на и собеседование приходят люди сеньор на уровне или которые думают сеньор но уровни но мы решили попробовать конце концов что мы теряем получаем какой-то мы будем дизайне систему с технической точки зрения то есть не про м.л. а что в не должно быть какие компоненты какие сервисы как аниме что мы должны общаться сколько мы должны железо подкопать какие базы данных и так далее так далее так далее

  00:01:59 - 00:03:13

• для меня это было одно из самых интересных то же время сложных собеседований потому что она бесконечно длинное а сложно насчет тем что тебе придется здесь солировать то есть я задаю вопрос даю какието водные а дальше на 40 минут я в идеальном случае замолкаю идеально случае никогда не будет и вишь ты немножко брикс все будет хорошо поэтому предлагается разно чать не тратить много времени задача следующий сервис который делает короткие ссылки то есть человек приходит тайне url или short url я не знаю

  00:02:37 - 00:03:59

• пользоваться и тогда сервисами которые сокращают ты заходишь или пользователь заходит кидает длинную ссылку не удается короткая ссылка то есть он кидает условно их нибудь 100 символов ему выдается тайне url slash какое-то количество небольшой символов и дальше когда другой человек в этой ссылке кликай товаре директная оригинальный url ну и собственно что еще можно сказать это все будем считать что это глобальный сервис которым пользуются по всему миру нужно чтобы человек мог зайти крикну посылки его на эту ссылку и директ на

  00:03:18 - 00:04:34

• оригинальную либо человек мог получить сокращенную ссылку я сразу вы пользователь сможет пользоваться что съесть получается с длинной ссылки мы должны получить короткую да и при этом короткая будет начинаться будет принадлежать по идее наши базе данных что ночь будет общий вот той не будет той неверно например the ural у нас будут для каждой ссылки да ну да и потом идет слеш и дальше уже наша укороченная версия что мы из этого понимаем у нас есть вся мы по сути любая ссылка мы должны перенаправить каким-то образом

  00:03:56 - 00:05:43

• перенаправить в нашу базу данных но таким образом чтобы не понятно будет у каждого индивидуально я получается приезжает любая ссылка каким-то образом шифруется как-то переставляются наши символы дается в более укороченным видим значит понятно что если будут две одинаковые ссылки ну каждой длинной ссылки со должна соответственно соответствовать короткая ссылка каждая короткая ссылка если только не введены какие-то ограничения по времени хороший вопрос пусть пусть у нас живет каждая короткая целка не более двух лет

  00:04:58 - 00:06:27

• ограничения по времени два года у нас значит по истечению двух лет вот этот наш какая-то последовательность уникальная освобождается и может занять в общем другой какой-то адрес это хорошо значит у нас будет [музыка] мы можем рассчитывать на то что наша база данных будет конечно увеличиваться но не так быстро то есть хранить ничего не надо бесконечно и получается что мы сможем использовать эти последовательности которые уже ранее были за но это тоже не плохо значит сможем использовать ну скажем просто старую ссылку скажем

  00:05:45 - 00:07:36

• так ссылку снова короткую суп до короткую а если задуматься над короткой ссылки интересует только последние уникальные значению продавить все остальное у нее одинаково . да ну то есть они естественно да мы говорим вот про эту часть наших назовем это ключом хорошо кибу и значит у нас понятно что будет укороченную ссылка но насколько насколько укорочены в нашем интернете может быть любой длины ссылка а здесь если мы делаем более короткую версию то мы можем вставить ограничение не то что ключ любой ключ должен быть 20 или

  00:06:57 - 00:08:42

• уменьшать количество по счету если мы же мы же четко можем сказать сколько символов нам позволяет сколько уникальный ключ и создать правду да и выбрать алфавит и там после этого все такое понятно вот в каком смысле короткая то что она будет короче чем то понятно но длинный тоже бывают разные если там 10-10 не длинная допустим 20 здесь длина ключа это длинное и 100 а тут сайте ключи так здесь домен тоже является ключом здесь как минимум домен будет плюс все что угодно после домена так что она может быть очень длинная да

  00:07:59 - 00:09:23

• вот здесь у нас разные длины вот о чем надо подумать в каком смысле будет короткой в относительном или в абсолютном то есть мы можем либо для вот допустим для ссылки с в 100 символов делать допустим короткую u20 это будет carrot пусть будет у нас всегда ключ одинаковые 1 хорошо значит у ключа мы знаем вопрос какой фиксированная длина теперь вопрос в том как нам кодировать вот эти разные длины в последовательность в разные последовательности уже одинаковой длины до надо премьер взять если у нас но тут

  00:08:40 - 00:10:36

• пусть будет да сто и двадцать мы должны преобразовать в уникальной [музыка] уникальные в уникальные ссылки но уже одинаковой длины пусть будет дан как мы это можем сделать у нас есть разные длинные как гомер как зная компьютер сайнс ты можешь привести любую вещь не фиксированные длины в вещь фиксированной длины не у нас есть не фиксированная длина мы делаем фиксированные значит мы что-то вычленяем дам из данных знаком ли ты с таким понятием как хэш функция хеширования мы можем про хэшировать и тогда

  00:09:43 - 00:11:28

• кэширование у нас выдает всегда фиксированную длину мы произведем хэширование да и тогда у нас будет 5 вот пусть как функции мы получаем действительно одинаковую длину и а какую вот я сейчас не вспомню ну ладно скажем так md5 хэш выдает нам 128 бит за двадцать восемь бит хорошо мы получили фиксированную наши длину теперь мы получили для каждого уникальная функция но здесь мы еще не совсем мы получили но 128 бит если это чисел кай выдавать это ну большая чисел k может быть можем ли мы как-то еще ужать это

  00:10:48 - 00:12:41

• то есть я и я посоветую следующим образом мы мы с тобой сейчас не знаем какая нагрузка сколько она вообще нужна уникальных ключей 10100 1000 миллион миллиардов а вид я думаю нужно подумать сначала с того насколько же нам какая же у нас нагрузка ты сколько нам вообще нужно ключей в пределе мы можем это вычислить так предполагаем что у нас мы можем очередь это подумаем сколько у нас за прошлый день может быть ну вообще у нас есть два типа запросов во-первых начнем центру у нас может быть сопровождаться то можно воспользоваться

  00:11:55 - 00:13:19

• поэтому мы сейчас говорим для начала про создать ссылку то есть у нас есть райт request когда мы записываем что-то эрид когда мы что-то считываем первый вопрос у нас сервис какую сторону смещен у нас преимущественно в рай 3 квест или редре квеста понятно что чаще переходить перед хайве хорошо это мы знаем это мы запомним получается да чаще переходим по ссылке но сначала про нагрузку общую подумать то есть у нас есть райт нагрузка ритм нагрузка подумал к ним если у нас считывается ссылка то что получается мы нажимаем на вот эту

  00:12:42 - 00:14:04

• сначала подумать сколько мы ссылок создаем в день прикинуть числа допустим миллион миллион ссылку хорошо миллион целый день мы знаем что мы храним два года правильно то есть сколько у нас в базе должно быть ключей минимум миллион допустим пусть будет тысяча четыреста дней в году так у нас знаете сотру вот это у нас понятно у нас миллион да ссылок в день ну пусть будет типа год 400 дней для простоты вычислений и умножаем на 2 года получается у нас 10 примерно такой ссылок у нас в базе данных ну и собственно за два года столько

  00:13:26 - 00:15:10

• ссылок мы создадим получается для каждого до отвести свое место и как раз такие вот каждая ссылка будет у нас уникальный а теперь вопрос сколько места под это нужно да и ну допустим хотя зависит размер ключа на ключ у нас будет какой-то она обычно бывает ну примерно 15 подожди подожди не спешит смотрим прежде чем быть 1510 или восемь нас уже есть цифра 8 на 10 8 правда то есть мы в принципе уже знаем сколько у нас ключей в базе данных будет мы бы хотели конечно иметь некоторый запас то есть у нас одно из ограничений наш ключ должен

  00:14:27 - 00:15:53

• поддерживать уникальный что многое зги не ровать этих уникальных ключей как минимум не меньше чем вот это количество нато если мы можем всего тренировать уникальных 10 6 ключей это наверно не хорошо если ты говоришь 15 символов сколько это уникальных ключей посчитай во-первых какой уфа вид как ты не раз говорил так мы должны прикинуть сколько у нас бит на один символ но пусть будет они там должно быть число определенную допустим я тебе дам подсказку что есть base64 encoding который позволяет тебе

  00:15:11 - 00:16:27

• каждый символ имевшихся четыре варианта соответственно четыре варианта то это 2 в шестой то есть это 6 бит рос бит у нас дано каждому на если у нас d64 теперь представим допустим у нас в этом до 64 ключи 10 символов сколько это у нас вариаций у нас в ключе 10 символов у нас круче 10 символов каждый по 6 бит каждый до 64 позиция имеет к ну понятно если он имеется четыре вариации этого 640 не надо подождать из да у нас на каждый символ 664 варианты значит 64 у нас 10 степи 10 минут запишись от 450

  00:15:53 - 00:17:22

• при ключа 10 при ключе нашим 10 символом и 6 бит на символ 64 10 но это 2 в 60 ну и сравним вот с этим например 2 60 уникальных последовательностей 2 в 60 мы знаем что есть 82 в 3 до 10 8 у нас неплохо будет сравнить я рассчитаю не четыре в 10 читали очень хорошо но я точно знаю что 16 больше чем 10 правда но 16 больше чем 10 конечно значит а 16 это 2 в четвёртой значит и 260 ты можешь представить как 2 4 еще в какой-то степени правда ну да да да то есть разбить это у нас будет 16 в 15 а тут у тебя 10 8

  00:16:38 - 00:18:56

• ну то есть здесь прям сильно сильно больше сильно-сильно больше сильно сидим мы можем всех зачем нам нужно хорошо оставляем кодирование таким какого я найду это точно в даже от этого не станет у этого есть некоторые до 100 грамм надо оптимизировать количество символов в нашей короткой ссылки тогда мы получим приемлемый для нас вариант ну что мы можем сделать мы можем просто подобрать например 8 сколько у нас тогда будет да у нас 4 8 это 16-го 2 4 у нас будет 64 до 8 это у нас будет два в 48 то есть

  00:18:03 - 00:19:43

• 16 в 12 но это тоже больше но уже лучше смотри ты уже у уменьшил количество место которое нам нужно на 20 процентов и при этом утечка падая что нам теперь для ключа нужно не не 10 а 8 символов а это сокращение 20 процентов ну хорошо допустим мы подберем пусть 8 удалит тут мы можем дальше уходить да зачем давайте пусть у нас длина нашего ключа будет восьмерка допустим и тогда у 82 больше 8б с 64 запиши чтобы мы не забыли до что у нас тренировка то что может это восемь бит и мы тоже не 8 бит правда это скорее 48 бит

  00:19:01 - 00:20:41

• хорошо мы подготовили нашу базу данных мы знаем то что у нас все будет нормально с количеством ссылок нужно ли как кодировать ну то есть при помощи кэширования устраивать мы не совсем знание делегировать еще почему потому что мы посмотрим у нас удается 128 бит а берем мышцы от 4 даже читать 448 потому что писали что им до 5 даёт нам 128 md5 md5 хэш а потом мы берем боишься 4 а нам относят 4 нужно всего 48 бит нужно всего лишь 48 бить но мы можем использовать другой тип расширении мы любим пошел сможет взять 1 48 бит или

  00:19:54 - 00:21:35

• просто dotech не нужен но это увеличивает риск коллизий запишем пока это перейдем к этому что можем увидеть риска литий ну понятно что если мы хэш как-то обрезаем хэш сам по себе имеет возможность коллизий если хошь еще уменьшать но представь что мы хэш берем один бит понятно что у нас может быть много ходить закончить эти при урезанном хэширование мы вообще при любом на урезанная просто повышает этот риск а вот мы с тобой это делаем на лету то есть нам приходит какая-то ссылка мы ее через хэш мы верим от него 1 48

  00:20:44 - 00:22:09

• бит переводим это в 60 боишься 4 и говорим это уникальный ключ ну и пихаем потом наверное как искал в себе в базу данных а затем как 4 это другой вопрос но этому придем а можно ли вот эту всю систему обряд нас есть риск ализе то есть к лизе их нужно как-то решать это неприятно а вот если задуматься а можем ли мы как-то заранее подготовиться и на летун генерировать ключ а просто что-то уже заранее подготовлено использовать можно использовать структуру дерева возможно и не ты ты куда-то в сложные вещи уходят как

  00:21:35 - 00:23:04

• подготовиться заранее когда вот и ты ключ на ли тут же с генерируешь к мужу начинали ту мы взяли хэш от оригинального урла от этого хэша взяли первые 48 бит эти первые 48 бит превратили в себя 4 прилепили сказали это ключ но есть риск alizee здесь правда ведь потому что может быть так что два разных url они могут по md5 в коллизию попасть ну а мы говорим по первым 48 у них еще выше может даже посчитать на сколько раз выше риск ализе многократно но можно ли как-то подготовиться так чтобы на лету не

  00:22:20 - 00:23:32

• считать и коллизии миновать если мы не считаем на лету это значит по сути нам по сути мы не используем хэширования это сразу почему нет потому что это самый первый вариант ну хорошо представь я посчитал заранее тысячах и шеи вверх могу заранее посчитать тысячам просто генерировать какие-то последовательности 60 через 48 бит а потом просто каждый раз брать этот ключ кидать его брате кидать брать кидать врачи дать на той сумме 100 ключей меня по меня просят генерирует ссылку я беру первый ключ вычеркиваю его

  00:22:56 - 00:24:18

• потом не просят сгенирировать ссылку я беру второй ключ с у меня уже где-то эти ключи лежала мы сначала сгенерировали вот у нас есть уже какие-то ключи но мы можем мы же сможем брызги не ровать любые последователи включи правда вопрос мы делаем рандомный генератор конечно и кидаем откуда-то то есть заранее мы знаем что там будут приходить ну вообще лучше записывать хэш сразу ну по надобности а почему помнить базу данных ну сколько вот это будет занятие допустим мы захотим section хранить заранее все

  00:23:39 - 00:24:50

• ключи сколько это место займет займет все места которые нас есть сколько посчитаем сколько места можно у нас ключ занимает 48 бит сейчас до 48 у нас шесть байт занимает на символ шесть байт до 8 символов по шесть байт 48г шесть байт он занимает сразу же есть 40 а у нас есть смотрю нас прежде на 8 6 бит 0 до 6 байт ну ладно только запиши 66 b6 байта марок на один ключ таблицы но если получается у нас настолько то ссылок мы посчитаем сколько нужно просто сколько нам нужно хранить место мы должны занять все так 66 дней на

  00:24:14 - 00:25:54

• жопами который у нас есть шесть байт умножаем на 10 в 8 на 8 это получает сорок восемь байт на 10 8 правильно сколько это место в каком смысле ну сколько памяти мне нужно чтобы хранить все эти ключи столько посчитаем 48 на 10 8 байт это у нас что сколько это кино ну допустим это у нас хорошо прикинем 50 на 50 получаем у нас пятеркой 90 и интер мы должны с излишком хранить окажи сколько это у нас получается то очень много вот сколько много сколько это килобайт просто и разделе опять на 10 6 правда особо мире обалдения еще

  00:25:08 - 00:26:47

• делим 5 на 10 в 3 то есть это что 5 гигабайт на все ссылки но не выглядит как при реальных конечно громить и правда ведь мы можем же использовать меньше так зачем 5 гигабайт слушают можно на macbook хранить оперативки ну при задержке а ну да если у нас будет система даже одновременно использоваться с миллионами пользователей то поиск по базе данных будет это мы про это близко там уже вот вот вот эти 5 гигабайт кажется что но можно держать прям где угодно при желании это вообще я по нему это было пять петабайт

  00:26:00 - 00:27:15

• но мы сейчас от него нечестным делать но это миллион раз меньше чем пять петабайт в принципе не что нам не мешает заранее же делать сгенерировать все ключи и но допустим мы сделали все ключи что нам нужно с ним делать теперь нужно каждый каждому ключу присвоить значение которое нам вводится ну по сути записать там словарь допустим снимал но нам вот эти ключи нам нужно наверно их хранить в двух местах в двух состояниях правда ведь у нас может быть ключ что может быть ключем сделан ключ у нас создается мы можем переходить на него то

  00:26:37 - 00:27:59

• есть мы можем его либо использовать лениво либо он еще свободный да то есть нам это тоже нужно фиксировать каких-то таблицах здесь мы же не можем дать занятый ключ ссылки про конечно мы не можем это сделать почему бы не хранить что значит двух состояниях ну вот вот свободные и заняты ну да у нас будет получается дополнительно какой-то дополнительный тип данных который обозначает ну там есть дополнительный дополнительная ячейка то говорил равна таблицы заняты до занят ли адрес занят ли наш ключ или нет ячейка или все-таки

  00:27:19 - 00:28:39

• 2 разных таблиц нам нужны не а это влияет значительно подумаем в чем в чем в чем плюсы в чем минус если это одна таблица но там есть какая-то ячейка на таблице у нас получается могут быть в ключи и состоянии то занят не занят так допустим это так тогда и мне нужно выдать новый ключ что я делаю я иду по всей таблице пока не встречая 1 незанятый ключ для это неэффективно а это соответственно карта как это будет у меня каждый раз на n операции где и на то количество уже созданных ссылок ну а если у меня есть табличка где я знаю что

  00:28:00 - 00:29:15

• у меня все ключи не занята я получаю до туда могу брать первый ключ день а табличка ночи у нас есть 1 2 3 и ну допустим вот так вот надо производить линейный поиск да да и ну скорее всего мы будем то есть мы можем просто из таблички если ключи там все свободно брать всегда первый ключ делать констант на операцию то есть вмещать не занятые ключицу достаточно просто их за 1 таблички убирать и сохранить власть во вторую торгуйся соответствие нам хранить и сделать только таблицу незанятых да ты у нас просто будет там

  00:28:42 - 00:30:06

• хранится допустим этот самый ключ noise там хранится какие-то ключи и точно также есть таблица занятых да есть таблицы занятых но разве получается если у нас если у нас есть вся таблица про ключи мы можем разлить либо хранить две таблицы занятых незанятых и бы мы можем просто хранить одну огромную таблицу всех ключей и там таблицу незанятых допустим нас нет разницы если мы хранили зачем нам хранить отдано таблица всех ключей и одну таблицу не заняты ключи это тогда дублирование информации да просто вот тогда они заняты у нас

  00:29:29 - 00:30:49

• самом начале будет будут все ключ к потом при заполнении нас проходит какое-то время и постепенно пополняются таблицы занятых так более того мы когда таблицу занятых мы что еще можем записать туда в таблицу занятыми мы можем да мы еще учитываем время и и и чем он занят да и как раз таки нашу ссылку то есть у нас тут получается уже дополнительные есть ячейке у нас будет самый ключ самый ключ у нас будет будет время и будет изначальная ссылка которая есть вот пусть bass будет названо затем хорошо но сейчас когда приходит запрос

  00:30:15 - 00:32:03

• мы знаем какую таблицу идти с короткой ссылки на оригинал оправдают сkоро туда это понятно знаем там у нас спокойно мы смотрим по времени да и когда время заканчивается мы возвращаем в нашу исходную таблицу с этим у нас все отлажено ну хорошо попробуй теперь общую картинку нарисовать это мы учите когда у нас в таблице незанятых у нас все сгенерированные допустим в целом мы знаем 5 гигабайт да и когда у нас производится запись мы про ну понятно что мы делаем мы соответствие проводим с изначально нашей

  00:31:16 - 00:32:47

• совы которые хотим закодировать на проводим с временем когда она была закодируем закодированы потому что у нас ограничено по времени это ссылка и так заполняется таблица занятых потом как у нас может обновляться таблицы незанятых нас убираются ключи либо добавляются те время которых уже прошло и при этом когда считывают когда считываются то просто считываются если коротким на ссылки на этом мы сразу переходим в таблицу занятых и потом переходим просто на bass только вот коллизий так к лизе у нас уже

  00:32:08 - 00:33:26

• нет и поэтому все ключи сгенерировали заранее можно генерировать их без калязине как раз таки чтобы мы выровняли где мы мы сделали как раз таки заранее наш наше число которое мы прикинули и [музыка] получили хороший массив который у нас не будет никак выдавать какие-то ошибки и затем просто в таблицу заняты я просто перепроверяли себя вы теперь получаешь все хорошо ты знаешь в какую таблица брать ключ ты знаешь в какую то bluetooth тебе идти для redirect а попробуем расписать общей service pack

  00:32:52 - 00:34:11

• верхнего уровня так что у нас есть изначально я ссылка с точки зрения того как пользователь будет но есть пользователи у него есть 2 2 2 10 которые может захотеть сделать эти пользователь он у нас может что сделать вещь сделать ссылку либо считать перейти по ссылке считай короткую тогда если он делает ссылку то у него у нас есть он к нам приходит на какой-то сервер все равно в любом случае он придет на один сервер правда рисуем сервер вот и у нас здесь есть значит таблица не не здесь у нас ничего нет таблицы у нас

  00:33:35 - 00:35:07

• в какой-то базе данных банк данных может быть на этом сервере не может не быть на этой базы данных от отдельная сущность как он переходит допустим к серверу он обращается к серверу хорошо сервер ты все нормально рисовал нарисует что какой-то зергов все делает сервер значит каким образом он отвечает если он здесь делает ссылку то в этом с этим сервером что он получает от пользователя наш сервер исходную ссылку допустим назовем ее так он получает нашу исходную ссылку дальше это исходная ссылка на рисуем

  00:34:37 - 00:36:10

• верхнюю равнину то есть можно не писать до исходной ссылки на сервер пойдет куда что сделать базу данных в 1 из 2 а вот сделаем вот так обращается либо он будет писать либо читать правда ведь значит что у нас делает сервер сервер отправляет команду в базу данных именно в нашу таблицу ключей до ключей либо в таблицу занятых ключи ключи у нас незанятых здесь будет получается читать ну если не заняты то здесь на самом деле жаждать здесь на самом деле будет делаться райт request то есть он сначала ключ и

  00:35:31 - 00:37:12

• забирает а потом он пива за раз а потом он пишет в таблицу и уже из таблицы он сейчас найти удобнее напишу еще нас пользователь если сделать ссылку либо считать короткую он отправляет запрос у себя на сервер наш ну и соответственно считать он идет в таблицу занятых правда да здесь конечно нас быть таблицы ключей которые уже заняты затем давайте сначала здесь записать у нас то есть надо сделать соответствии с незанятых ключей в наши ключи заняты добавить давайте запишем это добавить я вот так вот сделал у

  00:36:29 - 00:38:06

• нас должен выдаваться ключ пользователем ключ пользователь ну вот наша ссылка не суть важно и тот же самый ключ у нас будет записываться в уже таблицу занятых да то есть но как именно будет записываться наш ключ будет записываться время и исходная ссылка [музыка] на это при помощи нет мы это сделали до этого хэширования поэтому здесь уже когда пользователь использовать наш сервер то этого нет так смотрю на все есть верхний уровневый сервис верхние уровни он он плюс-минус работает ясно пойдем чуть глубже на

  00:37:34 - 00:39:18

• первый момент который нам еще нужно затронуть мы ж с тобой посчитали сколько нам нужно памяти место для таблицы ключей да но ведь для таблицы занятых ключей нам нужно совершенно другое количество места правда ведь почему и сколько места нам нужны она занимает занимает память еще время и исходная ссылка которая сколь ранить если мы там отправляем сколько было у нас над голубым сила 8 на 10 8 запросов 8 на 10 8 запросов за 2 года до и ну и рано или поздно нас таблица занятых заполнится как раз этим количеством

  00:38:29 - 00:39:49

• правда надо полностью мы должны это она должна быть даже желательно чуть больше у нас будет добавляться наш ключ по памяти который обнимает ну ключ-ключ время знаем ключи это уже 5 гигабайт да у нас есть можно должны мы еще оставить место для времени и для исходной шилки исходная ссылка у нас сколько будет занимать среднем если у нас занимает короткая сколько на почитали шесть байт часть байт давно занимает короткая а исходная сколько может среднюю занимать и надо разобрать средние но мы можем предусматривать что какое-то

  00:39:11 - 00:40:28

• максимальное количество мне-то какая разница все мы мы мы мы же сейчас оцениваем не схему данных и мы говорим там хранится строка строка может произвольной длины правдой но нам же нужен пример сколько нам памяти нужно под базу то есть если мы сейчас точно и что нужно пять терабайт окажется пять петабайт это проблема ну вот у нас эта строка в среднем сколько можно занимать опустим тридцатку 30 байт или больше пусть 100 байт ну вот мы должны взять я как хотел должны ведь максимальное ну визуально может быть и 500 байт эти

  00:39:50 - 00:41:11

• такой но в средам же в среднем нужно на живот 8 на 10 8 будет этих сук ну ссылки 500 байт со всякие те метки переходы тогда если мы верим в средней этому уравновешено но если у нас произойдет там какая-то атак а вот про это мы поговорим но если дать ему не успеем уже по говорится вот 100 байт средняя ссылку на flash с тобой сколько нам нужно место вступает у нас на одну ссылку да у нас столько запросов мужчин рассмотреть получше проще посчитать его как мы знаем что у тебя 5 гигабайт это при ссылке в шесть байт

  00:40:30 - 00:41:49

• правда ну и соответственно нас тобой да у нас больше это но в 7 раз допустим но не в 717 если 100 разделить на 6 получается 16.6 получается поэтому 17 на 5 17 у нас сколько 8 5 гигов + 5 получаем 90 но это еще никита без времени время сколько занимает время что мы должны допустим с момент вот сделаем отсчет времени у нас с того момента времени когда первый пользователь наш новый имидж unix тайме хранится делаешь петрограда можем сэкономить ну вот что ты жадный сколько хорошо вот uniq ставим сколько это

  00:41:10 - 00:42:47

• займет ну сколько указываете вниз то я не значит ну сколько четыре байта да пусть 8 найти 10 лет здесь ну ладно это еще 10 гигов да не так критична ну то есть суммарно печали 100 гигов на мгновение так все мы знаем что это 100 гигов на таблицу занятых ключей нет на общем на таблицу на нет ключей на общее 5 гигов нужен на незанятых ну смысле у нас было 5 гигабайт 155 одна таблица единство другая но она мы же будем записывать постепенно почему у нас будет 5 гигабайт незанятая таблицы и ключи было столько же там

  00:41:59 - 00:43:37

• занимать мы же будем короля те заодно и сохранять другую конечно можно сказать что мы хотим сэкономить 5 гигабайт ладно это может конечно суммарно 100 гигабайт потому что мы из одной перезаписываем другое но допустим хорошо с допустим мы сэкономили бы получили 100 вообще-то также можно хранить на компе до сих пор нет ну отдельно купить какой то комп и подниму все хранить но мы сейчас с тобой нарисовали эту картинку это у нас как раз реализовано ровно на одном компе теперь представьте что она же может быть

  00:42:51 - 00:44:16

• это реализовано до инфраструктуры для нас больше одного компа потому что мы например я сейчас хочу сказать у нас мы до сих пор не знаем как у нас запросов в секунду поэтому мы можем это посчитать еще нас да просто прикинем тут ты ж сам сказал сколько у нас там в день запрос миллион на создание на миллион на создана запись миллион на запись миллиона записи на сколько секунд но 100000 пусть будет 86 лет четыреста и любишь округлять ладно пусть 100 тыс у нас будет более 100 тыс секунд до так и сколько запросов в секунду

  00:43:34 - 00:44:56

• значит если если у нас столько запросов 100000 это у нас есть 5 на получаем 8 тысяч за просто че это за два года у нас в день таскал миллион а в день у нас точно ошибся в день у нас миллион вопросов и получаем 10 запросов в секунду так 10 запросов на запись запиши но ты мне сказал что у нас это рид хайдер то есть у нас на чтение будет больше запрос да на считывание это у нас на запись сделать короткую ссылку отсчитывать мы как часто будем считывать получается у нас один пользователь делится вообще всем

  00:44:18 - 00:45:53

• создают одну ссылку и кто ты сам стал что мы чувствуем гораздо больше чем да да насколько просто это будет получается по всему окружению допустим идти ну пусть 100 запросов на 100 раз чаще не до 1000 запросов в секунду 1000 куб с напишите пия зачем приперся концы забрал у нас gps и можно поставить слеш r назад на на чтение точно также кпс w согласить гораздо быстрее так писать не gps на g5 от друга и ну вообще это возникает вопрос и сколько один сервер способен держать connection of участь мы должны держать все подключения

  00:45:10 - 00:46:51

• у нас и на записи на считывания 3 второй момент ты не спросила меня на эти скажу что мы хотим чтобы latency было у нас небольшая 200 миллисекунд донецка но будет би си джи из этой посылки 10 секунд переходит но если у нас производится задержка 10 секунд мнимых нас это будет бесить этим 200 миллисекунд 200 хорошо у нас 200 миллисекунд получается мы можем делать у нас получается когда мы переходим уже посылки то есть это относится к считыванию у нас до их записи каким быстро персонально просто мои

  00:46:05 - 00:47:30

• пишешь быстро записать в целом их этим сервисом работать довольно быстро понятно но мы можем в принципе человек когда переходит по ссылке может не так много времени может подождать побольше времени к этому записывала запись допустим хорошо но 200 миллисекунд мы хотим нарядить там чуть побольше не будет хотя с другой стороны мы знаем что нас считывают 100 раз чаще и мы получили нашу задержку так на этом мы сейчас тогда уже не успеем 145 не заканчивается будем сейчас разбирать садись расслабляйся молодец что мы

  00:46:50 - 00:48:10

• сделали с тобой мы с тобой записали система для одной машины правильно в принципе 0 пользователь что-то там делает куда-то обращается теперь подумаем если бы мы хотели она во-первых я записал некоторые советы тебе на жизнь но сначала 1 мне понравилось я думаю тебе нет на кратно говорили что когда я был в твоем возрасте и такого не делал говорили такой час калека ну как понятно когда как иногда говорят разные вещи на говорили тебе такое конечно ну вот не буду тогда повторяться в целом значит первое что нужно всегда

  00:47:34 - 00:48:50

• сделать когда ты дизайнер системы есть такая вещь как cup теорема не все с ней согласна есть на самом деле адаптированы весе по царь теорема она заключается в том что мы когда строим сервис мы задумаемся какие вещи не должны быть constic консистентной доступность или надежность каким-то разрывом соответственно это тоже ну что разговорить мы хотим чтобы у нас была высокая доступность быстрая скорость ну и про консистентная для нас это не столь важно хотя тоже было бы неплохо себя по данной ссылке

  00:48:12 - 00:49:27

• человек переходил в одно и то же место ты тоже нужно как-то организовать и мы с тобой производили расчетах хук нам нужно место и прочего в самом самом самом конце уже какую ссылку на запрос а вот мы сейчас считаем сколько запросов в секунду сколько нужно памяти поэтому первое что ты спрашиваешь это условно нужно cup ограничение но это прям буквально одну секунду потом ты производишь расчеты а расчеты какие какой куб с сколько памяти все это и водный соответственно 5 гигабайт сразу понимаем а можем хранить не можем хранить дима

  00:48:50 - 00:50:12

• это обще можем хранить дальше я сама переходим к вопросу о масштабируемости то от нас есть пользователь а мы с тобой обсудили что он может быть много где соответственно глобально по миру раскидано для того чтобы обеспечить 200 миллисекунд у наверное хотим чтобы пользователи из аргентины работал сервером южной америки не будет работать сервером сервером в европе то мы можем посчитать что только на это у нас идет какая какое-то количество времени потому что есть даже скорости рст ранения сигнала как ограничение соответственно у

  00:49:31 - 00:50:48

• нас пользователь должен идти наверно какой то load balancer балансировщик нагрузки знакомый тебе это понять конечно воды соответственно понять что убил enter на самом деле ни один их так я нарисую что их несколько дальше у нас есть какой-то сервер и соответственно у нас есть как мы сказали у нас есть райт request и у нас есть ридриг вес так запишем дальше у нас есть сервер новый понятно что он тоже у нас несколько возникает вопрос этот сервер если он что-то считывает если мы считаем это из таблицы мы из этой таблицы

  00:50:09 - 00:51:36

• считывать будем если это какая-то сирийской аль таблица но летчика 2 за можем долго это считывать поэтому мы это каширу им в принципе мы вообще посчитали что можем все кэшировать на самом деле нам в принципе стол столько памяти что мы можем все все в кэш пихать поэтому первое что он идет он идет в кэш это если ридриг вас правда ведь понятно что райтер квеста не может войти в кэше он пошел в кэш если он в кэш конечному либо возвращает что-то и он возвращает либо как говорит ничего нет и тогда мы мы можем из кэша идти можем

  00:50:56 - 00:52:24

• отсюда идти на на что мы идем вот у нас редре квест в кэше этого нет мы идем в нашу таблицу вопрос какая у нас должна быть таблица в таблицу мы идем по ключу же правильно соответственно нам не нужна какая-то реляционная база данных нас устроит какая то но у сиквел система киви лью но даже люди любой это может быть тайным а это может быть те кассандра все что угодно идем сюда но проблема в том что в принципе мы ведь можем здесь найти рид request а можем и не найти правда ведь потому что может быть не существует

  00:51:40 - 00:53:09

• это орла поэтому дальше мы когда из базы данных если мы его достаём его кидаем в кэш ну и обратно отправляем либо либо мы отправляем not found может же такое быть теперь у нас есть какой-то key key generator сервис ноги генератор сервиса тоже таблиц поэтому мы чтобы не делать мы будем из него допустим н ключей брать ты хоть и в какой-то memory и уже из этой memory мы будем забирать почему это сделано потому что представь если у нас пошло в 10 в секунду может произойти коллизия могут захотеть захватить один и тот же

  00:52:38 - 00:54:23

• ключ поэтому один тут же клим и ключи сначала выгрузим сюда и в оперативке будем лог ставить на ключ то есть мы делаем блок 1 снимает log если он идет дальше всё соответствует это более сложная система но она если ты посмотришь особо-то ну не отличается от того что я писал на одной картинке есть здесь добавился лот балансир дальше можно справить задать вопрос а данные как мы будем партиции ровать у нас же сервера мы в принципе в нашем случае можем вообще все хранить везде потому что у нас весь раздел весь размер

  00:53:40 - 00:55:11

• бас таких что нам даже птицы ровать ничего не нужно 100 гигабайт на 100 гигабайт мы будем и 200 от 6 гигов оперативы поставить вообще не проблема терабайт 2 терабайта можно поставить там мы тут говорим про 100 гигабайт на все то есть мы вполне можем это держать каких-то базах данных каких-то серваках это держать как постоянное хранилище понятно что мы здесь нужно будет держать какой-то реплику но в принципе мы каждый раз можем накажем серваке все это держать оперативки при необходимости и если мы в

  00:54:28 - 00:55:35

• принципе все держим оперативки нам может быть вот особой конечно нужен потому что у нас все сразу оперативки лежит то есть я могу сказать вполне а мне и конечно не нужен узнаете почему мне конечно не нужен потому что у меня все все в кэш или же сразу все убрали лишний слой но мы можем это сказать только если мы знаем что на 100 гигабайт поэтому горе вот у меня есть база данных я сначала записываю в нее из неё кидаю в кэш из-за меня машина ломается я просто перекидываю возникает вопрос значит нужно как-то синхронизировать мой

  00:55:01 - 00:56:13

• вот здесь кэш если я все держу кгс или нет вот наверное вот эту часть я так и оставлю потому что это некий бушу я из таблицы подгружает периодически в оперативку и из нее уже всюду раздаю ну и соответственно я могу даже на каждую точку выгружать какие-то определенные ключи чтобы не было между ними никаких race conditions of ты словно говоря я могу еще вести дополнительную колонку в на какую тачку я какие ключи будут кидать в оперативку из нее выгружать правда ведь прикольно но я смогу так сделать соответственно мне что мне нужно

  00:55:37 - 00:56:57

• просто из базы каждый раз на 1 каждую машину выгружать уникальные ключи и тогда у меня никакого лог скорее ну блок может по-прежнему нужно держать может не нужна простая к серверу к сервису этому достучался тут жизнь его выгрузил единственное что мне нужно потом сказать базе что база я вот эти оба за уже знает кстати база уже знает она уже эти ключи от себя вычеркнул а потому что мы уже загрузили сюда единственное что когда ключ был использован нужно будет сообщить вот этой базе соедините и ссылкой

  00:56:17 - 00:57:33

• машина может упасть тогда те ключи которые не оперативки записаны пропадут но это не страшно будем здесь мы держать и допустим сколько ты говоришь тебе нужно 10 в секунду здесь можем держать на одном circus на здесь серваков мы пусть на одном серваке держим 10 тысяч ключей то нам на три часа хватит запаса каждый час мы еще подгружаем по по 3000 по 4 ну собственно все в общем тебе нужно сначала еще узнавать про ограничения потом расчеты проводить сразу потому что дальше эти расчеты влияют на дизайн ну а

  00:56:55 - 00:58:23

• дальше на самом деле здесь вот lancer то можно ставить здесь откровенно говоря уже даже не делал балансире может быть и на базу данных нужно может быть и нужны может быть мы хотим сказать что у нас будет несколько баз на разных машинах и мы будем их между собой синхронизировать но решать какой момент с какой из них достучаться и нам нужно будет еще один блок балансир вот здесь который уже будет дальше решать куда нам и тут у таки ну неплохо не знаю как тебе не понравилось 2 ну что спасибо что пришел пасибо надеюсь

  00:57:39 - 00:58:52

• не было и подругой на то здесь не было слишком большого стресса скорой встречи

  00:58:21 - 00:58:34