If you are interested to join the developer community around Apache Geode, subscribe via: dev-subscribe@geode.incubator.apache.org
Apache Geode: Distributed, in-memory database
31–40 of 65 posts
Re: Apache Geode: Distributed, in-memory database
#32Landing page and documentation should be reconsidered. lots of unanswered questions, - distributed, in-memory database - how does it compare to SAP HANA? or Redis? if "... database" where is the querying language? if you have own querying language other than SQL please show us. - Performance is key - tell us about some benchmarks - Consistency is a must - CA or CP in CAP theorem? - Can I fully drop RDBMS in favor of…
Complex objects can be stored by key and automatically partitioned and replicated. Query the data with OQL (an ODMG standard). For example: select * from /person p where p.name = 'foo' and p.age > 42
from docs at[1] they only support SELECT statements in OQL, calling object method in query reminds me Esper complex event processing engine.
[1] - http://geode-docs.cfapps.io/docs/getting_started/querying_qu...
Re: Apache Geode: Distributed, in-memory database
#33Feedback on the documentation: It's not immediately obvious to me how Geode is different from Redis. When would I want to use Geode over Redis, and vice versa?
This > Data is persisted in write-optimized disk storage. Consistency checking is configurable between highest performance caching and ACID transactions. seems pretty different to redis. I don't think Redis does ACID transactions.
Redis is single-threaded, so everything it does on a per-node basis is implicitly atomic. You can also force the single thread to handle a block of commands from a single socket at once by using MULTI (otherwise commands can be interleaved with other commands from other sockets).
Re: Apache Geode: Distributed, in-memory database
#34Didn't understand much from the linked page, but I found this website (from Pivotal, the commercial entity behind Geode) quite informative. Perhaps it's useful to others. https://pivotal.io/big-data/pivotal-gemfire === I found this interesting deployment: China National Railways use Geode to run railway ticketing for the entire country with a 10 node cluster, managing 2 TB of "hot data" in memory, and 10 backup nodes…
Geode wiki is quite good though: https://cwiki.apache.org/confluence/display/GEODE/Index
Re: Apache Geode: Distributed, in-memory database
#35Earlier quoted context omitted.
Apache Geode and Apache Ignite are more similar than they are different. Apache Ignite, based off the commercial distribution Grid Gain is newer to market. Apache Geode, based off the commercial distribution GemFire, has a long history in the market.
I wonder why Apache would need to have two "more similar than different" products.
because people are interested in maintaining each
Re: Apache Geode: Distributed, in-memory database
#36Would you choose it over Datomic?
Re: Apache Geode: Distributed, in-memory database
#37I believe this competes with another well known open-source In-Memory Data Grid, Hazelcast. worth checking out.
Re: Apache Geode: Distributed, in-memory database
#38I believe this competes with another well known open-source In-Memory Data Grid, Hazelcast. worth checking out.
Last time I checked Hazelcast couldn't be run standalone. Also I wouldn't use it as a database for anything more than a few MB of data.
This is probably closer to Apache Ignite aka Gridgain.
Re: Apache Geode: Distributed, in-memory database
#39Source here:
Re: Apache Geode: Distributed, in-memory database
#40I believe this competes with another well known open-source In-Memory Data Grid, Hazelcast. worth checking out.
Last time I checked Hazelcast couldn't be run standalone. Also I wouldn't use it as a database for anything more than a few MB of data. This is probably closer to Apache Ignite aka Gridgain.
Can you explain why ? I remember reading a ton about off-heap memory work they were doing