Файловая система Google
 | Эта статья нуждается в дополнительных ссылок для проверки . ( июль 2016 г. ) |
| Операционная система | Ядро Linux |
|---|---|
| Тип | Распределенная файловая система |
| Лицензия | Собственный |
Файловая система Google ( GFS или GoogleFS , не путать с файловой системой GFS Linux) — это собственная распределенная файловая система , разработанная Google для обеспечения эффективного и надежного доступа к данным с использованием больших кластеров стандартного оборудования . Файловая система Google была заменена Colossus в 2010 году. [1] [2]
Дизайн [ править ]
GFS усовершенствована для основных потребностей Google в хранении и использовании данных (в первую очередь для поисковой системы ), которая может генерировать огромные объемы данных, которые необходимо сохранять; Файловая система Google выросла из более ранней разработки Google, «BigFiles», разработанной Ларри Пейджем и Сергеем Брином на заре существования Google, когда она еще находилась в Стэнфорде . Файлы делятся на фрагменты фиксированного размера по 64 мегабайта , аналогичные кластерам или секторам в обычных файловых системах, которые перезаписываются или сжимаются крайне редко; файлы обычно добавляются или читаются. Он также разработан и оптимизирован для работы на вычислительных кластерах Google, плотных узлах, состоящих из дешевых «обычных» компьютеров, а это означает, что необходимо принять меры предосторожности против высокой частоты отказов отдельных узлов и последующей потери данных. Другие проектные решения ориентированы на высокую пропускную способность , даже если за это приходится платить задержкой .
Кластер GFS состоит из нескольких узлов. Эти узлы делятся на два типа: один главный узел и несколько серверов фрагментов . Каждый файл разделен на фрагменты фиксированного размера. Серверы фрагментов хранят эти фрагменты. Каждому фрагменту во время создания главный узел присваивает глобально уникальную 64-битную метку, при этом сохраняются логические сопоставления файлов с составляющими фрагментами. Каждый фрагмент реплицируется несколько раз по сети. По умолчанию он реплицируется три раза, но это можно настроить. [3] Файлы, пользующиеся большим спросом, могут иметь более высокий коэффициент репликации, в то время как файлы, для которых клиент приложения использует строгую оптимизацию хранения, могут реплицироваться менее трех раз — чтобы справиться с политиками быстрой очистки мусора. [3]
Главный сервер обычно хранит не сами фрагменты, а все метаданные, связанные с фрагментами, такие как таблицы, сопоставляющие 64-битные метки с местоположениями фрагментов и файлы, которые они составляют (сопоставление файлов с фрагментами), местоположения копий фрагментов, какие процессы читают или записывают в конкретный фрагмент или делают «снимок» фрагмента для его репликации (обычно по инициативе главного сервера, когда из-за сбоев узлов количество копий фрагмента упало ниже установленного числа). Все эти метаданные поддерживаются в актуальном состоянии главным сервером, периодически получающим обновления от каждого сервера фрагментов («сообщения Heartbeat»).
Разрешения на изменения обрабатываются системой ограниченных по времени и истекающих «аренды», где главный сервер предоставляет разрешение процессу на ограниченный период времени, в течение которого ни один другой процесс не будет получать от главного сервера разрешение на изменение фрагмента. . Модифицирующий сервер фрагментов, который всегда является основным держателем фрагментов, затем распространяет изменения на серверы фрагментов с помощью резервных копий. Изменения не сохраняются до тех пор, пока все серверы фрагментов не подтвердят их, что гарантирует завершение и атомарность операции.
Программы получают доступ к фрагментам, сначала запрашивая у главного сервера местонахождение нужных фрагментов; если чанки не используются (т.е. не существует невыполненных договоров аренды), Мастер отвечает, сообщая местоположения, а затем программа связывается и получает данные напрямую с сервера фрагментов (аналогично Kazaa и его супернодам ).
В отличие от большинства других файловых систем, GFS не реализована в ядре операционной системы , а вместо этого предоставляется в виде библиотеки пользовательского пространства . [4]
Интерфейс [ править ]
Файловая система Google не предоставляет интерфейс POSIX . [5] Файлы организованы иерархически в каталогах и идентифицируются по именам путей. Поддерживаются такие файловые операции, как создание, удаление, открытие, закрытие, чтение, запись. Он поддерживает добавление записей, которое позволяет нескольким клиентам одновременно добавлять данные в один и тот же файл, при этом гарантируется атомарность.
Производительность [ править ]
Принимая решение по результатам сравнительного анализа, [3] при использовании с относительно небольшим количеством серверов (15) файловая система достигает производительности чтения, сравнимой с производительностью одиночного диска (80–100 МБ/с), но имеет пониженную скорость записи (30 МБ/с) и относительно медленное (5 МБ/с) добавление данных в существующие файлы. Авторы не приводят результатов по времени случайного поиска. Поскольку главный узел не участвует напрямую в чтении данных (данные передаются с сервера фрагментов непосредственно клиенту чтения), скорость чтения значительно увеличивается с увеличением количества серверов фрагментов, достигая 583 МБ/с для 342 узлов. Объединение нескольких серверов также обеспечивает большую емкость, хотя она несколько снижается за счет хранения данных в трех независимых местах (для обеспечения избыточности).
См. также [ править ]
- Большой стол
- Облачное хранилище
- Облачный магазин
- Fossil — родная файловая система Plan 9.
- GPFS Общая параллельная файловая система IBM
- GFS2 Глобальная файловая система Red Hat 2
- Apache Hadoop и его «Распределенная файловая система Hadoop» (HDFS), Java-продукт с открытым исходным кодом, аналогичный GFS.
- Список продуктов Google
- Уменьшение карты
- Файловая система Moose
- ЯщерицаFS
Ссылки [ править ]
- ^ Хофф, Тодд (11 сентября 2010 г.). «Колосс Google делает поиск в реальном времени, отказавшись от MapReduce» . Высокая масштабируемость . Архивировано из оригинала 4 апреля 2019 г.
- ^ Ма, Эрик (29 ноября 2012 г.). «Колосс: преемник файловой системы Google (GFS)» . Системные учебники. Архивировано из оригинала 12 апреля 2019 г. Проверено 10 мая 2016 г.
- ^ Перейти обратно: а б с Гемават, Гобиофф и Люнг, 2003 .
- ^ Кириазис, Димосфенис (2013). Службы хранения больших объемов данных для облачных сред . IGI Global. п. 13. ISBN 9781466639355 .
- ^ Маршалл Кирк МакКьюсик; Шон Куинлан (август 2009 г.). «GFS: эволюция в ускоренном темпе» . Очередь АКМ . 7 (7): 10–20. дои : 10.1145/1594204.1594206 . Проверено 21 декабря 2019 г.
Библиография [ править ]
- Гемават, С.; Гобиофф, Х.; Люнг, ST (2003). «Файловая система Google». Материалы девятнадцатого симпозиума ACM по принципам операционных систем - SOSP '03 (PDF) . п. 29. CiteSeerX 10.1.1.125.789 . дои : 10.1145/945445.945450 . ISBN 1581137575 . S2CID 221261373 .
Внешние ссылки [ править ]
- «GFS: Эволюция в ускоренной перемотке вперед», Очередь , ACM .
- «Оценка файловой системы Google, часть I», Storage mojo .
