Распределенная файловая система GFS (Google File System)

[mitnlag]

Отлично. Вторая часть — реализация на практике кластера. Будет?

[Pr0grammer]

Что имеется в виду? Бенчмарки в той же статье, или же какая-то другая статья?

Вообще хотелось бы развить тему, как руки дойдут

[mitnlag]

Что может иметься ввиду?

Я хочу вторую часть: «Мы разобрали это в теории, давайте посмотрим на практике».
Я хочу эту вторую часть, как мануал к действию, для имплемента GoogleFS, если это возможно.

[stolen]

Насколько мне известно (поправьте, если неправ), GoogleFS (не путать с GFS от RedHat) не является доступной для простого смертного. Ближайшая по идеологии OpenSource-альтернатива — Hadoop.

[svpcom]

Вообще есть почти в точности сделанная по этому документу — cloudstore (kosmosfs.sourceforge.net), но оно еще довольно сыровато.

[proc]

Нифига не понял, но жуть как интересно. Спасибо

[Pr0grammer]

Попробуйте прочитать исходную статью, возможно их английский лучше, чем мой русский.
Также можно почитать аналогичные статьи про hadoop, например www.insight-it.ru/net/scalability/hadoop/

[kudzu]

Да нет, он действительно ниче не понял.

[ivanrt]

Тогда сначала сравните для начала FAT32 и sqlite.

[kelevra]

вообще-то у оракла есть своя распределённая файловая система. ваш КО.

[ivanrt]

Сравнение распределенных файловых систем Google и Oracle. В такой постановке вопрос имеет некоторый смысл. Впрочем, сфера задач и требований к этим FS сильно отличается и сравнивать их безполезно. GFS заточена под линейное чтение и запись ведется только в конец файла. oss.oracle.com/projects/ocfs2/ — семантика POSIX, журналирование (в том числе запись в середину). Для хранения и доступа к файлам скорее всего удобней OCFS2, для запуска mapreduce (en.wikipedia.org/wiki/MapReduce) возможно GFS. Есть еще такие критерии как устойчивость к падению серверов, скорость чтения данных с учетом выхода из строя оборудования, масштабируемость (тоже по разному можно определять), и тп. Сравнивайте! :)

[mrskam]

Хороший перевод. Если будет время и желание, переведите статейки по MapReduce и Bigtable из labs, многим думаю будет интересно узнать и про эти «столпы» гугли.

Кто хочет почитать про эволюцию gfs — есть довольно свежая статья от инженера гугли: GFS: Evolution on Fast-forward (англ.)

[Pr0grammer]

Про MapReduce и Bigtable — в точку. Постараюсь найти свободное время.

[Arvik]

Интересная статья.

Но вот GFS сам по себе это довольно простецкое решение задачи «как хранить кучу данных на куче железа». Ни одной оригинальной идеи в себе не несёт и выглядит лишь слегка сложнее FATа 70х годов.

[sgzmd]

Рекомендую почитать также статьи про Hadoop и HDFS — она постоянно развивается и не в пример более открытая по сравнению с GFS.

[ramovsky]

Все таки самая известная — NFS

[angry_elf]

Давно она стала распределённой?

[romx]

Всегда была распределенной для клиента, и начиная с NFSv4.1 она распределенная для сервера.

[tony]

смутное чувство, что где-то я это читал… или что-то очень-очень похожее.

[Khoss]

GFS — отличная основа для разработок будущего ИИ… Такими темпами Гугл создаст искусственный интеллект. Рано или поздно.

[Khoss]

интересно, за что минусы?

[krasin]

Как то, что вы сказали, приближает Гугл или еще кого-нибудь к ИИ?

[Khoss]

Разве подобная файловая система не является возможно, крупнейшим, и стабильнейшим хранилищем для информации на планете? А вкупе с кластерами для облачных вычислений типа GoogleApps, в которые вваливается столько денег и прочих ресурсов, что они могут заменить по вычислительной мощи все крупнейшие мейнфреймы военных, НАСА и прочих организаций? Разве это ли не есть «белковый бульон» для того, что бы в нем можно было ставить эксперименты по созданию, возможно, крупнейших «цифровых нейронных сетей»? А системы распознавания голоса, изображений и даже видео разве не требуют крупных хранилищ информации, доступ к которой уже «интеллектуально» организуется на предмет приоритетов и защиты от повреждений?

[mrskam]

Текущая реализация gfs недопустимо медленна для реализаций хранилища для ИИ. В спецификации GFS прямо написано, что время отклика на запрос менее важно, чем обеспечение высокой пропускной способности. Вот когда перепишут (уже переписывают), посмотрим на отклик. Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)

Облачных вычислений типа GoogleApps — вы разумется, имели ввиду AppEngine, не путайте. В нее кстати немного денег вложено, там реально небольшая команда разработчиков. Да и софт полностью использует существующую архитектуру. AppEngine для ИИ не подойдет, он общается с тем же кешом (ну или с любым сервисом) через rpc, а он реально медленный и последовательный. Это все заточено для нестабильного веба, а никак для реалтаймовой системы с очень быстрым временм отклика.

Для ИИ теоретически может подойти RTMFP в fp10*, коль уж флеша стоит на сотнях миллинов миллиардах машин. Нейрон как раз хорошо вписывается в этот p2p протокол.

[Khoss]

Теперь я понял почему flash тормозит везде ;)

Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)

Я имел ввиду, если ИИ и понадобится постоянная память (ROM) — то медленная но стабильная, защищенная от падений каналов, от потери данных GoogleFS (возможно в переписанном виде) как раз подойдет. Я не имел ввиду RAM.

[mrskam]

Таких ИИ природа инженеры не видывали :) Посмотрите на активность мозга, там все видно. Для современных мне известных моделей нужна реатайм система. Она же и рам, и ром, и все вместе.

[o_O_Tync]

Я правильно понимаю, что «proprietary distributed file system developed by Google Inc. for its own use» (en.wiki) значит что GFS не доступна для использования вне компании Google?

[Khoss]

Она, как я понимаю, используется для всех служб гугла самим гуглом. Следовательно косвенно и теми, кто пользуется службами гугла

[Pr0grammer]

Да, но есть альтернатива — Hadoop, который, как я понимаю изначально строился по подобию GFS.

[Pr0grammer]

Под Hadoop я имел в виду HDFS

[o_O_Tync]

Java =\ не верю я в её «производительность» :)

[gudok]

GFS и HDFS предназначены для обработки больших объемов данных. Настолько больших, что узкое горлышко — дисковые операции. А на них язык реализации ФС слабо влияет.

[mrskam]

Не, узкое место в них — сетевые операции. Поэтому чтобы проц не простаивал в ожидании, все данные сжимаются, «создавая» балланс использования ресурсов.

[gudok]

Это смотря что делать. Если поверх DFS использовать MapReduce, то 90% операций локализуются за счет локальности самих задач и высокого коэффициента репликации. Сеть нагружается только во время пересылок map->reduce. Во всё остальное время боттлнек — диски (особенно во время сортировки). Репликаця же работает в бэкграунде и не мешает.

Данные сжимают, чтобы сбалансировать проц как с сетью, так и с дисками.

[mrskam]

Ясно, спасибо. Часом не в гугле работаете? А то хорошие познания механизмов работы.

[gudok]

Место работы можно узнать из профиля. :)

[mrskam]

Что-то там мало написано :) я так и не понял, ну да ладно.

А тогда может вы знаете, что реально хранится в gfs (понятно, что данные)? Я так понял, что все общение с gfs идет через как минимум через bigtable, и тогда получается что единственное назначение gfs — обслуживать bigtable (ибо даже логи хрянятся вроде через bigtable). Не в курсе, так это?

[gudok]

Самому интересно.

Есть подозрение, что все данные, обрабатываемые в бэкграунде, действительно хранятся в bigtable. Реляционно-подобная организация избавляет от написания отдельной программы для конкретной задачи (скажем, «SELECT * FROM...»). Но для realtime задач он вряд ли подходит по времени отклика. То есть для задач поиска всё-таки используется не bigtable, и не GFS.
Также есть подозрение, что данные извлекаются непосредственно из bigtable при клике на ссылку «закэшированный запрос» (долго работает).

Работаю в nigma.ru.

[mrskam]

У меня было подозрение на нигму :) спасибо.

Вообще скорость извлечения 1 записи из megastore (надстройка над bigtable, отвечающая за индексы, схемы, транзакции и пр.) — около 30-50мс. Это причем через rpc. Причем для всей AppEngine используется всего 4 «стола» на всех. Так что почему кеш долго извлекается — непонятно, видимо где-то далеко лежит или хитро извлекается через 10 запросов, ибо нечастая операция. Но вообще я слышал, что весь поиск полностью под bigtable сидит, ибо легко и быстро при этом сменить весь индекс (например откатить по таймстампу).

[googol]

4 самых главных пользователя gfs это (насколько я помню):
1) BigTable как основное хранилище данных в гугле
2) логи. Огромное количество логов со всех проектов. Gmail по моему год хранит логи на все действия пользователей.
3) Транзакционные данные для map-reduce. Когда 1 машина заканчивает свою часть вычеслений — она выкладывает данные в gfs. Другая машина эти данные использует как inut.
4) Gmail — почта пользователей. Насколько я знаю gmail #1 в потреблении дискового пространства среди google проектов.

[mrskam]

Ясно, спасибо огромное.
Только на счет 2 и 4 я думал, что это уже на bigtable переведено, особенно 4, это же удобнее, да и bigtable совсем небольшой довесок дает по скорости. Держать-то файло с километровыми названиями не айс… (datacenter_id, machine_id, service_name? time и пр.) Единственно понятно, что бигтайбл свеж (он же позже гмыла вышел в продакшн?), а те же задания обработку логов давно писались и оттачивались.

Еще так додумал, что видео от ютуба непосредственно в gfs лежит, ибо бигтайбл не умеет отдавать данные с произвольного байта (для перемотки видео)? И также интересно, где гугл.доки лежат, на каком уровне абстракции.

[seriyPS]

<humour_tag>
Джеки ЧанК одобряет этот пост…
</humour_tag>
Пардон, не сдержался…
Довольно интересно… Т.е. ВСЕ данные гугла хранятся в GFS? А как например с images.google.com? Ведь там кучи мелких картинок хранится размером явно меньше 64 мегабайт…

[mrskam]

Так речь в 64МБ о чанке. Дальше из него побайтно читают.

Вот из свежей обзорной презентации топового инженера гугли:
How long to generate image results page (30 thumbnails)?
  Design 1: Read serially, thumbnail 256K images on the fly
    30 seeks * 10 ms/seek + 30 * 256K / 30 MB/s = 560 ms
  Design 2: Issue reads in parallel:
    10 ms/seek + 256K read / 30 MB/s = 18 ms
   (Ignores variance, so really more like 30-60 ms, probably)

[mrskam]

И не факт кстати, что на превью-картинки чанк 64MB, может и меньше, не знаю.

[mrskam]

А нет, факт, эти же картинки 100% лежат в bigtable.

«BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных»

А для чего gfs реально используется (ну кроме как для данных bigtable) — не очень понятно, видимо только для какой-то внутренней статики.

[deniamnet]

после прочтения статьи мне теперь будет сниться слово «чанк»
шутка ли, 103 раза упоминается =)

[scr1pt]

Раньше знал о существовании GFS, но все руки не доходили прочитать поподробнее и вникунуть в саму, так сказать, суть.

Автор наглядно показал могущество гугла, спасибо:)

[kossmoss]

Мне напомнило строение человеческого мозга. Тоже куча заманух, всё распределено, а как работает — понятно очень смутно. Но результат восхищает.