Haven't heard much about this making it into production environments yet Alexey. Anything you can share with us? I know there has been a long effort by IBM to get this out though....
On Jun 10, 2008, at 2:31 AM, Alexey Roytman wrote:
Hi,
IBM has a similar product. Its name is ObjectGrid. It can be used as a shared coherent cache, or a data base front-end. It supports maps and entities abstractions, MapReduce / DataGrid patterns and etc.
See http://www-128.ibm.com/developerworks/wikis/display/objectgrid/Getting+started )
So it is another candidate to the cloud environment.
Regards
Alexey.
Alexey Roytman
Distributed Middleware
IBM Research Laboratory in Haifa
> GemStone basically *IS* a distributed database
Never heard this before. GemStone defines itself as more like in-mermoy data management and caching solution.
"The GemStone® EDF flagship product—GemFire Enterprise™—is an in-memory data management solution that sits in the middle-tier between the applications and the data sources to provide distributed caching, continuous analytics semantics and message bus service all in one and operates at memory speeds. It provides low-latency and near-zero downtime along with horizontal & global scalability. The GemFire Enterprise solution is easy to adopt with simple HashMap API. The programming paradigm is extremely simple and familiar, but what it does behind the scenes is the real value proposition. You simply "put" your state into the local HashMap of your business service and under the covers the middleware takes care of replicating, persisting and managing this business object to multiple additional servers in a massively distributed environment."
Source: http://gemstone.com/products/gemfire/enterprise.php
No claim of its being a distributed database! Am I missing something?
Regardless I think Gemstone, Oracle Coherence and Gigaspaces are great grid application enablers and cloud is a nice ecosystem to run grid(dy) applications.
Best,
Talip Ozturk
Hazelcast: Clustering and data distribution platform for Java
blog :http://www.jroller.com/talipozturk
On Sun, Jun 8, 2008 at 10:19 PM, Stuart Charlton <stuartcharlton@gmail.com> wrote:
> Log shipping like Oracle's data guard tends to work well in covering for log
> failures. I've also seen success with storage-level replication like EMC's
> SRDF.
> It can be problematic, however, for catastrophic failure (i.e. the whole
> data center), as the latency of synchronous replication over a WAN can be
> performance prohibitive beyond a few hundred miles or so (i.e. your DR site
> couldn't be across the continent). Of course, you could go asynchronous
> and tolerate some data loss as acceptable in such a scenario -- just that
> many aren't willing to (i.e. in CAP conjecture terms, emphasizing
> "C"onsistency & "A"vailability but becoming unavailable during a network
> "P"artition). Or you could partition / shard the data set itself to
> segment disruption, though that in itself has a whole pile of tradeoffs.
> Solutions like Gemstone, Gigaspaces, Coherence, etc. if you're using "write
> behind" caching, all basically perform the same idea as log shipping and
> have similar tradeoffs as a traditional DB's log shipper, though they go
> about it in different ways. (e.g. GemStone basically *IS* a distributed
> database, whereas Gigaspaces & Coherence are distributed caches that
> delegate to an RDBMS or indexed file).
>
> Cheers
> Stu
>
>
> On 6-Jun-08, at 8:04 AM, Alan Ho wrote:
>
> There is good old oracle with hot-standby. Its not perfect, but our
> applications was able to fail-over gracefully from one oracle instance to
> another oracle instance.
>
> Regards,
> Alan Ho
>
>
>
>
> ----- Original Message ----
> From: Gavan Corr <gcorr@nyx.com>
> To: cloud-computing@googlegroups.com
> Sent: Friday, June 6, 2008 5:57:43 AM
> Subject: Re: Reliability in of the cloud
>
> There are a number of commercial data caching solutions in the market,
> Gemstone, Coherence (now from Oracle) and Gigaspaces, and to a lesser extent
> terracotta. of those, Gemstone is the only one I have seen successfully
> deployed in a large scale multi site environment to ensure consistency of
> data between multiple sites, and to do reliable failover if a node or a
> center fails. Hadoop is gaining interest but not there yet...
> Gavan
>
>
> On Jun 5, 2008, at 9:00 PM, Khazret Sapenov wrote:
>
> Alan,
> If you are talking about Hadoop, then high availability is not inherent in
> it yet (but maybe it changed recently).
> As far as I know, while there is Secondary Name Node provided (that resides
> in another data center) there's no guarantee of real time switch of Job
> Tracker/Name Node/Task Tracker/Data Nodes of DC A to Job Tracker/Name
> Node/Task Tracker/Data Nodes of DC B.
>
> cheers
> --
> Khaz Sapenov,
> Director of Research & Development
> Enomaly Labs
>
> US Phone: 212-461-4988 x5
> Canada Phone: 416-848-6036 x5
> E-mail: khaz@enomaly.net
> Get Linked in> http://www.linkedin.com/in/sapenov
> On Thu, Jun 5, 2008 at 8:41 PM, Alan Ho <karlunho@yahoo.ca> wrote:
>>
>> I guessed that about google app engine too.
>>
>> Things get really interesting when you need to do election leader
>> decisions across data centers. E.g. If you are doing a big map-reduce task
>> in one data center, it goes down, so you want to finish the task in another
>> data center.
>>
>> How does one transfer the task ? Is it even worth solving ?
>>
>> Alan Ho
>>
>>
>> ________________________________
>> From: Reuven Cohen <ruv@enomaly.com>
>> Sent: June 05, 2008 10:03 AM
>> To: cloud-computing@googlegroups.com
>> Subject: Re: The Business of Building Clouds
>>
>> From what I've seen of Google App Engine, they distribute your python code
>> to dozens of servers and then use some kind of round robin to spread the
>> load. Nothing ground breaking.
>>
>> r/c
>>
>> On Thu, Jun 5, 2008 at 12:59 PM, wyim wyim <wingmanyim@hotmail.com> wrote:
>>>
>>>
>>> In regards to failover, does Google App Engine have some sort of a
>>> LoadBalancer API?
>>>
>>> thanks
>>> Wayne Yim
>>>
>>>
>>> ________________________________
>>> From: stuartcharlton@gmail.com
>>> To: cloud-computing@googlegroups.com
>>> Subject: Re: The Business of Building Clouds
>>> Date: Thu, 5 Jun 2008 09:07:12 -0700
>>>
>>>
>>>
>>> On 5-Jun-08, at 8:35 AM, Alan Ho wrote:
>>>
>>> Picking a provider that has data center failover is critical - but it
>>> does mean that you write your application in a way that can failover
>>> gracefully. Cloud providers need to provide the base infrastructure to do so
>>> OR constrain the user to a particular programming paradigm (like the
>>> limitations of google app engine)
>>>
>>> That's a very astute observation, Alan. Constraining an architecture
>>> to induce certain properties (guarantees?) is likely the right approach.
>>> Though I wonder if AppEngine is a bit too "Nanny-ish" that limit its
>>> audience in ways that don't really impact the big picture qualities.
>>> For example, the choice of Python was easy because it was a standard
>>> Google language, but that doesn't seem to be inherently a more applicable
>>> language than say C#, Java or Ruby.
>>>
>>> I expect in the future that cloud computing systems will provide the
>>> concept of "cloud events" in case of major datacenter failures. I just don't
>>> see any way round it.
>>>
>>> I wonder if Google actually provides this sort of failover for AppEngine
>>> today. Certainly, they could, though they provide no such guarantees at
>>> the moment.
>>> As for "cloud events" - yup. In the traditional data centre, it's
>>> likely SNMP or JMX traps. On the cloud, it's not entirely clear if/where
>>> SNMP would play. Or WS-Man. Or something newer (?).
>>> Cheers
>>> Stu
>>>
>>>
>>>
>>
>>
>>
>> --
>> --
>>
>> Reuven Cohen
>> Founder & Chief Technologist, Enomaly Inc.
>> www.enomaly.com :: 416 848 6036 x 1
>> skype: ruv.net // aol: ruv6
>>
>> blog > www.elasticvapor.com
>> -
>> Get Linked in> http://linkedin.com/pub/0/b72/7b4
>>
>>
>>
>>
>>
>> ________________________________
>>
>> Visit our website at http://www.nyse.com
>>
>> *****************************************************************************
>> Note: The information contained in this message and any attachment to it
>> is privileged, confidential and protected from disclosure. If the reader of
>> this message is not the intended recipient, or an employee or agent
>> responsible for delivering this message to the intended recipient, you are
>> hereby notified that any dissemination, distribution or copying of this
>> communication is strictly prohibited. If you have received this
>> communication in error, please notify the sender immediately by replying to
>> the message, and please delete it from your system. Thank you. NYSE
>> Euronext, Inc.
>>
>
> ________________________________
> Ask a question on any topic and get answers from real people. Go to Yahoo!
> Answers.
>
>
>
>
> >
>
Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext, Inc.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---
Posts
No comments:
Post a Comment