This is a really old company, that is going through its fourth incarnation. These incarnations were -
- (Dedicated) Database hardware machines (mid-80's to ~1990). The company at the time was called Servio Logic, and was largely a spin-off from OGI (Oregon Graduate Inst). (Alan Purdy et.al.)
- A Pure OODBMS - GemStone. ~1990 to mid-90's. This was a database whose "upper half" or "object manager" was Smalltalk based. Servio had its own Smalltalk VM that supported a new type of object memory that acted as the client cache backed by persistence. This had a lot of potential, but the "DBMS" part of "OODBMS" was quite weak by relational database standards.
- A persistence layer for, first, ORB's and then for J2EE app servers: mid-90's to early this decade. This was similar to what companies like "Persistence", "TopLink" and other object-to-relational mapping layer products were providing. The key aspect of GemStone (the product) has been the "disk spilling" capability (a la database).
- Now - in-memory data management and caching (with disk spilling capabilities).
In some ways GemStone has always been cool technology in search of a problem to solve (or try to stay relevant in the market). Currently, I believe the product has come a long way away from its hardware and Smalltalk lineage. But the run-time characteristics and sematics supported by what GemStone's database server process could do or what it used to be, still survive.
I hope that helps.
--
Regards,
Sanjeev K.
-------------- Original message ----------------------
From: "Talip Ozturk" <oztalip@gmail.com>
> > 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(R) 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 <http://www.hazelcast.com>: 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.
> >
> >
> >
> >
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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