Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Вы решили написать собственное хранилище (Илья Космодемьянский)

553 views

Published on

  • Be the first to comment

  • Be the first to like this

Вы решили написать собственное хранилище (Илья Космодемьянский)

  1. 1. Вы  решили  написать  собственное   хранилище  данных   Илья  Космодемьянский  
  2. 2. Данные  •     Традиционно  хранят  в  СУБД  •     Данные  нужно  хранить  надежно  •     С  данными  нужно  производить  действия:  CRUD  •     CR  –  «просто»,  UD  –  «сложно»  •     Хранилища  данных  имеют  специализацию  
  3. 3. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»   •     Уперлись  в  мастер   •     Медленные  join’ы   •   «И  вообще  все  криво»   •   «Хотим  искать  максимальную  клику  графа  и  чтоб  нам  за  это  ничего  не  было»  
  4. 4. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Postgres,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»   •     «Не  репликация  а  черти  что»   •     «Не  смогли  научить  использовать  правильный  индекс»   •     «И  вообще  все  криво»   •     «Хотим  найти  все  циклы  в  произвольном  графе  и  чтобы              нам  за  это  ничего  не  было»  
  5. 5. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Postgres,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Oracle,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»   •     «Хотим  мультимастер  в  две  стороны»   •     «Не  смогли  научить  использовать  правильный  индекс»   •     «Очень  сложно,  Concepts  читать  долго,  много  воды»   •     «Хотим  перемножать  матрицы  за  O(1)  и  чтоб  золотая              рыбка  была  у  меня  на  посылках»  
  6. 6. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Postgres,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Oracle,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  DB2/MSSQL/Sybase  …  whatever»  
  7. 7. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Postgres,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Oracle,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  DB2/MSSQL/Sybase  …  whatever»  •     «А  давайте  запилим  что-­‐нибудь  высокотехнологичное  –  будем  как…»  
  8. 8. Зачем  писать  свое  хранилище?  Распростарненные  случаи  •     «Делали  на  MySQL,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Postgres,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  Oracle,  устали  –    теперь  хотим  чего-­‐либо  более  светлого»  •     «Делали  на  DB2/MSSQL/Sybase  …  whatever»  •     «А  давайте  запилим  что-­‐нибудь  высокотехнологичное  –  будем  как…»  •     «Чтоб  разгрузить  БД,  нужно  простенькое  быстрое  хранилище»  !!!  
  9. 9. Вобщем  решили  писать  с  нуля  Ну  или  почти  с  нуля  –  не  суть  ;-­‐)  
  10. 10. Надежность  хранилища  Mission  cri>cal?  Перевод  денег  со  счета  на  счет  в  банке   Где  граница?  Порядок  постов  во  френдленте  
  11. 11. Надежности  мешают  отказы   Хороший  термин  Failure,  переведем  его  как  Падение   •     Падает  железо   •     Падает  ПО   •     Непродуманый  дизайн  ПО  ведет  к  падениям   •     Нерадивый  админ  нажал  не  на  ту  кнопку  и  все  упало  Потенциальная     Случившаяся   Ошибка   Падение   проблема   проблема   (ошибка  которую     нельзя  обработать)  
  12. 12. Начинаем  с  простого   D  
  13. 13. Добавляем  надежность   Простое  и  логичное  решение!  D1   D2   D3  Dm  
  14. 14. Это  был  подход     «Чтобы  не  падало»  Почему  плохо  •     Сразу  две  проблемы  –  и  с  чтением  и  записью  •     Непроизводительно  
  15. 15. Быстро  поднятое  не  считается   упавшим  •     Исходим  из  того,  что  система  всё  равно  когда-­‐нибудь  может  упасть  •     Минимизируем  потери  
  16. 16. Атомарность   D1   D2  Такая  последовательность  действий  восстановима  
  17. 17. Конкурентный  доступ  S  =  1000RUR  send_money(S,  B,  100  )      A1   A1   затем   A2   или  send_money(S,  B,  200  )      A2   A2   затем   A1  S  =  900RUR  ?    S  =  800RUR  ?  S  =  700RUR  !  
  18. 18. Конкурентный  доступ  S  =  1000RUR  send_money(S,  B,  100  )      A1   A1   затем   A2   или  send_money(S,  B,  200  )      A2   A2   затем   A1  S  =  900RUR  ?    S  =  800RUR  ?   ИзоляцияS  =  700RUR  !  
  19. 19. Конкурентный  доступ  S  =  1000RUR  send_money(S,  B,  100  )      A1   A1   затем   A2   или  send_money(S,  B,  200  )      A2   A2   затем   A1  S  =  900RUR  ?    S  =  800RUR  ?   ИзоляцияS  =  700RUR  !  Восстановимость  +  изоляция  =  атомарность  
  20. 20. Свойства  действий  с  блоками  данных  •     Атомарность  •     Целостность  –  набор  правил  для  данных  •     Долговечность    Действие,  обладающее  такими  свойствами  есть  транзакция  
  21. 21. Быстрая  восстановимость   •     Версии   D0   D1   VN   Если  все  действие  прошло  успешно,  А  если  упали  на  смене  VN?    достигнут  Commit  point  
  22. 22. Быстрая  восстановимость  •     Версии  •     Пишем  лог    Изоляция/корректность  –  легко  без  производительности
  23. 23. T1   T2   r1[x]   w2[x]   w1[y]   w2[y]   -­‐  корректная  история   История  корректна  если    r1[x]   w2[x]   эквивалентна     Направление  стрелок  –     последовательному    w1[y]   w2[y]   порядок  выполненения   выполнению  транзакций  –     сериализуема   конфликтующих  действий   Граф  действий  /  граф   T2   конфликтов   T4   Некорректная  история  –    T1   Если  нет  циклов,  то   историю  на  которой  он   падение  и  нарушение  целостности   построенможно   T3   сериализовать  
  24. 24. 2PL  •     с  конфликтами  борятся  блокировками  –  блокирующий  шедулер  •     двухфазное  блокирование  –  сначала  выставляем  все  блокировки,  ни  одна                блокировка  не  может  быть  снята  пока  не  выставлены  все    •     С  помощью  2PL  мы  добиваемся  изоляции  при  сохранении          производительности  
  25. 25. Мы  построили  хранилище  на  отдельно  взятой   машине  •     Объективно  машина  не  справляется.  Что  дальше?  •     Scale  out  –  репликация  и  шардинг  •     Асинхронный  месседжинг  –  очереди  –  что  они  дают  •     Распределенные  транзакции  –  если  до  этого  было  еще  не  страшно  
  26. 26. Нерассмотренные  важные  моменты  •  Сеть и производительность•     Мониторинг  •     capex/opex  
  27. 27. Возвращаемся  к  постановке  задачи  •  Данные не должны браться из ниоткуда и не должны пропадать•  Данные связаны между собой•   Устранены-­‐ли  проблемы  по  которым  нас  не  устраивала  СУБД  •   Сколько  мы  на  это  все  потратитли  и  сколько  еще  потратим?  

×