Pull to refresh

Comments 49

Отлично. Вторая часть — реализация на практике кластера. Будет?
Что имеется в виду? Бенчмарки в той же статье, или же какая-то другая статья?

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

Я хочу вторую часть: «Мы разобрали это в теории, давайте посмотрим на практике».
Я хочу эту вторую часть, как мануал к действию, для имплемента GoogleFS, если это возможно.
Насколько мне известно (поправьте, если неправ), GoogleFS (не путать с GFS от RedHat) не является доступной для простого смертного. Ближайшая по идеологии OpenSource-альтернатива — Hadoop.
Вообще есть почти в точности сделанная по этому документу — cloudstore (kosmosfs.sourceforge.net), но оно еще довольно сыровато.
Нифига не понял, но жуть как интересно. Спасибо
Попробуйте прочитать исходную статью, возможно их английский лучше, чем мой русский.
Также можно почитать аналогичные статьи про hadoop, например www.insight-it.ru/net/scalability/hadoop/
Да нет, он действительно ниче не понял.
UFO just landed and posted this here
Тогда сначала сравните для начала FAT32 и sqlite.
вообще-то у оракла есть своя распределённая файловая система. ваш КО.
Сравнение распределенных файловых систем Google и Oracle. В такой постановке вопрос имеет некоторый смысл. Впрочем, сфера задач и требований к этим FS сильно отличается и сравнивать их безполезно. GFS заточена под линейное чтение и запись ведется только в конец файла. oss.oracle.com/projects/ocfs2/ — семантика POSIX, журналирование (в том числе запись в середину). Для хранения и доступа к файлам скорее всего удобней OCFS2, для запуска mapreduce (en.wikipedia.org/wiki/MapReduce) возможно GFS. Есть еще такие критерии как устойчивость к падению серверов, скорость чтения данных с учетом выхода из строя оборудования, масштабируемость (тоже по разному можно определять), и тп. Сравнивайте! :)
Хороший перевод. Если будет время и желание, переведите статейки по MapReduce и Bigtable из labs, многим думаю будет интересно узнать и про эти «столпы» гугли.

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

Но вот GFS сам по себе это довольно простецкое решение задачи «как хранить кучу данных на куче железа». Ни одной оригинальной идеи в себе не несёт и выглядит лишь слегка сложнее FATа 70х годов.
Рекомендую почитать также статьи про Hadoop и HDFS — она постоянно развивается и не в пример более открытая по сравнению с GFS.
Давно она стала распределённой?
Всегда была распределенной для клиента, и начиная с NFSv4.1 она распределенная для сервера.
смутное чувство, что где-то я это читал… или что-то очень-очень похожее.
GFS — отличная основа для разработок будущего ИИ… Такими темпами Гугл создаст искусственный интеллект. Рано или поздно.
интересно, за что минусы?
Как то, что вы сказали, приближает Гугл или еще кого-нибудь к ИИ?
Разве подобная файловая система не является возможно, крупнейшим, и стабильнейшим хранилищем для информации на планете? А вкупе с кластерами для облачных вычислений типа GoogleApps, в которые вваливается столько денег и прочих ресурсов, что они могут заменить по вычислительной мощи все крупнейшие мейнфреймы военных, НАСА и прочих организаций? Разве это ли не есть «белковый бульон» для того, что бы в нем можно было ставить эксперименты по созданию, возможно, крупнейших «цифровых нейронных сетей»? А системы распознавания голоса, изображений и даже видео разве не требуют крупных хранилищ информации, доступ к которой уже «интеллектуально» организуется на предмет приоритетов и защиты от повреждений?
Текущая реализация gfs недопустимо медленна для реализаций хранилища для ИИ. В спецификации GFS прямо написано, что время отклика на запрос менее важно, чем обеспечение высокой пропускной способности. Вот когда перепишут (уже переписывают), посмотрим на отклик. Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)

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

Для ИИ теоретически может подойти RTMFP в fp10*, коль уж флеша стоит на сотнях миллинов миллиардах машин. Нейрон как раз хорошо вписывается в этот p2p протокол.
Теперь я понял почему flash тормозит везде ;)
Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)
Я имел ввиду, если ИИ и понадобится постоянная память (ROM) — то медленная но стабильная, защищенная от падений каналов, от потери данных GoogleFS (возможно в переписанном виде) как раз подойдет. Я не имел ввиду RAM.
Таких ИИ природа инженеры не видывали :) Посмотрите на активность мозга, там все видно. Для современных мне известных моделей нужна реатайм система. Она же и рам, и ром, и все вместе.
Я правильно понимаю, что «proprietary distributed file system developed by Google Inc. for its own use» (en.wiki) значит что GFS не доступна для использования вне компании Google?
Она, как я понимаю, используется для всех служб гугла самим гуглом. Следовательно косвенно и теми, кто пользуется службами гугла
Да, но есть альтернатива — Hadoop, который, как я понимаю изначально строился по подобию GFS.
Java =\ не верю я в её «производительность» :)
GFS и HDFS предназначены для обработки больших объемов данных. Настолько больших, что узкое горлышко — дисковые операции. А на них язык реализации ФС слабо влияет.
Не, узкое место в них — сетевые операции. Поэтому чтобы проц не простаивал в ожидании, все данные сжимаются, «создавая» балланс использования ресурсов.
Это смотря что делать. Если поверх DFS использовать MapReduce, то 90% операций локализуются за счет локальности самих задач и высокого коэффициента репликации. Сеть нагружается только во время пересылок map->reduce. Во всё остальное время боттлнек — диски (особенно во время сортировки). Репликаця же работает в бэкграунде и не мешает.

Данные сжимают, чтобы сбалансировать проц как с сетью, так и с дисками.
Ясно, спасибо. Часом не в гугле работаете? А то хорошие познания механизмов работы.
Место работы можно узнать из профиля. :)
Что-то там мало написано :) я так и не понял, ну да ладно.

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

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

Работаю в nigma.ru.
У меня было подозрение на нигму :) спасибо.

Вообще скорость извлечения 1 записи из megastore (надстройка над bigtable, отвечающая за индексы, схемы, транзакции и пр.) — около 30-50мс. Это причем через rpc. Причем для всей AppEngine используется всего 4 «стола» на всех. Так что почему кеш долго извлекается — непонятно, видимо где-то далеко лежит или хитро извлекается через 10 запросов, ибо нечастая операция. Но вообще я слышал, что весь поиск полностью под bigtable сидит, ибо легко и быстро при этом сменить весь индекс (например откатить по таймстампу).
4 самых главных пользователя gfs это (насколько я помню):
1) BigTable как основное хранилище данных в гугле
2) логи. Огромное количество логов со всех проектов. Gmail по моему год хранит логи на все действия пользователей.
3) Транзакционные данные для map-reduce. Когда 1 машина заканчивает свою часть вычеслений — она выкладывает данные в gfs. Другая машина эти данные использует как inut.
4) Gmail — почта пользователей. Насколько я знаю gmail #1 в потреблении дискового пространства среди google проектов.
Ясно, спасибо огромное.
Только на счет 2 и 4 я думал, что это уже на bigtable переведено, особенно 4, это же удобнее, да и bigtable совсем небольшой довесок дает по скорости. Держать-то файло с километровыми названиями не айс… (datacenter_id, machine_id, service_name? time и пр.) Единственно понятно, что бигтайбл свеж (он же позже гмыла вышел в продакшн?), а те же задания обработку логов давно писались и оттачивались.

Еще так додумал, что видео от ютуба непосредственно в gfs лежит, ибо бигтайбл не умеет отдавать данные с произвольного байта (для перемотки видео)? И также интересно, где гугл.доки лежат, на каком уровне абстракции.
<humour_tag>
Джеки ЧанК одобряет этот пост…
</humour_tag>
Пардон, не сдержался…
Довольно интересно… Т.е. ВСЕ данные гугла хранятся в GFS? А как например с images.google.com? Ведь там кучи мелких картинок хранится размером явно меньше 64 мегабайт…
Так речь в 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)
И не факт кстати, что на превью-картинки чанк 64MB, может и меньше, не знаю.
А нет, факт, эти же картинки 100% лежат в bigtable.

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

А для чего gfs реально используется (ну кроме как для данных bigtable) — не очень понятно, видимо только для какой-то внутренней статики.
после прочтения статьи мне теперь будет сниться слово «чанк»
шутка ли, 103 раза упоминается =)
Раньше знал о существовании GFS, но все руки не доходили прочитать поподробнее и вникунуть в саму, так сказать, суть.

Автор наглядно показал могущество гугла, спасибо:)
Мне напомнило строение человеческого мозга. Тоже куча заманух, всё распределено, а как работает — понятно очень смутно. Но результат восхищает.
Sign up to leave a comment.

Articles