Терракотовая + Компас = Hibernate + HSQLDB + JMS?

Question

В настоящее время мне нужен высокопроизводительный механизм хранения Java.

Это означает:

1) У меня более 10000 объектов с 1 - много отношений.

2) Объекты обновляются каждые 5 секунд, причем самые последние обновления сохраняются в случае сбоя системы.

3) Объекты должны быть доступны для запроса в течение разумного времени (1-5 секунд). (IE: дайте мне все объекты с этой отметкой времени или все объекты в пределах этих границ местоположения).

4) Объекты должны быть доступны в различных установках Glassfish.

В настоящее время:

Я использую JMS для распределения объектов, Hibernate как ORM и HSQLDB для обеспечения необходимой восстанавливаемости.

Я не совсем доволен исполнением. Особенно это касается JMS.

После некоторого исследования переполнения стека, мне интересно, будет ли это лучшим решением. Имейте в виду, что у меня нет опыта с тем, что дает мне Терракота.

Я бы использовал Terracotta для распределения объектов по системе, а что-то еще, чтобы дать возможность «запрашивать» атрибуты этих объектов.

Это звучит разумно? Будет ли это соответствовать этим ограничениям производительности? Какие еще решения я должен рассмотреть?

Answer 1

Я знаю, что это не то, что вы просили, но вы можете начать с переключения с HSQLDB на H2 . H2 - относительно новая, чистая БД Java. Он написан тем же парнем, который написал HSQLDB, и он утверждает, что производительность намного лучше. Я использую это в течение некоторого времени, и я очень доволен этим. Это должен быть очень быстрый переход (добавить Jar, изменить строку подключения, создать базу данных), поэтому стоит попробовать.

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

Answer 2

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

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

Относительно ваших требований и терракота:

1) 10 тыс. Объектов довольно мало с точки зрения терракоты

2) 5-секундная частота обновления не выглядит проблемой. Может зависеть от того, сколько существует узлов и есть ли естественное разбиение, которым вы можете воспользоваться. Все обновления будут постоянными.

3) Время запроса 1-5 секунд кажется довольно простым. Создание собственных хорошо организованных структур данных для поиска - сложная часть. Очевидно, вы хотите избежать сканирования всех данных.

4) В настоящее время Terracotta поддерживает Glassfish v1 и v2.

Если вы разместите на форумах Terracotta , вы, вероятно, получите больше глазных яблок Terracotta по этой проблеме.

Answer 3

Во-первых, Люсен здесь не твой друг. (только чтение)

Терракота - это масштаб на логическом слое! Кажется, ваша проблема не связана с логикой обработки. Это больше касается места хранения / связи.

1. Определите свое узкое место! Оцените время и издержки обработки хранилища / логики / JMS!
2. Устраните проблемы JMS с помощью хорошей платформы JMS (например, ActiveMQ) и с хорошей / настроенной конфигурацией.
3. Может быть, хранилище распределенных ключей => - ваш друг. Попробуйте Project Voldemort !
4. Если вы хотите остановиться в Hibernate и HSQL, ознакомьтесь с Hibernate 2-го уровня и пулами соединений (c3po, управляемый контейнером ...)!

Answer 4

Может быть, вам стоит взглянуть на: Превайлер .

Ваши объекты всегда в памяти. «Изменения» ваших объектов сохраняются. Время от времени вы можете сделать снимок: каждый объект сохраняется.

Answer 5

Вы не говорите, какого вендора вы используете для JMS, но я не удивлюсь, если у вас там есть горлышко бутылки. Я не мог получать более 100 сообщений в секунду от ActiveMq, и что бы я ни пытался с точки зрения конфигурации подтверждения, размера очереди и т. Д., Мы не смогли снизить нагрузку на ЦП выше нескольких процентов.

Решением было объединить множество запросов в одно сообщение JMS. У нас был простой класс, который либо отправлял пакет сообщений, когда доходил до 200 запросов, либо достигал тайм-аута (мы использовали 20 мс), что дало нам резкое увеличение пропускной способности.

Answer 6

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

Я не эксперт по БД, но я думаю, вам стоит взглянуть на любое из решений по распределенным БД, которые были в новостях в последнее время. (CouchDB, Кассандра)

Answer 7

В настоящее время я работаю над написанием клиента для очень (очень) быстрой распределенной хеш-базы данных Key / Value, которая обеспечивает семантику set + list. База данных - C99 и требует GCC, и сейчас я борюсь со старым добрым сетевым вводом-выводом Java, чтобы преодолеть мой текущий барьер в 30 000 получения / наборов в секунду. Надеюсь, что будет сделано в течение недели. Напишите мне через мой аккаунт, и я вернусь, когда придет время.

Answer 8

Terracotta + jofti = запрашиваемые постоянные кластеризованные структуры данных Поиск в Google для терракотовой карты запросов или посетите tusharkhairnar.blogspot.com для блога запроса карты Вы можете также интегрировать timasync для обновления вашей базы данных. База данных - это ваша система записи, использующая терракоту в качестве механизма кэширования и выгрузки базы данных, вы даже можете пакетно обновлять асинхронные обновления, чтобы сделать ее более быстрой, чтобы в БД содержались довольно свежие данные

Tushar tusharkhairnar.blogspot.com

Answer 9

Гарантированный обмен сообщениями будет намного медленнее, чем передача сообщений. Поскольку каждый объект обновляется каждые несколько секунд, вы можете рассмотреть возможность пакетирования ваших обновлений (скажем, 500 изменений или по времени, скажем, времени в 1-10 мс), отправки через непостоянные сообщения и пакетирования ваших транзакций. В этом случае вы, скорее всего, будете ограничены пропускной способностью. При настройке варианта использования вы можете обнаружить, что меньшие размеры партий также работают эффективно. Если пропускная способность критична (скажем, у вас соединение 10 МБ или медленнее, вы можете использовать сжатие через JMS)

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