Могу ли я использовать Terracotta для масштабирования приложения, интенсивно использующего оперативную память?

Я оцениваю Terracotta, чтобы помочь мне масштабировать приложение, которое в настоящее время ограничено оперативной памятью. Это совместный фильтр, который хранит около 2 килобайт данных на пользователя. Я хочу использовать Amazon EC2, что означает, что я ограничен 14 ГБ ОЗУ, что дает мне эффективную верхнюю границу около 7 миллионов пользователей на сервер. Мне нужно иметь возможность выйти за рамки этого.

Основываясь на прочитанном до сих пор, я понял, что Terracotta может иметь кластеризованную кучу, превышающую доступную оперативную память на каждом сервере. Было бы целесообразно иметь эффективную кластеризованную кучу объемом 30 ГБ или более, где каждый из серверов поддерживает только 14 ГБ?

Данные для каждого пользователя (большую часть которых составляют массивы с плавающей запятой) изменяются очень часто, потенциально сотни тысяч раз в минуту. Нет необходимости синхронизировать каждое из этих изменений с другими узлами кластера в момент их возникновения. Можно ли периодически синхронизировать только некоторые поля объекта?


java amazon-ec2 scalability terracotta
person sanity    schedule 22.09.2008    source источник
comment
Сегментированный кластер Redis может быть более простым подходом, мог ли он работать в этом сценарии?   -  person cobbzilla    schedule 29.07.2016

Ответы (1)


arrow_upward
4
arrow_downward

Я бы сказал, что ответ на это - квалифицированное да. Terracotta позволяет вам работать с кластеризованными кучами, превышающими размер одной JVM, хотя это не самый распространенный вариант использования.

Вам все еще нужно помнить: а) размер рабочего набора и б) объем трафика данных. Для а) существует некоторый набор данных, который должен находиться в памяти для выполнения работы в любой момент времени, и если размер этого рабочего набора > размера кучи, производительность, очевидно, пострадает. Для b) каждый фрагмент данных, добавленный/обновленный в кластеризованной куче, должен быть отправлен на сервер. Terracotta лучше всего подходит, когда вы меняете мелкие поля в диаграммах pojo. Работа с большими массивами не позволяет наилучшим образом использовать возможности Terracotta (это не означает, что люди иногда не используют его таким образом).

Если вы создаете много мусора, то менеджеры памяти Terracotta и распределенный сборщик мусора должны справляться с этим. Трудно сказать, не попробовав, превышают ли ваши объемы данных доступную пропускную способность.

Ваше приложение получит огромную выгоду, если вы запустите несколько серверов, а данные разделены по серверам или имеют некоторую локальность ссылок. В этом случае вам нужны данные только для одного раздела сервера в куче, а остальные не нужно загружать в память. Конечно, это будет неисправно, если это необходимо для аварийного переключения / доступности, если другие серверы выйдут из строя. Это означает, что в случае секционированных данных вы не выполняете широковещательную рассылку на все узлы, а только отправляете транзакции на сервер.

С точки зрения чисел можно проиндексировать 30 ГБ данных, так что это не предел.

person Alex Miller    schedule 22.09.2008
comment
Быстрое продолжение: я слышал, что если вы используете HashMap с Terracotta, то значения могут быть распределены, но ключи будут зеркалироваться везде. Это правда? Будет ли другая коллекция карт вести себя иначе? - person sanity; 23.09.2008
comment
Правильный. HashMap, ConcurrentHashMap и т. д. будут поддерживать полный набор ключей на всех узлах. Если мы этого не сделаем, трудно понять, связано ли отсутствие ключа с нелокальным ключом или с отсутствующим ключом. Одной из распространенных альтернатив является создание карт карт, позволяющих выгружать больше данных. - person Alex Miller; 23.09.2008
comment
Я должен указать, что это деталь реализации, которая относится к моменту времени. Алекс прав, так проще сделать, но сделать виртуальный набор ключей не невозможно, это просто работа ;) - person Taylor Gautier; 04.10.2008