Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Отлично. Вторая часть — реализация на практике кластера. Будет?
Что имеется в виду? Бенчмарки в той же статье, или же какая-то другая статья?
Вообще хотелось бы развить тему, как руки дойдут
Вообще хотелось бы развить тему, как руки дойдут
Насколько мне известно (поправьте, если неправ), GoogleFS (не путать с GFS от RedHat) не является доступной для простого смертного. Ближайшая по идеологии OpenSource-альтернатива — Hadoop.
Нифига не понял, но жуть как интересно. Спасибо
Попробуйте прочитать исходную статью, возможно их английский лучше, чем мой русский.
Также можно почитать аналогичные статьи про hadoop, например www.insight-it.ru/net/scalability/hadoop/
Также можно почитать аналогичные статьи про hadoop, например www.insight-it.ru/net/scalability/hadoop/
Тогда сначала сравните для начала 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 (англ.)
Кто хочет почитать про эволюцию gfs — есть довольно свежая статья от инженера гугли: GFS: Evolution on Fast-forward (англ.)
Интересная статья.
Но вот GFS сам по себе это довольно простецкое решение задачи «как хранить кучу данных на куче железа». Ни одной оригинальной идеи в себе не несёт и выглядит лишь слегка сложнее FATа 70х годов.
Но вот GFS сам по себе это довольно простецкое решение задачи «как хранить кучу данных на куче железа». Ни одной оригинальной идеи в себе не несёт и выглядит лишь слегка сложнее FATа 70х годов.
Рекомендую почитать также статьи про Hadoop и HDFS — она постоянно развивается и не в пример более открытая по сравнению с GFS.
Все таки самая известная — NFS
смутное чувство, что где-то я это читал… или что-то очень-очень похожее.
GFS — отличная основа для разработок будущего ИИ… Такими темпами Гугл создаст искусственный интеллект. Рано или поздно.
интересно, за что минусы?
Как то, что вы сказали, приближает Гугл или еще кого-нибудь к ИИ?
Разве подобная файловая система не является возможно, крупнейшим, и стабильнейшим хранилищем для информации на планете? А вкупе с кластерами для облачных вычислений типа GoogleApps, в которые вваливается столько денег и прочих ресурсов, что они могут заменить по вычислительной мощи все крупнейшие мейнфреймы военных, НАСА и прочих организаций? Разве это ли не есть «белковый бульон» для того, что бы в нем можно было ставить эксперименты по созданию, возможно, крупнейших «цифровых нейронных сетей»? А системы распознавания голоса, изображений и даже видео разве не требуют крупных хранилищ информации, доступ к которой уже «интеллектуально» организуется на предмет приоритетов и защиты от повреждений?
Текущая реализация gfs недопустимо медленна для реализаций хранилища для ИИ. В спецификации GFS прямо написано, что время отклика на запрос менее важно, чем обеспечение высокой пропускной способности. Вот когда перепишут (уже переписывают), посмотрим на отклик. Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)
Облачных вычислений типаGoogleApps — вы разумется, имели ввиду AppEngine, не путайте. В нее кстати немного денег вложено, там реально небольшая команда разработчиков. Да и софт полностью использует существующую архитектуру. AppEngine для ИИ не подойдет, он общается с тем же кешом (ну или с любым сервисом) через rpc, а он реально медленный и последовательный. Это все заточено для нестабильного веба, а никак для реалтаймовой системы с очень быстрым временм отклика.
Для ИИ теоретически может подойти RTMFP в fp10*, коль уж флеша стоит насотнях миллинов миллиардах машин. Нейрон как раз хорошо вписывается в этот p2p протокол.
Облачных вычислений типа
Для ИИ теоретически может подойти RTMFP в fp10*, коль уж флеша стоит на
Теперь я понял почему flash тормозит везде ;)
Да и непонятно, что хранить в этом хранилище — на 1 нейрон как-то нехорошо блок на 64МБ резервировать :)Я имел ввиду, если ИИ и понадобится постоянная память (ROM) — то медленная но стабильная, защищенная от падений каналов, от потери данных GoogleFS (возможно в переписанном виде) как раз подойдет. Я не имел ввиду RAM.
Я правильно понимаю, что «proprietary distributed file system developed by Google Inc. for its own use» (en.wiki) значит что GFS не доступна для использования вне компании Google?
Она, как я понимаю, используется для всех служб гугла самим гуглом. Следовательно косвенно и теми, кто пользуется службами гугла
Да, но есть альтернатива — Hadoop, который, как я понимаю изначально строился по подобию GFS.
Под Hadoop я имел в виду HDFS
Java =\ не верю я в её «производительность» :)
GFS и HDFS предназначены для обработки больших объемов данных. Настолько больших, что узкое горлышко — дисковые операции. А на них язык реализации ФС слабо влияет.
Не, узкое место в них — сетевые операции. Поэтому чтобы проц не простаивал в ожидании, все данные сжимаются, «создавая» балланс использования ресурсов.
Это смотря что делать. Если поверх DFS использовать MapReduce, то 90% операций локализуются за счет локальности самих задач и высокого коэффициента репликации. Сеть нагружается только во время пересылок map->reduce. Во всё остальное время боттлнек — диски (особенно во время сортировки). Репликаця же работает в бэкграунде и не мешает.
Данные сжимают, чтобы сбалансировать проц как с сетью, так и с дисками.
Данные сжимают, чтобы сбалансировать проц как с сетью, так и с дисками.
Ясно, спасибо. Часом не в гугле работаете? А то хорошие познания механизмов работы.
Место работы можно узнать из профиля. :)
Что-то там мало написано :) я так и не понял, ну да ладно.
А тогда может вы знаете, что реально хранится в gfs (понятно, что данные)? Я так понял, что все общение с gfs идет через как минимум через bigtable, и тогда получается что единственное назначение gfs — обслуживать bigtable (ибо даже логи хрянятся вроде через bigtable). Не в курсе, так это?
А тогда может вы знаете, что реально хранится в gfs (понятно, что данные)? Я так понял, что все общение с gfs идет через как минимум через bigtable, и тогда получается что единственное назначение gfs — обслуживать bigtable (ибо даже логи хрянятся вроде через bigtable). Не в курсе, так это?
Самому интересно.
Есть подозрение, что все данные, обрабатываемые в бэкграунде, действительно хранятся в bigtable. Реляционно-подобная организация избавляет от написания отдельной программы для конкретной задачи (скажем, «SELECT * FROM...»). Но для realtime задач он вряд ли подходит по времени отклика. То есть для задач поиска всё-таки используется не bigtable, и не GFS.
Также есть подозрение, что данные извлекаются непосредственно из bigtable при клике на ссылку «закэшированный запрос» (долго работает).
Работаю в nigma.ru.
Есть подозрение, что все данные, обрабатываемые в бэкграунде, действительно хранятся в bigtable. Реляционно-подобная организация избавляет от написания отдельной программы для конкретной задачи (скажем, «SELECT * FROM...»). Но для realtime задач он вряд ли подходит по времени отклика. То есть для задач поиска всё-таки используется не bigtable, и не GFS.
Также есть подозрение, что данные извлекаются непосредственно из bigtable при клике на ссылку «закэшированный запрос» (долго работает).
Работаю в nigma.ru.
У меня было подозрение на нигму :) спасибо.
Вообще скорость извлечения 1 записи из megastore (надстройка над bigtable, отвечающая за индексы, схемы, транзакции и пр.) — около 30-50мс. Это причем через rpc. Причем для всей AppEngine используется всего 4 «стола» на всех. Так что почему кеш долго извлекается — непонятно, видимо где-то далеко лежит или хитро извлекается через 10 запросов, ибо нечастая операция. Но вообще я слышал, что весь поиск полностью под bigtable сидит, ибо легко и быстро при этом сменить весь индекс (например откатить по таймстампу).
Вообще скорость извлечения 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 проектов.
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 лежит, ибо бигтайбл не умеет отдавать данные с произвольного байта (для перемотки видео)? И также интересно, где гугл.доки лежат, на каком уровне абстракции.
Только на счет 2 и 4 я думал, что это уже на bigtable переведено, особенно 4, это же удобнее, да и bigtable совсем небольшой довесок дает по скорости. Держать-то файло с километровыми названиями не айс… (datacenter_id, machine_id, service_name? time и пр.) Единственно понятно, что бигтайбл свеж (он же позже гмыла вышел в продакшн?), а те же задания обработку логов давно писались и оттачивались.
Еще так додумал, что видео от ютуба непосредственно в gfs лежит, ибо бигтайбл не умеет отдавать данные с произвольного байта (для перемотки видео)? И также интересно, где гугл.доки лежат, на каком уровне абстракции.
<humour_tag>
Джеки ЧанК одобряет этот пост…
</humour_tag>
Пардон, не сдержался…
Довольно интересно… Т.е. ВСЕ данные гугла хранятся в GFS? А как например с images.google.com? Ведь там кучи мелких картинок хранится размером явно меньше 64 мегабайт…
Джеки ЧанК одобряет этот пост…
</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)
Вот из свежей обзорной презентации топового инженера гугли:
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) — не очень понятно, видимо только для какой-то внутренней статики.
«BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных»
А для чего gfs реально используется (ну кроме как для данных bigtable) — не очень понятно, видимо только для какой-то внутренней статики.
после прочтения статьи мне теперь будет сниться слово «чанк»
шутка ли, 103 раза упоминается =)
шутка ли, 103 раза упоминается =)
Раньше знал о существовании GFS, но все руки не доходили прочитать поподробнее и вникунуть в саму, так сказать, суть.
Автор наглядно показал могущество гугла, спасибо:)
Автор наглядно показал могущество гугла, спасибо:)
Мне напомнило строение человеческого мозга. Тоже куча заманух, всё распределено, а как работает — понятно очень смутно. Но результат восхищает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распределенная файловая система GFS (Google File System)