It looks similar to Hazelcast / Oracle Coherence?
Yes, both Geocode, Coherence, Ignite and Hazelcast are quit similar.Grid computation.
Apache Geode: Distributed, in-memory database
51–60 of 65 posts
Re: Apache Geode: Distributed, in-memory database
#52Can anyone comment on Geode's non-Java support?
I'm asking because a lot of Java "big data" stuff tend to prioritize Java clients (ZooKeeper, Kafka, Hadoop HDFS, Storm, VoltDB and HBase come to mind), and while there are sometimes clients in other languages, they tend to be second-class citizens that take years to reach feature/performance parity with the Java stuff.
For example, last I checked there still wasn't a mature, feature-complete Kafka client (consumer and producer with built in offset management) for Go.
Re: Apache Geode: Distributed, in-memory database
#53Earlier quoted context omitted.
CA is possible if its read only, essentially, with all updates synchronized when a partition is not present [which is the majority of the time in the real world].
It's semantics, but I'd argue if you're read only than you're changing the definition of available.
Geode is write-intensive, and generally optimizes for consistency over availability. That being said - there's a lot built into Geode to ensure availability as well.
Re: Apache Geode: Distributed, in-memory database
#54Re: Apache Geode: Distributed, in-memory database
#55Can anyone comment on Geode's non-Java support? I'm asking because a lot of Java "big data" stuff tend to prioritize Java clients (ZooKeeper, Kafka, Hadoop HDFS, Storm, VoltDB and HBase come to mind), and while there are sometimes clients in other languages, they tend to be second-class citizens that take years to reach feature/performance parity with the Java stuff. For example, last I checked there still wasn't a m…
Gemfire (on which geode is based) has a fully featured c, c++, c# client which has feature parity with the Java client. I don't know if pivotal is going to open source these clients too.
There however is a REST api and a python client https://github.com/gemfire/py-gemfire-rest
Re: Apache Geode: Distributed, in-memory database
#56Sorry for the stupid question: how do in-memory DBs deal with power failures? e.g. someone walking in the server room and trip power cable.
I can understand for read-only in-memory, but what about writes?
Re: Apache Geode: Distributed, in-memory database
#57> Gemcached > Geode servers can be configured to talk memcached protocol. hey this is very interesting, it could work as a persistent acid memcached drop-in replacement!
There's already memcacheDB for that https://github.com/LMDB/memcachedb
That one doesn't seem distributed. But I just glanced at the readme.
Re: Apache Geode: Distributed, in-memory database
#58Earlier quoted context omitted.
CA is possible if its read only, essentially, with all updates synchronized when a partition is not present [which is the majority of the time in the real world].
It's semantics, but I'd argue if you're read only than you're changing the definition of available.
Fair enough but read-only in the event of a network partition is a viable real world use case.
Re: Apache Geode: Distributed, in-memory database
#59Geode FAQ Wiki page https://cwiki.apache.org/confluence/display/GEODE/Technology...
Re: Apache Geode: Distributed, in-memory database
#60Sorry for the stupid question: how do in-memory DBs deal with power failures? e.g. someone walking in the server room and trip power cable. I can understand for read-only in-memory, but what about writes?
In the case of Geode, you can make a "Region" (think table) persistent on disk and using the concept of shared nothing architecture [1] to avoid SPOFs.
What's also interesting is that we offer a very efficient way to recover data from disk as well[2] in the case of a crash of a single node or the entire cluster.
[1] https://en.wikipedia.org/wiki/Shared_nothing_architecture [2] http://gemfire.docs.pivotal.io/docs-gemfire/latest/managing/...