Проблема в том, что несколько десятков миллионов дескрипторов держать очень накладно. Вся соль в том, что файл читается однажды и попадает в кеш на другом уровне, снова его читать будут уже только тогда, когда он выпадет из кеша.
Имея 20 миллионов файлов и 10 миллионов открытых дескрипторов мы будем большинство времени промазывать мимо кеша. Опять же, файлов на сервер влазит куда больше, чем 20 миллионов.
Но некоторые задачи удобнее запускать на той же машине, где и данные лежат, это тупо быстрее из-за отсутствия сети между приложением и данными.
Тут не поспоришь. Только данные нужно линейно читать. В общем случае при ресайзе сетевые задержки гигабитного канала даже близко не сравнимы с disk read + resize.
вы же запоминаете где-то, в какой шард положили фоточку?
Да, у фотки есть имя и шард. Так куда проще, чем с DHT :)
восстанавливать всё сразу, как только сотрудники ДЦ заменили диск на новый
Это хорошо и удобно, но ведь создать таск в app engine «взять данные с одного инстанса и добавить в очередь на репликацию на второй» тоже можно. Автоматизации это потдаётся, хотя и с несколько большими усилиями.
Ничего из перечисленного не тянет на космические технологии, если честно :) Запускать задачи можно и вне хранилища, что куда удобнее, имея окружения для процессинга, которое можно растянуть по cpu гораздо дальше, чем себе могут позволить сервера с данными.
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
> У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности»
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
Видео вроде то. Не вдохновились, потому что плюсов очевидных именно для простого хранения фотографий не было. Фотографиям просто много не надо: положить, прочитать, желательно с минимальными нагрузками на железо. Не думайте, что я только старое видео смотрел по elliptics, я даже был подписан на гитхабе на него, думал, что мнение изменится :)
Смотрели в эту сторону уже после перевода части инфраструктуры на backpack, но как-то не срослось. В elliptics много того, что нам не надо, а видео не вдохновили достаточно, чтобы попробовать его внедрить вместо backpack именно для хранения фотографий.
Ну а количество картинок в хранилище — вопрос времени :)
Ребята, у нас в логах ваш браузер не вставляет в конце урлов "/" иногда, это так и задумано? Сам поймать не смог, но если путь /blah/123/, то в логах есть /blah/123 только от яндекс-браузера. Мы одни такие?
При этом у клиента будут заметные тормоза, потому как cloudflare не за нулевое время проксирует каждый запрос. Если сайт в Питере, клиент в Питере, то схема с Питер -> Питер меняется на Питер -> Лондон -> Питер.
Как бы выгода не так уж очевидна :)
Ну и да, «Бинарный протокол, написанный на языке программирования Google Go» — не думал, что протоколы к языкам прибивают гвоздями.
Какой-то костыль, простите. В таком варианте consistency весьма и весьма eventual.
Вообще можно (нужно) держать несколько серверов memcached на разных физических машинах и тогда потеря одного сервера не должна портить погоду. Иначе «сервис не сможет выдержать нагрузку» по-умолчанию.
Имея 20 миллионов файлов и 10 миллионов открытых дескрипторов мы будем большинство времени промазывать мимо кеша. Опять же, файлов на сервер влазит куда больше, чем 20 миллионов.
Тут не поспоришь. Только данные нужно линейно читать. В общем случае при ресайзе сетевые задержки гигабитного канала даже близко не сравнимы с disk read + resize.
Да, у фотки есть имя и шард. Так куда проще, чем с DHT :)
Это хорошо и удобно, но ведь создать таск в app engine «взять данные с одного инстанса и добавить в очередь на репликацию на второй» тоже можно. Автоматизации это потдаётся, хотя и с несколько большими усилиями.
При добавлении новых серверов elliptics на них перетащит часть данных, так ведь? Вот это нам как раз не сильно нужно в append-only хранилище.
> У нас в планах штука, которая совсем сама всё делает, и только высылает письма «замените винт в сервере ААА, на полке подсвечен лампочкой неисправности»
Это задача мониторинга, а не системы хранения. У вас же вроде кластер заббикса для таких дел был.
Ну а количество картинок в хранилище — вопрос времени :)
client -(http)> server
С рейлганом будет ходить:
client -(http)> cloudflare -(railgun)> server
При этом у клиента будут заметные тормоза, потому как cloudflare не за нулевое время проксирует каждый запрос. Если сайт в Питере, клиент в Питере, то схема с Питер -> Питер меняется на Питер -> Лондон -> Питер.
Как бы выгода не так уж очевидна :)
Ну и да, «Бинарный протокол, написанный на языке программирования Google Go» — не думал, что протоколы к языкам прибивают гвоздями.
Вообще можно (нужно) держать несколько серверов memcached на разных физических машинах и тогда потеря одного сервера не должна портить погоду. Иначе «сервис не сможет выдержать нагрузку» по-умолчанию.
У вас такой же callback hell, если вы в него верите, исключения передаются в коллбеки.
И да, асинхронные функции не должны выбрасывать исключений.
Если есть вероятность поймать исключения, то она должна быть локализована. Типа
function parseJSON(json, callback) { try { callaback(null, JSON.parse(json)) } catch (e) { callback(e) } }И не будет никаких проблем. Разве что вы забудете повесть обработчики ошибок.
А почему он должен?