Я думаю, что ваш общий вопрос довольно широк, и нет единого рекомендуемого подхода для охвата всех объединенных коммуникаций (в первую очередь, всех ваших аналитических представлений / моделей ваших данных в соответствии с требованиями вашего приложения (приложений)).
Такие вопросы включают множество факторов, таких как размер отдельных элементов данных, объем данных, частота доступа или шаблоны доступа, исходящие от приложения или приложений, своевременная доставка информации, насколько точными должны быть данные, размер. вашего кластера, физических ресурсов каждой (виртуальной) машины и т. д. Таким образом, любой конкретный подход, несомненно, потребует настройки приложения, соответствующей настройки GemFire и настройки JVM независимо от вашей модели данных. Тем не менее, тщательно созданная модель данных может определить степень такой настройки.
В частности, в GemFire такая настройка будет включать другую конфигурацию, например, но не ограничиваясь: политики управления данными, выселение (Overflow) и срок действия (LRU или, возможно, custom) настройки вместе с разными порогами выселения / истечения срока действия, возможно сохранение данных в память вне кучи с использованием различных стратегий разделения (PartitionResolver) и так далее и тому подобное.
Например, если ваша информация об адресе относительно статична и неизменна (т.е. фактические «справочные» данные), вы можете рассмотреть возможность хранения данных об адресе в REPLICATE регионе. Данные, которые записываются часто (обычно «транзакционные»), лучше использовать в PARTITION регионе.
Конечно, как вы знаете, любые PARTITION данные (управляемые в отдельных регионах), которые вы «присоединяете» к запросу (с использованием OQL), должны быть размещены вместе. GemFire / Geode в настоящее время не поддерживает распределенные объединения.
Кроме того, на определенных узлах могут размещаться определенные регионы, что позволяет разделить кластер на «транзакционные» и «аналитические» узлы, где аналитические узлы обновляются с CacheListeners в регионах в транзакционных узлах (будьте осторожны с this) или, что еще лучше, асинхронно с использованием AEQ с AsyncEventListeners. AEQ можно отдельно сделать высокодоступными и долговечными. Такой транзакционный и аналитический подходы лежат в основе CQRS.
На размер ваших данных также влияет форма, в которой они хранятся, то есть сериализованные или несериализованные, а собственный формат сериализации (PDX) GemFire является оптимальным по сравнению с сериализацией Java. Все зависит от того, насколько «переносимыми» должны быть ваши данные и можно ли хранить данные в сериализованной форме.
Кроме того, вы можете подумать о том, насколько дорого обходится объединение данных на лету. Это означает, что если вы можете относительно дешево агрегировать, преобразовывать и обогащать данные во время выполнения (вычисления или память / хранилище), то вы можете рассмотреть возможность использования Служба выполнения функции, переносящая вашу логику в данные, а не данные в вашу логику (фундаментальная основа MapReduce < / em>).
Вы должны знать, и я уверен, что вы знаете, что GemFire - это хранилище ключей и значений, поэтому отображение сложного графа объекта в отдельные области не является тривиальной проблемой. Разделение объектов по ссылкам (особенно «многие ко многим») и точное знание того, когда их загружать с нетерпением или лениво, является проблемой с перегрузкой, особенно в распределенном хранилище реплицированных данных, таком как GemFire, где существуют компромиссы между согласованностью и доступностью.
Существуют различные API-интерфейсы и фреймворки для упрощения сохранения и выполнения запросов с помощью GemFire. Один из наиболее заметных подходов - это Spring Data GemFire расширение Spring Data Commons абстракции репозитория.
Это также может быть связано с использованием правильной модели данных для работы. Если у вас очень сложные отношения данных, возможно, создание аналитических моделей с использованием базы данных графов (например, Neo4j) будет более простым вариантом. Spring также предоставляет отличную поддержку для Neo4j под руководством Команда Neo4j.
Несомненно, любой выбор дизайна, который вы сделаете, несомненно, будет включать гибридный подход. Часто путь неясен, поскольку он действительно "зависит" (т.е. зависит от приложения и шаблонов доступа к данным, нагрузки и всего прочего).
Но одно можно сказать наверняка: убедитесь, что у вас есть хорошие поверхностные знания и понимание базового хранилища данных и его возможностей управления данными, особенно в том, что касается согласованности и доступности, начиная с this.
Обратите внимание: существует также Slack-канал GemFire , а также список рассылки Apache DEV, который вы можете использовать, чтобы обратиться к экспертам GemFire и сообществу (продвинутых) пользователей GemFire / Geode, если у вас есть другие конкретные проблемы по мере продвижения по этому пути архитектурного проектирования.
person
John Blum
schedule
20.06.2016
