Skip to content

Instantly share code, notes, and snippets.

@otrack
Last active September 25, 2017 11:30
Show Gist options
  • Save otrack/cb6d0e5f3d6c9bd61a476b8dc41bfc1a to your computer and use it in GitHub Desktop.
Save otrack/cb6d0e5f3d6c9bd61a476b8dc41bfc1a to your computer and use it in GitHub Desktop.
indexing.md

Callable and queryable objects over a NoSQL storage

slides

Context

Cloud applications are commonly split in three distinct tiers, the presentation tier, the application tier and the storage tier. The presentation tier displays information related to the application services, such as web pages. The application tier contains the business logic. The storage tier executes the data persistence mechanisms (database servers, file shares, etc.) and the data access layer that encapsulates the persistence mechanisms and exposes the data.

Traditionaly, an object-relational mapping (ORM) [1] converts the data between the application and the storage tier. The ORM materializes the frontier between the two tiers, and it reduces the coupling. However, it also forces to repeatedly convert the objects between their in-memory and their serialized representations. This negatively impacts performance and increases execution costs.

In a recent paper [2], we describe the design of Creson, a system supporting callable objects over a NoSQL storage. With Creson, instead of fetching objects from the storage, the application directly calls them. Creson ensures that the objects are persisted and shared consistently amonng several client machines. As an example, consider the following two classes.

class Hero{@Shared Room location;}
class Room{Treasure loot();}

The Hero class contains a location field annotated with @shared. This tells Creson to push the location to the storage tier, allowing several instances of Hero on several application machines to access the same location object transparently. Creson ensures that the object are strongly consistent over time. In the example above, this means that if two heroes stand in the same rooom, only one of them may loot the treasure.

Objectives

In the current state, Creson does not support transparently the indexing of objects. Going back to the above example, this means that to retrieve all the rooms, the application needs to maintain an explicit index, e.g.,

List<Room> allRooms;

Compared to standard practices in the object-relational world, managing an explicit index increases the burden of the developper.

The goal of this project is to add an automated indexation mechanism to the Creson code base. This mechanism should allow the indexation and querying of objets stored in Creson with ease. The querying language will be JPQL, a standard close to SQL and defined in the Java persistent API (JPA).

Roadmap

Creson is implemented on top of Infinispan (ISPN), the industrial-grade NoSQL datastore of RedHat. The students will first acquire an understanding of ISPN and of the existing querying mechanisms. Then, they will investigate Creson and will adapt the indexing mechanisms of ISPN to the objects persisted in Creson. Further, the students will interface a JPQL query engine, and demonstrate the effectiveness of their approach in practice.

Contact

Pierre Sutra

References

[1] https://en.wikipedia.org/wiki/Object-relational_mapping

[2] CRESON: Callable and Replicated Shared Objects over NoSQL, Pierre Sutra, Etienne Rivière, Cristian Cotes, Marc Sánchez Artigas, Pedro Garcia Lopez, Emmanuel Bernard, William Burns and Galder Zamarreño, 37th IEEE International Conference on Distributed Computing Systems (ICDCS 2017).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment