ну не совсем ясно зачем тут content addressable storage. Все картинки у нас адресуются в хранилище однозначно по цифровому ИД. К тому же сомнительно что кто то из CAS сможет работать с такой скоростью — просто из-за более сложного и ненужного для данной задачи алгоритма.
Или вы предлагаете вместо blob storage использовать какой то CAS solution?

Ну а если хочется заниматься крутыми штуками — используйте e-mail job@odnoklassniki.ru по назначению ;-)

нет. Это 3000 мегабит. когда мегабайты обычно пишут MB/s ( B — большое)

2. Да, мы сейчас вообще в эту сторону двигаемся с максимально возможной скоростью. При таком количестве серверов выбора среди трех букв уже нет.

Про шарданг отвечу сначала. Все пространство ключей делится на 256 частей (берется младший байт ИД). Это число у нас называется «доменом». В системе кешей при конфигурации кластера описываются партиции интервалами доменов. Типа 0-15 => G1, 16-31 => G2 итп. Каждую партицию могут обслуживать несколько серверов, это тоже указывается в конфиге кластера. Все сервера в пределах 1 партиции являются полными репликами друг друга.

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

Если же необходимо разбить одну из партиций на 2, то делается в общем то же самое, только переконфигурация кластера посложнее будет.

Да, хотим. Но пока боимся той доп. работы что повлечет это за собой. Но постпенно, надеюсь, будем, начнем правда с инфраструктурных библиотек — конф, статистика, ремотинг — которые сами по себе довольно интересны и без которых остальное не работает.

Не планируете реализовать декомпрессор на cuda? Если даже он может декомпрессить только то, что FVJPEG сжал — уже будет очень полезно, так как это позволит съэкономить кучу времени на пересылке сырых картинок в видео карточку и задача пережатия или процессинга готовых картинок на лету становится уже реальной.

Поняли в общем правильно все.
Ответы ниже по пунктам:
1. Нет, соединения между самими серверами не поддерживаются.
2. Если апдейт с клиента не прошел по какой то причине — то измененные данные все равно попадут в кеш чуть позже через процесс синхронизации с Бд ( на картинке обозначен как synchronization). так что в итоге расхождение будет длиться не более 2 секунд
3. Когда нода стартует, она загружает данные из локального снапшота на диске. Затем запускается процесс синхронизации в БД, который подтягивает все изменения, прошедшие за время пока нода не работала. Ну а потом она собсно входит в кластер и клиенты начинают с ней работать.
4. Да, запросы рутит клиентская либа. Если запрос простой — по ид — то она, зная топологию кластера, определяет шард на основе ИД запрошенной записи и вызывает одну из реплик, по принципу взвешенного RR. Если же запрос не имеет определенного ид — то используется MapReduce — параллельно вызываются несколько шард, согласно маппера и потом результат сливается редюсером на клиенте. Фильтрация происходит на стороне инстанса кеша — на клиента приходят уже отфильтрованные данные. Индекс внутри инстанса кеша может использоваться, если это необходимо.

это не совсем удобно — в 8 раз больше соединений, усложняется конфигурация и администрирование. плюс 2 jvm на одном боксе работают хуже чем одна, но под двойной нагрузкой.

поскольку выигрыша по скорости не было — то и не разбирались с этим.

падает чаще.

Ну просто так мы ничего стараемся не делать. При первоначальной разработке этого решения мы рассматривали несколько вариантов, в том числе и мемкеш. Задачи поддержания консистентности на нем сильно усложняются, так как он не ведает, что хранит; повышенный трафик, так как приходится гонять бинарные массивы от него к клиентам и назад; необходимость разработки нового фейловер кластера; отсутствие сохранения данных между рестартами и, как следствие, проблема холодного старта — вот несколько причин, по которым он не подошел.

Да, неар кеши тоже есть, естественно. Профили пользователей, например, кешируются в том числе и не серверах приложений на короткий промежуток времени. Эти уже на хипе работают, так как объекты короткоживущие.

ключи в кеше — это Ид записей в БД. Поэтому напрямую использовать адрес в памяти не получится. Кроме того этот адрес может измениться после например реаллокации памяти или рестарта кеша. Поэтому приходится иметь в памяти соответствние ИД -> адрес записи в памяти.

Про сериализацию — да, есть дерево компонентов, которые для класса описывают его сериализацию в память. Они в конечном итоге и занимаются пут по адресу с офсетом.

да, у нас тоже есть сервера под CMS и 10-16 Г хипа, но тут больше зависит от количества объектов, а не от размера хипа. После некоторого предела ситуация начинает резко ухудшаться. В кешах бизнес объектов этот предел достигается быстро.

Да и по опыту могу сказать, что написать такое хранилище у меня недавно заняло с отладкой 2-3 дня. Настройка CMS под задачу тоже по времени сравнимо с этим. Но в итоге решение с Unsafe работает стабильнее и меньше подвержена внезапным поломкам в процессе эксплуатации.

и шо вы такой нервный ж-)? креш был на сегфолт. на самом деле, скорее всего это зависит от паттерна нагрузки и потребления памяти. наверно у вас паттерн удачный для G1, на багу не напоролись у нас — чуть другой — напоролись.

аватарки — не совсем статика, они все таки меняются. хранятся они в хранилище, на дисках. раздаточные сервера их кешируют в памяти.

раздаются тем же томкатом, разницы никакой нет чем раздавать на самом деле — все равно упираются они в сетевой интерфейс.

пробовали. с включенным G1 jvm работает до креша где то 5 минут. пока решили экспериментов не продолжать и подождать более стабильной версии.

как мне известно, Азул — это не надстройка, а наоборот, полностью своя JVM с менеджментом памяти и GC собственной разработки.
а патчили они кернел линукса чтобы позволить jvm более близко работать с железом для реализации read & write barriers, которые он и использует для организации доступа к перемещенным при компактировании хипа областям памяти

ну я могу только про jrockit сказать, что когда мы его пробовали — никаких изменений по сравнению с sum jvm в пределах статистической погрешности не было. но была менее стабильная работа самой jvm, поэтому решили более с jrockit не продолжать.

azul — не пробовали вообще после того, как узнали цену

не совсем понял какие циферки вы имеете в виду?

да смотрели. из memory data grid это по моему мнению самый лучший продукт. к сожалению цена его также для наших размеров довольно высока, так как количество серверов изменяется сотнями. в нашем случае экономически эффективнее разработка собственного решения.

вне кучи хранятся модельки с данными и коллекциями, аватарки и маленькие фотки, списки дружб итп. бизнес объекты. связанные объекты хранятся в зависимости от необходимости. Если это master-detail, то тут же рядом с объеком и хранится, если association — то присто ид сущности и за сущностью или отдельный запрос делается или из кеша достается одним запросом. зависит от необходимости.

по второму вопросу — нет, это значительно больше кода и багов. сейчас память просто выделяется маллоком — что может быть проще.

> выглядит как троллинг :)
нет, просто есть еще 1 способ, но мы о нем никому не расскажем ж-)

надо было писать печатными буквами, разборчиво. ж-)