Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
Бинарные
(файловые)
хранилища
Даниил Подольский
Git in Sky
страшная сказка с
мрачным концом
Немного теории
•  Файл (англ. file) — именованная область
данных на носителе информации
–  Слишком большая, чтобы
обращаться с ней как с единой
сущностью
•  Краеугольный камень современного
массового обмена данными
–  Наследие мрачных времен
медленных каналов
Файловые хранилища
Сегодня следует переименовать в
«отдавалища»
•  В бизнес-требованиях не написано
«хранить файлы»
–  Даже когда написано – это ошибка
•  В бизнес требованиях написано
«отдавать файлы»
•  Но отдать можно лишь то, что имеешь
Еще чуть-чуть теории:
файловые системы
•  винтажные и журналируемые
•  плоские и иерархические
•  контроль доступа и
расширенные атрибуты
И еще: POSIX
•  Стандарт на интерфейс файловой системы
–  Open
–  Read
–  Write
–  seek, который мы ненавидим
•  Случайное (не последовательное) чтение
•  Случайная (не последовательная) запись
•  Операции атомарные и нет
И последнее:
bells and whistles
•  сжатие, шифрование,
дедупликация
•  snapshots
Самое последнее
•  Кеширование чтения
•  Кеширование записи
HighLoad – это сеть
•  Протоколы доступа
–  stateless
–  statefull
•  двуличная bitch отказоустойчивость
–  целостность данных
–  бесперебойные запись и чтение
•  consistency-availability-partition
Так в чем проблема?
Берем большую-
пребольшую СХД и…
•  локальный кеш?!
•  конкурентная запись?!!
•  Берем OCFS2 и…
–  Как “падают виртуалки”?!
–  И почему так медленно?
•  А еще большую-пребольшую СХД довольно
трудно получить в свое распоряжение
Берем CEPH/Lustre/
LeoFS и…
•  Почему так медленно?!
•  Что значит “ребалансинг”?!
•  И вообще – атомарные операции
такие атомарные
А СУБД?
Нельзя просто так взять и сложить
все файлы в базу
Резервное
копирование
•  Не, не слышал
•  Резервное копирование – это НЕ
отказоустойчивость
Что же делать?
А какова задача?
•  А надо ли экономить?
•  POSIX - нужен ли он?
•  Большие файлы - нужны ли они?
•  Атомарные операции - нужны ли они?
•  Версионирование - нужно ли версионирование?
•  Насколько большим должно быть наше
хранилище?
•  И собираемся ли мы удалять файлы?
•  И каков будет профиль нагрузки?
I’m feeling lucky
•  для некоторых сочетаний
требований решение есть!
•  А для остальных - решения нет.
Так что же все-таки
делать?
•  искать бюджет
•  все-таки сложить все файлы в базу
–  личное мнение докладчика
•  написать свое
–  не так это и сложно!
–  но все же довольно сложно
Вопросы?

More Related Content

Бинарные (файловые) хранилища: страшная сказка с мрачным концом / Даниил Подольский (Qmobi.Com)

  • 3. Немного теории •  Файл (англ. file) — именованная область данных на носителе информации –  Слишком большая, чтобы обращаться с ней как с единой сущностью •  Краеугольный камень современного массового обмена данными –  Наследие мрачных времен медленных каналов
  • 4. Файловые хранилища Сегодня следует переименовать в «отдавалища» •  В бизнес-требованиях не написано «хранить файлы» –  Даже когда написано – это ошибка •  В бизнес требованиях написано «отдавать файлы» •  Но отдать можно лишь то, что имеешь
  • 5. Еще чуть-чуть теории: файловые системы •  винтажные и журналируемые •  плоские и иерархические •  контроль доступа и расширенные атрибуты
  • 6. И еще: POSIX •  Стандарт на интерфейс файловой системы –  Open –  Read –  Write –  seek, который мы ненавидим •  Случайное (не последовательное) чтение •  Случайная (не последовательная) запись •  Операции атомарные и нет
  • 7. И последнее: bells and whistles •  сжатие, шифрование, дедупликация •  snapshots
  • 8. Самое последнее •  Кеширование чтения •  Кеширование записи
  • 9. HighLoad – это сеть •  Протоколы доступа –  stateless –  statefull •  двуличная bitch отказоустойчивость –  целостность данных –  бесперебойные запись и чтение •  consistency-availability-partition
  • 10. Так в чем проблема?
  • 11. Берем большую- пребольшую СХД и… •  локальный кеш?! •  конкурентная запись?!! •  Берем OCFS2 и… –  Как “падают виртуалки”?! –  И почему так медленно? •  А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
  • 12. Берем CEPH/Lustre/ LeoFS и… •  Почему так медленно?! •  Что значит “ребалансинг”?! •  И вообще – атомарные операции такие атомарные
  • 13. А СУБД? Нельзя просто так взять и сложить все файлы в базу
  • 14. Резервное копирование •  Не, не слышал •  Резервное копирование – это НЕ отказоустойчивость
  • 16. А какова задача? •  А надо ли экономить? •  POSIX - нужен ли он? •  Большие файлы - нужны ли они? •  Атомарные операции - нужны ли они? •  Версионирование - нужно ли версионирование? •  Насколько большим должно быть наше хранилище? •  И собираемся ли мы удалять файлы? •  И каков будет профиль нагрузки?
  • 17. I’m feeling lucky •  для некоторых сочетаний требований решение есть! •  А для остальных - решения нет.
  • 18. Так что же все-таки делать? •  искать бюджет •  все-таки сложить все файлы в базу –  личное мнение докладчика •  написать свое –  не так это и сложно! –  но все же довольно сложно