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.
Upcoming SlideShare
опыт построения и эксплуатации большого файлового хранилища
Next
Download to read offline and view in fullscreen.

Share

распределенная транзакционная версионированная Web ориентированная файловая система djarvur.ppt

Download to read offline

1. Постановка задачи, или откуда вообще взялась такая идея
1.1. десятки терабайт данных, сотни миллионов файлов
1.2. экономные заказчики - commodity hardware и хостер на букву Х
1.3. WEB контент - потребность в атомарном обновлении
1.4. отказоустойчивость - это не когда хранится, а когда отдается
1.5. Проблема резервного копирования
2. пара слов о существующих решениях
2.1. дорого
2.2. медленно
2.3. плохо работает
2.4. POSIX не нужен
3. Подробности реализации
3.1. Распределенная
3.1.1. Проблемы
3.1.1.1. Проблема файлового кеша
3.1.1.2. Проблема отказоустойчивости
3.1.1.3. Проблема репликации
3.1.1.4. Проблема ребалансинга
3.1.1.5. NoSQL кластер - наше все
3.1.2. Решения
3.1.2.1. Как мы выбирали базу
3.1.2.2. Почему Aerospike
3.1.2.2.1. Да, Aerospike нынче OpenSource и бесплатен
3.1.2.3. Почему Cassandra
3.1.2.4. Составные индексы
3.1.2.5. Транзакции
3.2. Транзакционность
3.2.1. проблемы
3.2.1.1. атомарное обновление
3.2.1.2. откат
3.2.1.3. уровень изоляции
3.2.2. решения
3.2.2.1. примерно как на симлинках, только без симлинков
3.2.2.2. создание файла
3.2.2.3. удаление файла
3.2.2.4. commit и rollback как процессы
3.2.2.5. самописная система транзакций - это весело
3.3. Версионирование
3.3.1. Проблемы
3.3.1.1. Сисадмины бывают двух сортов, или проблемы бекапа
3.3.2. Решения
3.3.2.1. Раз есть транзакции - их можно использовать как точки восстановления
3.3.2.2. На самом деле, транзакции ни при чем. Просто мы храним несколько версий файла с одним именем.
3.4. WEB-ориентированность
3.4.1. Прямой доступ по полному пути
3.4.2. Иерархические файловые системы не нужны
3.5. Файловость
3.5.1. FUSE как интерфейс
3.5.2. Совмещение абстракций “транзакция” и “точка восстановления” с абстракцией “файл”
3.5.3. На самом деле - файловая система не нужна
3.6. Под капотом
3.6.1. Проблема больших файлов
3.6.1.1. Chunks
3.6.1.2. Bunches
3.6.2. Кое что задаром
3.6.2.1. Дедупликация
3.6.2.2. Сжатие на лету
3.6.2.3. Экономия канала
3.6.3. Двухфазное удаление
3.6.3.1. удаление как таковое не нужно
3.6.4. Transaction keeper как единая точка отказа
4. Коротко об опыте эксплуатации
5. Где взять
5.1. https://github.com/Djarvur/djarvurfs.git

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

распределенная транзакционная версионированная Web ориентированная файловая система djarvur.ppt

  1. 1. Распределенная транзакционная версионированная web-ориентированная файловая система Djarvur Даниил Подольский, Git in Sky
  2. 2. Постановка задачи, или откуда вообще взялась такая идея •  десятки терабайт данных, сотни миллионов файлов •  экономные заказчики ­ commodity hardware и хостер на букву Х •  WEB контент ­ потребность в атомарном обновлении •  Отказоустойчивость ­ это не когда хранится, а когда отдается •  Проблема резервного копирования
  3. 3. Пара слов о существующих решениях •  Дорого •  Медленно •  Плохо работает •  POSIX не нужен
  4. 4. Подробности реализации: Распределенность Проблемы: •  Проблема файлового кеша •  Проблема отказоустойчивости •  Проблема репликации •  Проблема ребалансинга •  NoSQL кластер - наше все
  5. 5. Подробности реализации: Распределенность Решения: •  Почему NoSQL •  Как мы выбирали базу •  Почему Aerospike –  Да, Aerospike нынче OpenSource и бесплатен •  3.1.2.3. Почему Cassandra •  3.1.2.4. Составные индексы •  3.1.2.5. Транзакции
  6. 6. Подробности реализации: Транзакционность Проблемы •  Атомарное обновление •  Откат •  Уровень изоляции
  7. 7. Подробности реализации: Транзакционность Решения •  примерно как на симлинках, только без симлинков •  создание файла •  удаление файла •  commit и rollback как процессы •  самописная система транзакций – это весело
  8. 8. Подробности реализации: Версионирование Проблемы •  Сисадмины бывают двух сортов, или проблемы бекапа
  9. 9. Подробности реализации: Версионирование Решения •  Раз есть транзакции - их можно использовать как точки восстановления •  На самом деле, транзакции ни при чем. Просто мы храним несколько версий файла с одним именем
  10. 10. Подробности реализации: WEB-ориентированность •  Прямой доступ по полному пути •  Иерархические файловые системы не нужны
  11. 11. Подробности реализации: Файловость •  FUSE как интерфейс •  Совмещение абстракций “транзакция” и “точка восстановления” с абстракцией “файл” •  На самом деле - файловая система не нужна
  12. 12. Под капотом: Проблема больших файлов •  Chunks •  Bunches
  13. 13. Под капотом: Кое что задаром •  Дедупликация •  Сжатие на лету •  Экономия канала
  14. 14. Под капотом •  Двухфазное удаление –  удаление как таковое не нужно
  15. 15. Под капотом Transaction keeper как единая точка отказа
  16. 16. Коротко об опыте эксплуатации
  17. 17. Где скачать •  https://github.com/Djarvur/djarvurfs
  18. 18. Вопросы?

1. Постановка задачи, или откуда вообще взялась такая идея 1.1. десятки терабайт данных, сотни миллионов файлов 1.2. экономные заказчики - commodity hardware и хостер на букву Х 1.3. WEB контент - потребность в атомарном обновлении 1.4. отказоустойчивость - это не когда хранится, а когда отдается 1.5. Проблема резервного копирования 2. пара слов о существующих решениях 2.1. дорого 2.2. медленно 2.3. плохо работает 2.4. POSIX не нужен 3. Подробности реализации 3.1. Распределенная 3.1.1. Проблемы 3.1.1.1. Проблема файлового кеша 3.1.1.2. Проблема отказоустойчивости 3.1.1.3. Проблема репликации 3.1.1.4. Проблема ребалансинга 3.1.1.5. NoSQL кластер - наше все 3.1.2. Решения 3.1.2.1. Как мы выбирали базу 3.1.2.2. Почему Aerospike 3.1.2.2.1. Да, Aerospike нынче OpenSource и бесплатен 3.1.2.3. Почему Cassandra 3.1.2.4. Составные индексы 3.1.2.5. Транзакции 3.2. Транзакционность 3.2.1. проблемы 3.2.1.1. атомарное обновление 3.2.1.2. откат 3.2.1.3. уровень изоляции 3.2.2. решения 3.2.2.1. примерно как на симлинках, только без симлинков 3.2.2.2. создание файла 3.2.2.3. удаление файла 3.2.2.4. commit и rollback как процессы 3.2.2.5. самописная система транзакций - это весело 3.3. Версионирование 3.3.1. Проблемы 3.3.1.1. Сисадмины бывают двух сортов, или проблемы бекапа 3.3.2. Решения 3.3.2.1. Раз есть транзакции - их можно использовать как точки восстановления 3.3.2.2. На самом деле, транзакции ни при чем. Просто мы храним несколько версий файла с одним именем. 3.4. WEB-ориентированность 3.4.1. Прямой доступ по полному пути 3.4.2. Иерархические файловые системы не нужны 3.5. Файловость 3.5.1. FUSE как интерфейс 3.5.2. Совмещение абстракций “транзакция” и “точка восстановления” с абстракцией “файл” 3.5.3. На самом деле - файловая система не нужна 3.6. Под капотом 3.6.1. Проблема больших файлов 3.6.1.1. Chunks 3.6.1.2. Bunches 3.6.2. Кое что задаром 3.6.2.1. Дедупликация 3.6.2.2. Сжатие на лету 3.6.2.3. Экономия канала 3.6.3. Двухфазное удаление 3.6.3.1. удаление как таковое не нужно 3.6.4. Transaction keeper как единая точка отказа 4. Коротко об опыте эксплуатации 5. Где взять 5.1. https://github.com/Djarvur/djarvurfs.git

Views

Total views

350

On Slideshare

0

From embeds

0

Number of embeds

3

Actions

Downloads

3

Shares

0

Comments

0

Likes

0

×