Entries Tagged 'Data Grid' ↓

Demain soir à 19h30 se déroule le traditionnel Paris JUG, événement réunissant la communauté Java parisienne autour d’un certain nombre de sujets d’actualité. Je précise pour les non initiés
Il est vrai que d’ordinaire nous ne postons jamais au sujet de cet événement car d’autres confrères le font très bien.
Cependant, il me semblait important de mentionner la présentation Data Grid qui me semble très intéressante et d’actualité dans un certain nombre de projets.

Qu’est ce que le Data Grid ?

Tous ceux qui sont confrontés à des problématiques de temps d’accès aux données ou de traitements massifs de ces données recherchent des solutions alternatives aux bases de données relationnelles.
Les Data Grid en mémoire permettent de clusteriser la mémoire d’un parc hétérogène de machines tout en fournissant un accès simple (clef valeur, ?QL, template d’objet) et transactionnel, à cet espace mémoire virtualisé.
Le stockage des données en mémoire est fiabilisé par un certain nombre de mécanismes et le Data Grid fournit les indispensables mécanismes d’intégration au SI dont, notamment, les bases de données existantes.
Lorsqu’on revient aux fondamentaux; j’aime considérer les technologies en identifiant leur impact sur les éléments matériels sous-jacents (CPU, mémoire, disque, réseau); on se rend compte que les technologies Data Grid fournissent une réponse très adaptée dans beaucoup de situations car les temps d’accès et la bande passante de la mémoire sont infiniment supérieurs à ce que peuvent proposer les disques.
Évidemment, on peut toujours payer très cher pour essayer d’atteindre les mêmes performances que la mémoire avec des disques spécialisés, mais le veut on ?
Oui me diront certains, ça rassure ! Mais c’est un autre débat et puis ces temps-ci, en période de crise, ça fait pas très classe

La base de données change de rôle

En tant que partenaire GigaSpaces, un des leaders de ce domaine, nous voyons de plus en plus d’entreprises de toute taille qui démarrent des études afin de choisir le Data Grid qui permettra à leurs projets stratégiques de gérer les problématiques de stockage haute-performance et de traitements de données.
Depuis un peu plus de 3 ans environ, une grosse partie de notre activité a été de concevoir avec nos clients, et mettre en production, des systèmes stratégiques fondés sur les technologies Data Grid. Non seulement ça marche, mais les performances sont au rendez vous :
- plusieurs dizaine de milliers d’appels par seconde
- des temps de réponse inférieurs à la milliseconde sur des réseaux classiques 1GB
tout çà sur une “lame” d’entrée de gamme à quelques milliers d’euros pièce.

Lorsqu’on voit la prolifération d’offres alternatives aux bases de données relationnelles, il est désormais clair que le rôle de la base de données est en train de changer (ou a déjà changé pour certains) dans le système d’informations.
La base de données a imposé son hégémonie dans nos systèmes d’information depuis des années et a fait la richesse de certains acteurs du secteur, mais il est désormais acquis que la base de données ne peut pas monter en charge sans faire la richesse des vendeurs de matériel.
D’ailleurs, curieusement, dans certains cas, ce sont les mêmes

Le Data Grid s’est donc imposé avec le temps; projet après projet, secteur d’activité après secteur d’activité comme la solution alternative à la base de données, notamment lorsque celle ci se trouve sur le chemin critique des transactions.
Des pionniers de ce secteur comme GigaSpaces martèlent ce message depuis une dizaine d’années maintenant.
D’autres utilisateurs et fournisseurs d’infrastructures massivement distribuées ont utilisé un certain nombre de concepts  d’informatique distribuée sous-jacents aux technologies Data Grid dans leurs infrastructures internes.
Je pense notamment à Google, Amazon, Facebook qui n’ont pas eu le choix, pour des raisons économiques que de créer des alternatives pour stocker et exploiter de manière efficace leurs données.
Comme il faut rendre à César ce qui appartient à César on peut même dire que ces acteurs incontournables du Web poussent à leurs limites les technologies traditionnelles et dans certains cas poussent (ou tirent comme vous voulez) l’innovation. Le concept MapReduce a été popularisé par Google par exemple.

Le Data Grid, la boite à outils pour le traitement massif de données

Lorsqu’il m’arrive de présenter GigaSpaces, je fais souvent l’analogie entre GigaSpaces et les concepts sur lesquels s’appuient ces énormes infrastructures en indiquant que GigaSpaces peut être vu comme une technologie permettant de productiser, et rendre accessible de manière simple un ensemble de concepts d’informatique distribuée.
Cela nous permet à nous, architectes et développeurs, d’avoir les outils permettant d’assurer la performance et la scalabilité de nos applications distribuées.
D’ailleurs à ce propos, je voudrais mentionner cet article qui explique bien un certain nombre de principes de l’informatique distribuée : http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf tels que les concepts de Grid Computing, de Master Worker ou de MapReduce.

Au delà de la gestion des données en mémoire, de manière fiabilisée et très performante, le Data Grid permet de paralléliser les traitements sur les données en permettant l’implémentation de patterns tels que Master Worker ou Map Reduce.

Les capacités du Data Grid sont multiples, les technologies Data Grid sont matures (car d’autres ont débuggé pour vous, vous savez ce que c’est ), et les cas d’utilisation foisonnent, tous secteur d’activités confondus.

Voilà, j’espère que je vous aurai donné envie de venir assister à cette présentation Data Grid si vous n’étiez déjà convaincus, et je serai présent ainsi qu’un certain nombre de nos consultants (dont Jean-Michel qui participe à cette présentation) pour discuter de tout çà avec vous.

Pour venir : http://www.jugevents.org/jugevents/event/16041
Les détails de la présentation : http://www.parisjug.org/xwiki/bin/view/Meeting/20090512

The spaceRetry project is a plugin for GigaSpaces OpenSpaces.

Features:

• Lazy-load: we can instantiate the PU also if the proxy can’t connect to the space
• Connection is made when we invoke a method on the IJSpace Proxy (like a write)

Synopsis:

We have developed this plugin in order to fix two problems with the space components of OpenSpaces.
1) The Space component of OpenSpaces allows you to create an IJSpace.
If we want to create a Remote Space with an url like jini://*/*/space the remote site has to be deployed first. If not, the deployment of the PU will failed with a org.openspaces.core.space.CannotFindSpaceException (ATTENTION: Failed to find space with url …).

2) The second problem is about automatic proxy renewal.
If the proxy loose his connection there is no mechanism to try to rebind the connection when a method of IJSpace is invoked.

Now, let’s dive into the configuration of this component.

Configuration

In order to have the <fc-os:spaceretry> namespace add

xmlns:fc-os="http://opensource.fastconnect.org/schema/spaceretry"

Then add the schema location

http://opensource.fastconnect.org/schema/spaceretry http://opensource.fastconnect.org/schema/space/fcspace.xsd

Finally, to use the fcSpaceRetry proxy, you have to wrap the <os-core:space /> with the <fc:spaceretry/> tag.

<fc-os:spaceretry id="myspace" max-retry-init="1" max-retry-invoke="1" wait-time="5000">
<os-core:space id="ijspace" url="jini://*/*/mySpace" />
</fc-os:spaceretry>

Parameters:

• max-retry-init: the number of tests for connexion during the initialization of the proxy
• max-retry-invoke: the number of tests for connexion when a method of IJSpace is invoke
• wait-time: the wait time between both tests of connexion (in millisecond)

Use the <os-core:space> like you have the used to do.

If you use Maven, you have also add a dependency to space-retry in your POM.xml

<dependencies>
<dependency>
<groupId>fr.fastconnect.openspaces</groupId>
<artifactId>space-retry</artifactId>
<version>0.7</version>
</dependency>
</dependencies>

Technical Information

The spaceRetry plugin extends the UrlSpaceFactoryBean and overloads the doCreateSpace method to create a new instance of IJSpaceProxy (dynamic proxy of IJSpace).

Algorithm :

We try n times to create an IJSpace with the SpaceFinder.find(spaceURL). When the max-retry-init is reached, we create a proxy of the IJSpace but not initialised.

When a method of the IJSpace is invoked and if the connection is not established the IJSpaceProxy try n times to make the connection.
When the max-retry-invoke is reached, the IJSpaceProxy throw a RuntimeException.

Compatibility

The spaceRetry plugin is compatible with all components of the IJSpace (core, events or remoting components). Just use the id of the spaceRetry bean to have all benefits of the plugin.
Example :

<fc:spaceretry id="myspace" max-retry-init="2" max-retry-invoke="5" wait-time="5000">
<os-core:space id="dontuseit" url="/./mySpace" />
</fc:spaceretry>
<os-core:giga-space id="gigaSpace" space="myspace"/>

More information on https://opensource.fastconnect.org/redmine/projects/show/extended-space-bean

As part of my job, I often visit customers of very different needs and application types, but most of them have one thing in common; data, data and more data. Data related challenges are numerous but in this post I’d like to share with you a few alternatives to solving a common scenario; where the application is using multiple persistency layers that need to be synchronized, without compromising consistency or performance.

Persistency as a Service

Data modification performed on a GigaSpaces cluster can be received asynchronously using a central process. This process is called the Mirror Service.

This concept is mostly used in two scenarios:

• As a persistence mechanism; click here to read more.
• As an optimized over the WAN replication facility

The Mirror Service allows providing your own logic to deal with batches of modifications by implementing the BulkDataPersister interface. While a powerful capability, this does not allow configuring multiple implementations simultaneously.

Simultaneous Configuration

A solution to workaround the challenge stated above is to implement a specific BulkDataPersister that broadcasts the data to concrete implementations, internally. Every method calls will then be forwarded to all persistency layers. Composite BulkDataPersister is a generic implementation of this pattern, allowing to simply configure multiple concrete BulkDataPersister used by a Mirror Service.

What do I mean by simply? All you need to do is to configure your regular BulkDataPersister implementations (using either regular property file or spring injection) and then configure the Mirror Service to use Composite BulkDataPersister.

Internally, a thread pool will be used to delegate the execution of all implementations in parallel.

Inconsistency Handling

The Composite BulkDataPersister approach could leads to inconsistency between the various BulkDataPersisters, in case one of the delegates fails.

To solve this, the following steps can be taken:

• A generic strategy can be used for handling partial failures.

• One of the default strategies will use another space to store all information related to a particular failure.

• Ultimately, if the strategy itself fails, an exception is propagated to the Mirror Service, which then triggers the redo-log mechanism (so one batch might be received several time by a delegate).

Implementation of this pattern with full documentation is available here.

Since inconsistencies pose a potential risk using this approach, I recommend keeping in mind all failure scenarios, including the most unlikely ones. If everything fails, data modifications can be received several times by persistency layers due to the Mirror Service redo-log granularity.

Nevertheless, this simple pattern allows leveraging the performance improvement provided by the Mirror Service in highly distributed and dispersed environments, while still ensuring full reliability. In fact, one of our clients with strong WAN performance requirements is already using it.

Further improvements to this pattern might include transaction usage and JMX management.

Do you consider those features important? Are the available entry points sufficient to your needs?