Комментарии 43
Спасибо, ушел делать свой tumblr, facebook или imgur!
нормуль, пригодиться. Спасибо
Спасибо, пацаны! Кому интересно как устроена система — youtu.be/7bCK_8UoWNA?t=19m37s
Есть опен-сорс реализация по мотивам FB Haystack — github.com/reverbrain/eblob/. Это низкоуровневая часть. А собственно хранилище — github.com/reverbrain/elliptics/. Храним всякое разное, начиная от картинок и заканчивая видео. Правда у нас кластерки побольше слегка, тот, что с картиночками — около 20 000 000 000 картинок :)
Всё опенсорс, и есть даже несколько инсталляций за пределами нашей компании. undev, например, у себя пробует. Есть множество плюшек кроме непосредственно хранения.
Всё опенсорс, и есть даже несколько инсталляций за пределами нашей компании. undev, например, у себя пробует. Есть множество плюшек кроме непосредственно хранения.
Это тот elliptics, что использует Яндекс?
Смотрели в эту сторону уже после перевода части инфраструктуры на backpack, но как-то не срослось. В elliptics много того, что нам не надо, а видео не вдохновили достаточно, чтобы попробовать его внедрить вместо backpack именно для хранения фотографий.
Ну а количество картинок в хранилище — вопрос времени :)
Ну а количество картинок в хранилище — вопрос времени :)
Как показывает наша практика, каждый раз, когда количество картинок значительно вырастает (тысяча, миллион, миллиард) — появляются проблемы, о которых раньше даже не предполагали. Если вдруг надумаете попробовать ещё раз — пишите. Если не секрет — почему именно для хранения фотографий не вдохновились?
Кстати, а вы про какие видео говорите? Выступление Жени на yac'2010?
Кстати, а вы про какие видео говорите? Выступление Жени на yac'2010?
Видео вроде то. Не вдохновились, потому что плюсов очевидных именно для простого хранения фотографий не было. Фотографиям просто много не надо: положить, прочитать, желательно с минимальными нагрузками на железо. Не думайте, что я только старое видео смотрел по elliptics, я даже был подписан на гитхабе на него, думал, что мнение изменится :)
Посмотрел ваши слайды. У нас есть одна штука и на тему ресайзера, и ещё пара дополнений для nginx кеша.
Из очевидных плюсов elliptics для хранения — просто сохраняешь и всё, не надо даже думать о том, что происходит под капотом: восстановления там всякие, миграция данных между серверами и прочее. Вам пришлось всё же всё это написать в backpack. У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности». Для загрузки процессоров серверов хранилищ — возможность загружать программки типа «пробежаться по фоткам и найти лица этим новым алгоритмом».
Вы же в Питере, да? Будете в мск — заходите, расскажем про космические технологии :)
Из очевидных плюсов elliptics для хранения — просто сохраняешь и всё, не надо даже думать о том, что происходит под капотом: восстановления там всякие, миграция данных между серверами и прочее. Вам пришлось всё же всё это написать в backpack. У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности». Для загрузки процессоров серверов хранилищ — возможность загружать программки типа «пробежаться по фоткам и найти лица этим новым алгоритмом».
Вы же в Питере, да? Будете в мск — заходите, расскажем про космические технологии :)
Ничего из перечисленного не тянет на космические технологии, если честно :) Запускать задачи можно и вне хранилища, что куда удобнее, имея окружения для процессинга, которое можно растянуть по cpu гораздо дальше, чем себе могут позволить сервера с данными.
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
> У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности»
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
> У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности»
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
Ничего из перечисленного не тянет на космические технологии, если честно :) Запускать задачи можно и вне хранилища, что куда удобнее, имея окружения для процессинга, которое можно растянуть по cpu гораздо дальше, чем себе могут позволить сервера с данными.
А у нас как раз есть опенсорсный app engine, я его для ресайзера предлагал как «одну штуку». Но некоторые задачи удобнее запускать на той же машине, где и данные лежат, это тупо быстрее из-за отсутствия сети между приложением и данными. Хорошо, когда есть выбор, правда? Кстати, приложения node.js мы в нашем app engine уже умеем запускать :)
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
И я вас прекрасно понимаю! Сейчас у нас есть вариант, когда при добавлении машин мы не перетаскиваем данные. Есть с этим некоторые неудобства, но тут у вас, на сколько я понимаю, похожая фигня: вы же запоминаете где-то, в какой шард положили фоточку? Кстати, 20млрд мы храним всё таки в старом варианте с DHT, на тех объёмах технология со скрипом, но работает.
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
Задача мониторинга — задетектить поломавшийся диск. Но мы хотим в этом месте проинтегрироваться с ним, чтобы автоматически восстанавливать всё сразу, как только сотрудники ДЦ заменили диск на новый. А если новый нельзя поставить — то восстановиться на какую нибудь другу машину.
Но некоторые задачи удобнее запускать на той же машине, где и данные лежат, это тупо быстрее из-за отсутствия сети между приложением и данными.
Тут не поспоришь. Только данные нужно линейно читать. В общем случае при ресайзе сетевые задержки гигабитного канала даже близко не сравнимы с disk read + resize.
вы же запоминаете где-то, в какой шард положили фоточку?
Да, у фотки есть имя и шард. Так куда проще, чем с DHT :)
восстанавливать всё сразу, как только сотрудники ДЦ заменили диск на новый
Это хорошо и удобно, но ведь создать таск в app engine «взять данные с одного инстанса и добавить в очередь на репликацию на второй» тоже можно. Автоматизации это потдаётся, хотя и с несколько большими усилиями.
Тут не поспоришь. Только данные нужно линейно читать. В общем случае при ресайзе сетевые задержки гигабитного канала даже близко не сравнимы с disk read + resize.
Конечно с линейным чтением, без него весь смысл теряется. Про сеть я несколько другое имел в виду, с одного диска можно снять порядка 50 мегабайт линейного чтения. 2 диска, в итоге, забивают гигабитную сеть. У нас обычно стоят полки на 24 диска, я своими глазами видел 700 мегабайт в секунду в dstat. Сами понимаете, в сеть такое не запихнёшь. А надо же ещё данные отдавать.
speakerdeck.com/bobrik/node-dot-js-for-millions-of-images на 10 слайде моего первого рассказа про backpack есть упоминание elliptics как варианта для хранения, правда без конкретики.
Тоже смотрим на elliptics, возникло несколько вопросов:
1. Есть ли административный интерфейс к клсастеру elliptics, если да, то что он позволяет делать?
2. Можно ли управлять шириной канала для merge?
3. Как можно управлять размером кэша для блобов (cache_size, blob_cache_size) и как мониторить статистику использования кэша?
4. Можно ли использовать несколько дисков для хранения блобов?
5. Имеет ли смысл запрещать кэширование в случае случайных запросов на чтение, когда данные не помещаются целиком в памяти?
6. Чем лучше мерять производительность elliptics?
1. Есть ли административный интерфейс к клсастеру elliptics, если да, то что он позволяет делать?
2. Можно ли управлять шириной канала для merge?
3. Как можно управлять размером кэша для блобов (cache_size, blob_cache_size) и как мониторить статистику использования кэша?
4. Можно ли использовать несколько дисков для хранения блобов?
5. Имеет ли смысл запрещать кэширование в случае случайных запросов на чтение, когда данные не помещаются целиком в памяти?
6. Чем лучше мерять производительность elliptics?
1. Пока нету. Есть консольные утилиты.
2. Можно запускать merge на отдельном интерфейсе, есть возможность тегировать траффик.
3. Там несколько разных сущностей. blob_cache_size — это кеш ключей, cache_size — это кэш, куда попадают записи, у которых при записи указан флажок специальный. То есть клиентское приложение (http прокси, например) может решать, что кешировать, а что — нет. А так блоб всегда сильно больше оперативки, оптимизирован под линейные чтения, и pagecache работает более-менее неплохо.
4. Можно запускать несколько инстансов эллиптикса на машине, по одному инстансу на каждый диск. Использовать RAID чаще всего нет смысла.
5. Как я написал в 3, кешированием может управлять клиент. pagecache операционной системы тоже писали умные люди. Ну и объём дисков обычно на 2 порядка превышает объём памяти. Если памяти больше, чем данных, то pagecache вообще всё отлично разрулит.
6. Мы яндекс.танком меряем, либо напрямую, либо через HTTP-прокси. Если вы делаете на каждый запрос клиента много обращений к хранилищу — то лучше стрелять в ту штуку, которая реализует логику работы с хранилищем.
Если вы в Москве — то мы готовы встретиться и голосом рассказать и дать какие нибудь ценные советы, как вам лучше реализовать логику.
2. Можно запускать merge на отдельном интерфейсе, есть возможность тегировать траффик.
3. Там несколько разных сущностей. blob_cache_size — это кеш ключей, cache_size — это кэш, куда попадают записи, у которых при записи указан флажок специальный. То есть клиентское приложение (http прокси, например) может решать, что кешировать, а что — нет. А так блоб всегда сильно больше оперативки, оптимизирован под линейные чтения, и pagecache работает более-менее неплохо.
4. Можно запускать несколько инстансов эллиптикса на машине, по одному инстансу на каждый диск. Использовать RAID чаще всего нет смысла.
5. Как я написал в 3, кешированием может управлять клиент. pagecache операционной системы тоже писали умные люди. Ну и объём дисков обычно на 2 порядка превышает объём памяти. Если памяти больше, чем данных, то pagecache вообще всё отлично разрулит.
6. Мы яндекс.танком меряем, либо напрямую, либо через HTTP-прокси. Если вы делаете на каждый запрос клиента много обращений к хранилищу — то лучше стрелять в ту штуку, которая реализует логику работы с хранилищем.
Если вы в Москве — то мы готовы встретиться и голосом рассказать и дать какие нибудь ценные советы, как вам лучше реализовать логику.
Первый тег лишний: я читаю!
Прочитал как Хранилище фотографий Trollface
Почему backpack настолько быстрее? Дескрипторы файлов в каталогах Linux не умеет читать целиком? Жаль в Linux нет возможность задать определённые папки для преварительного кэширования (метаданных или содержания) и указать «держать их всегда в памяти».
В nginx можно кэшировать открытые дескрипторы. Linux и так будет всегда держать горячие данные в кэше, если памяти достаточно.
Проблема в том, что несколько десятков миллионов дескрипторов держать очень накладно. Вся соль в том, что файл читается однажды и попадает в кеш на другом уровне, снова его читать будут уже только тогда, когда он выпадет из кеша.
Имея 20 миллионов файлов и 10 миллионов открытых дескрипторов мы будем большинство времени промазывать мимо кеша. Опять же, файлов на сервер влазит куда больше, чем 20 миллионов.
Имея 20 миллионов файлов и 10 миллионов открытых дескрипторов мы будем большинство времени промазывать мимо кеша. Опять же, файлов на сервер влазит куда больше, чем 20 миллионов.
Но при этом вы лишены таких механизмов ядра, как sendfile. На том же графике видно, что на горячих данных nginx выдает ~100rps, а ваше решение ~120rps, при том, что насколько я понимаю, никакого глубокого тюнинга ОС не проводилось. Сравнивать же непрогретый кэш, с прогретым — просто некорректно.
Как прогреть кеш на 6 терабайт? :)
Вопрос звучит, а как поместить кэш 6 терабайт в память? Видимо ответ будет такой же. И backpack этого тоже не сделает, и c nginx всё упрется в насколько плохо/хорошо работает фс и ядро, и то, и другое нуждается на таких задачах в глубоком тюнинге.
Склеивая файлы в один, и сохраняя значения отступа и метаинформацию, вы фактически переизобрели в юзерспейсе файловую систему.
Склеивая файлы в один, и сохраняя значения отступа и метаинформацию, вы фактически переизобрели в юзерспейсе файловую систему.
Эхх, видимо я один завис на картинке с мыслью «при чем здесь Гусман»?)
Вы мне лучше скажите, чего это в вашем топфейсе любое действие платное? После первой недели пользования вообще ничего не работает. Это шутка такая?
Промазал
Верно, что со временем (без перебалансировки) все старые фотографии будут недоступны? Если да, то интересно, почему вы решили, что она не нужна.
Почему вдруг фотографии станут недоступны? Запись на инстансы прекратится, а чтения будут идти как и прежде.
Мы давно записали фотографию и затем только читаем. В системе периодически вылетают диски — мы их заменяем новыми, но перебалансировки не происходит. Со временем все диски будут заменены, а так как перебалансировки не было — наша фотография хранилась только на старых дисках, следовательно, мы её потеряем.
Я что-то не так понял?
Я что-то не так понял?
Перебалансировка — это когда фотография попадает на другой шард, в терминологии backpack. После замены диска надо запускать восстановление, а не перебалансировку, на другой шард фотография при этом естественно не переместится.
Перебалансировка может возникать при добавлении новых дисков в шард, когда увеличивается его ёмкость. Но в Topface решили не увеличивать шарды, и на то есть причины.
Перебалансировка может возникать при добавлении новых дисков в шард, когда увеличивается его ёмкость. Но в Topface решили не увеличивать шарды, и на то есть причины.
А если использовать вместо backpack на node, openresty (nginx+lua), nginx как вебсервер а Lua для чтения файлов и метаданных из redis?
openresty.org/
openresty.org/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хранилище фотографий Topface теперь open source