Мелкозернистая и крупнозернистая модель домена В памяти Data Grid

Мне интересно, какой подход лучше. Должны ли мы использовать мелкозернистые объекты на сетке, а затем строить функционально богатые объекты домена из штрафованных зернистых объектов.Мелкозернистая и крупнозернистая модель домена В памяти Data Grid

Или, альтернативно, мы должны построить объекты объекта с зернистым течением и хранить их непосредственно в сетке и сущности, которые мы просто используем для сохранения.

Редактировать: Я думаю, что этот вопрос еще не ответил полностью. До сих пор у нас есть комментарии от Hazelcast, Gemfire и Ignite. Нам недостает Infinispan, Coherence .... То есть для завершения сакэ :)

источник

2016-03-22 Alexandar Petrov

Я согласен с Валентином, это в основном зависит от системы, которую вы хотите использовать. Обычно я хотел бы хранить объекты расширенного домена напрямую, так или иначе, если бы у вас было очень мало объектов, но их размер был массивным, вы в конечном итоге столкнулись с плохим распределением и неравномерным использованием памяти на узлах. Если ваш объект домена «обычно», и у вас много, вам не следует беспокоиться.

В Hazelcast лучше хранить эти объекты напрямую, но имейте в виду использование хорошей системы сериализации, поскольку Java Serialization работает медленно. Если вы хотите запросить свойства внутри объектов домена, вы также должны рассмотреть возможность добавления индексов.

источник

2016-03-22 18:00:32 noctarius

Привет, большое спасибо за ответ. Почему в Hazelcast улучшенные объекты лучше? Что нового в Hazelcast? –

Hazelcast не предлагает операции объединения, поэтому вам нужно будет выполнить несколько запросов для извлечения всех ваших объектов или, альтернативно, добавить привязку данных и EntryProcessors для генерации объекта домена «на лету» (локальный узел), который является своего рода та же идея, что и операция соединения. Во всяком случае, Hazelcast все о скорости и повторной генерации одних и тех же объектов просто не звучит правильно :) Я бы рекомендовал прочитать о денормализации, если вы не знаете этот термин (https://en.wikipedia.org/wiki/Denormalization). Надеюсь, это имеет смысл, в противном случае вы можете задать дополнительные вопросы :) – noctarius

Вы даете много информации, и у меня есть немного проблем с перевариванием всего этого. Я немного не уверен, рекомендую ли вы хранить мелкозернистые объекты, а затем использовать EntityProcessor для генерации расширенных. Это альтернатива, если мы не можем напрямую сохранить расширенное право? –

Я считаю, что он может отличаться от одной сетки данных к другой. Я больше знаком с Apache Ignite, и в этом случае мелкозернистый подход работает намного лучше, потому что он более гибкий и во многих случаях обеспечивает лучшее распределение данных и, следовательно, лучшую масштабируемость. Ignite также предоставляет богатые возможности SQL [1], которые позволяют объединять разные объекты и выполнять индексированный поиск. Таким образом, вы не потеряете производительность с мелкозернистой моделью.

[1] https://apacheignite.readme.io/docs/sql-queries

источник

2016-03-22 17:35:57

Как насчет совместного размещения? Когда у вас есть сложные объекты, которые вы сохраняете в сетке, вы точно знаете, что данные находятся в совместном размещении, но если вы работаете с мелкозернистыми объектами, как вы знаете, что вложенные агрегирования расположены на одной машине? –

Правильно, вы должны правильно сопоставлять данные при использовании объединений. Вот как это должно быть сделано в Ignite: https://apacheignite.readme.io/docs/affinity-collocation –

Также обратите внимание, что начиная с 1.6 Ignite позволяет выполнять объединения без коллокации. Но это, конечно, не бесплатно, и плохо повлияет на производительность. Такой подход все еще рекомендуется. –

Одним из преимуществ крупнозернистого объекта является согласованность данных. Все в этом объекте сохраняется физически. Но если вы разделите этот объект на 4 небольших объекта, вы рискуете спасти 3 объекта и 1 сбой (по какой-либо причине).

Мы используем GemFire и, как правило, предпочитаем крупнозернистые объекты ... вплоть до точки. Например, наш объект Customer содержит список адресов. Альтернативным вариантом было бы создание одного региона GemFire для «Customer» и отдельного региона GemFire для «CustomerAddresses», а затем надеемся, что вы сможете синхронизировать эти регионы.

Недостатком является то, что каждый раз, когда кто-то обновляет адрес, мы переписываем весь объект Customer. Это не очень эффективно, но наши шаблоны трафика показывают, что изменения адреса очень редки (по сравнению со всеми другими действиями), так что это работает отлично.

Один опыт, который у нас был, является недостатком использования Java Serialization для долговременного хранения данных. Мы избегаем этого сейчас, из-за всех проблем, вызванных совместимостью объектов, поскольку объекты меняются со временем. Не говоря уже о том, что для клиентов .NET становится головной болью, чтобы читать объекты. :)

источник

2016-05-25 13:17:28 Beaker

Мелкозернистая и крупнозернистая модель домена В памяти Data Grid

ответ

Смежные вопросы