ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Infinispan: All content tagged as Infinispan in NoSQL databases and polyglot persistence

Main Features of In-Memory Data Grids

Good article about In-Memory Data Grids on Cubrid’s blog by Ki Sun Song.

The features of IMDG can be summarized as follows:

  • Data is distributed and stored in multiple servers.
  • Each server operates in the active mode.
  • A data model is usually object-oriented (serialized) and non-relational.
  • According to the necessity, you often need to add or reduce servers.

Even if you don’t read it all, but plan to use an IMDG solution, the first two questions you want to ask your vendor are: what the approach you are proposing to deal with the limited memory capacity and what’s the strategy for reliability. You’ll get good answers from well established products, but these answers are not necessarily the ones that provide the exact requirements your solution will need.

Original title and link: Main Features of In-Memory Data Grids (NoSQL database©myNoSQL)

via: http://www.cubrid.org/blog/dev-platform/introduction-to-in-memory-data-grid-main-features/


NoSQL Databases Adoption in Numbers

Source of data is Jaspersoft NoSQL connectors downloads. RedMonk published a graphic and an analysis and Klint Finley followed up with job trends:

NoSQL databases adoption

Couple of things I don’t see mentioned in the RedMonk post:

  1. if and how data has been normalized based on each connector availability

    According to the post data has been collected between Jan.2011-Mar.2012 and I think that not all connectors have been available since the beginning of the period.

  2. if and how marketing pushes for each connectors have been weighed in

    Announcing the Hadoop connector at an event with 2000 attendees or the MongoDB connector at an event with 800 attendeed could definitely influence the results (nb: keep in mind that the largest number is less than 7000, thus 200-500 downloads triggered by such an event have a significant impact)

  3. Redis and VoltDB are mostly OLTP only databases

Original title and link: NoSQL Databases Adoption in Numbers (NoSQL database©myNoSQL)


Hibernate OGM: Why, What, How

Very good post by Emmanuel Bernard on the Hibernate blog explaining why Hibernate OGM was created, how it works, and what the plan is.

Why Hibernate OGM

At JBoss, we strongly believe that provided tools become available, developers, applications and whole corporations will exploit new data usage patterns and create value out of it. We want to speed up this adoption / experimentation and bring it to the masses. NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. It’s not really surprising, NoSQL solutions are inherently complex, extremely diverse and come with quite different strengths and weaknesses: going for it implies a huge investment (in time if not money). (One of) JBoss’s goal is to help lower the barrier of entry and Hibernate OGM is right inline with this idea.

This sounds like the expanded version of what I was writing about Spring Data. Both Spring framework and Hibernate have been accepted inside enterprises for a long time now. If they start providing integrations with NoSQL databases, then the enterprise teams will not have to go through the long acceptance cycles anymore.

How Hibernate OGM Works?

Entities are stored as tuples which essentially is a Map where the key is the column name and the value is the column value. In most cases, the property is mapped to a column but this can be de-correlated (@Column). An entity tuple is accessible via a single key lookup. Associations as a bit trickier because unlike RDBMs, many NoSQL stores and Grid specifically do not have build-in query engines and thus cannot query for associated data easily. Hibernate OGM stores navigational information to go from a given entity to its association information. This is achieved by a single key lookup. The drawback here is that writing requires several key lookup / update operations.

The post provides more details about how Hibernate OGM plans to address the mismatches between the object world and NoSQL storages, but also those between NoSQL storages and the JPA specification. Worth keeping in mind is that even if Hibernate OGM will bring the JPA standard to NoSQL databases, there will be many limitations to what can be done due to the different natures of the models involved. More advanced projects will probably need custom serializers/deserializers, special query implementors, etc.

The future of Hibernate OGM

  • support for other key/value pair systems
  • support for other NoSQL engine
  • declarative denormalization: we have focused on feature so far, performance check and association denormalization is planned)
  • support for complex JP-QL queries including to-many joins and aggregation
  • fronting existing JPA applications

Hibernate OGM has a long way to go. The list of NoSQL databases Spring Data integrates with is longer for now: Redis, Riak, Neo4j and a couple more.

Original title and link: Hibernate OGM: Why, What, How (NoSQL database©myNoSQL)

via: http://in.relation.to/Bloggers/HibernateOGMBirthAnnouncement