Показаны сообщения с ярлыком IMDG. Показать все сообщения
Показаны сообщения с ярлыком IMDG. Показать все сообщения
понедельник, 16 мая 2011 г.
Are Cloud Based Memory Architectures the Next Big Thing?
Who are the Major Players in this Space?:
With that bit of background behind us, there are several major players in this space (in alphabetical order):
Coherence - is a peer-to-peer, clustered, in-memory data management system. Coherence is a good match for applications that need write-behind functionality when working with a database and you require multiple applications have ACID transactions on the database. Java, JavaEE, C++, and .NET.
GemFire - an in-memory data caching solution that provides low-latency and near-zero downtime along with horizontal & global scalability. C++, Java and .NET.
GigaSpaces - GigaSpaces attacks the whole stack: Compute Grid, Data Grid, Message, Colocation, and Application Server capabilities. This makes for greater complexity, but it means there's less plumbing that needs to be written and developers can concentrate on writing business logic. Java, C, or .Net.
GridGain - A compute grid that can operate over many data grids. It specializes in the transparent and low configuration implementation of features. Java only.
Terracotta - Terracotta is network-attached memory that allows you share memory and do anything across a cluster. Terracotta works its magic at the JVM level and provides: high availability, an end of messaging, distributed caching, a single JVM image. Java only.
WebSphere eXtreme Scale. Operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers.
With that bit of background behind us, there are several major players in this space (in alphabetical order):
Coherence - is a peer-to-peer, clustered, in-memory data management system. Coherence is a good match for applications that need write-behind functionality when working with a database and you require multiple applications have ACID transactions on the database. Java, JavaEE, C++, and .NET.
GemFire - an in-memory data caching solution that provides low-latency and near-zero downtime along with horizontal & global scalability. C++, Java and .NET.
GigaSpaces - GigaSpaces attacks the whole stack: Compute Grid, Data Grid, Message, Colocation, and Application Server capabilities. This makes for greater complexity, but it means there's less plumbing that needs to be written and developers can concentrate on writing business logic. Java, C, or .Net.
GridGain - A compute grid that can operate over many data grids. It specializes in the transparent and low configuration implementation of features. Java only.
Terracotta - Terracotta is network-attached memory that allows you share memory and do anything across a cluster. Terracotta works its magic at the JVM level and provides: high availability, an end of messaging, distributed caching, a single JVM image. Java only.
WebSphere eXtreme Scale. Operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers.
Q&A with Tangosol's Cameron Purdy and Peter Utzschneider
Q&A with Tangosol's Cameron Purdy and Peter Utzschneider:
"Their functionality and the data that they depend on must all be continuously available, surviving failures of servers, networks and even data centers."
"We can now detect a remote garbage collection within milliseconds, and dynamically reshape the cluster's traffic to avoid overheating that node."
"The self-tuning algorithms, flow control and traffic shaping features have propelled us years ahead of the technology curve, and help to explain how Coherence is the lowest latency, highest throughput and most scalable clustered data management system in existence."
"This 3.2 release is also notable because it is the first release that we have focused specifically on cluster latency, largely related to specific requests from telecom and financial services customers."
"In my experience, switching to Infiniband form GigE is a big win. But also, I've seen a strictly linear, by-the-ruler, scaling to nearly 400 cache nodes"
"Their functionality and the data that they depend on must all be continuously available, surviving failures of servers, networks and even data centers."
"We can now detect a remote garbage collection within milliseconds, and dynamically reshape the cluster's traffic to avoid overheating that node."
"The self-tuning algorithms, flow control and traffic shaping features have propelled us years ahead of the technology curve, and help to explain how Coherence is the lowest latency, highest throughput and most scalable clustered data management system in existence."
"This 3.2 release is also notable because it is the first release that we have focused specifically on cluster latency, largely related to specific requests from telecom and financial services customers."
"In my experience, switching to Infiniband form GigE is a big win. But also, I've seen a strictly linear, by-the-ruler, scaling to nearly 400 cache nodes"
понедельник, 7 марта 2011 г.
Oracle Coherence: author blog
Обнаружен блог Cameron Purdy.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
суббота, 19 февраля 2011 г.
Почему я заинтересовался IMDG.
Десятилетие 2005-2015 - это десятилетие (в том числе) The Concurrency Revolution.
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Зачем писать свой IMDG?
Info: лицензия за GemFire на 1 нод на один год - 25K$. Т.е. кластер на 40 нодов - 1M$/year.
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.
P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.
P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!
JGroups: author blog
Обнаружен блог автора и основного разработчика JGroups. Также он еще и разработчик JBoss Infinispan (IMDG).
пятница, 18 февраля 2011 г.
IMDG Internals: JGroups
Давно уже чесались взяться за JGroups - a toolkit for reliable multicast communication.
И вот выяснилось, что ее используют Ehcache, GemFire, JBoss Infinispan:
Ehcache - Replicated Caching using JGroups.
Gemfire - для Member Discovery (не уверен на счет Communication and Data Transfer)
JBoss Infinispan
Тут много всяких доков включая даже книгу (ссылка не работает). "Ken Birman: Building Secure and Reliable Network Applications. Excellent book on group communication. In-depth description of various protocols (atomic bcast, causal, total order, probabilistic broadcast). Very technical content."
P.S. Есть желание изучить ключевые либы, на которых строятся cutting edge проекты для JVM. Пока обнаружено два кандидата: JGroups и Netty (пожулуй самая производительная либа для NIO). Netty вместе с автором сейчас работают над JBoss Infinispan.
И вот выяснилось, что ее используют Ehcache, GemFire, JBoss Infinispan:
Ehcache - Replicated Caching using JGroups.
Gemfire - для Member Discovery (не уверен на счет Communication and Data Transfer)
JBoss Infinispan
Тут много всяких доков включая даже книгу (ссылка не работает). "Ken Birman: Building Secure and Reliable Network Applications. Excellent book on group communication. In-depth description of various protocols (atomic bcast, causal, total order, probabilistic broadcast). Very technical content."
P.S. Есть желание изучить ключевые либы, на которых строятся cutting edge проекты для JVM. Пока обнаружено два кандидата: JGroups и Netty (пожулуй самая производительная либа для NIO). Netty вместе с автором сейчас работают над JBoss Infinispan.
среда, 16 февраля 2011 г.
Собираю материал по Memory Consistency Models of IMDGs
Собираю материал по Memory Consistency Models of IMDGs.
Помогите кто чем богат:)
В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.
Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).
Помогите кто чем богат:)
В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.
Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).
Подписаться на:
Сообщения (Atom)