The purpose of Orestes is to enable low latency with tunable consistency for a broad set of database systems. This is achieved by a middleware design that promotes database independence of central data management capabilities such as schema management and caching. To exploit the benefits in a broad set of application contexts, Orestes exposes data stores as a DBaaS and BaaS by enhancing them with the necessary functional ex-tensions (e.g., backend code) and security mechanisms (e.g., object-level access control).
By making the middleware tier scale independently from database systems, multi-tenant cloud data management is achieved without compromising the heterogeneous trade-offs found in NoSQL database systems.
To illustrate the usefulness of Orestes with respect to requirements-driven development of data-centric applications, consider a typical development process for a scalable two-tier application:
1. First, an Orestesdata modelis defined that leverages the hybrid approach of mixing well-known data types with more flexible schemaless elements. The schema design uses a visual editor in a web dashboard to allow easy definition and sharing of the core application data model.
2. One or more database technologiesare chosen to provide the DBaaS/BaaS used by the application. The step can either happen manually based on the NoSQL tool-box proposed in the beginning of this chapter, or through an automized process as described in Chapter 5.
3. If the application is based on an existing corpus of data, it is imported and trans-formed to the specified data model.
4. The application’s web or appfrontendis developed without requiring any previously developed server-side application logic (e.g., HTML template rendering). Orestes exposes a database REST API that is consistent across projects and therefore easy to apply.
5. Any critical or confidential parts of the business logic are developed as backend codemodules, handlers, or scheduled code using the same APIs as the frontend to perform queries, load and save objects, and manage users.
6. Access to data issecuredby defining appropriate schema ACLs during the modeling phase, and setting object-level ACLs that protect access according to any application-level notion of permissions.
7. The application artifacts like the schema, backend code, and frontend assets are ver-sioned and sharedacross teams through an arbitrary version control system. Based on the source code repository, the application is deployed to testing, staging, and production environments using a CLI either from development machines or contin-uous integration servers throughout the different phases of development.
8. In production, Orestes handles the database and middleware infrastructure to de-liver data consumed and displayed in the frontend with minimal latency while trans-parently scaling with data volume and request load.
9. If new applications based on the same data are created, they can share and reuse the backend side using the same REST interface without compromising performance.
While any application could also be developed through the explicit use of disparate database and cloud storage technologies, we believe that a common API and middle-ware for database systems is a promising way to solve critical non-functional and func-tional problems across many systems. Thus, development efforts can be focused on the application-specific problems, while generic components are already available.
HTTP Performance Evaluation
In Chapter 4, we will provide in-depth evaluations of the performance and latency im-provements obtained through Orestes. To give a first quantitative impression on the po-tential effects and the overhead of Orestes, we present results for experiments on the REST/HTTP layer in the following. Figure 3.12 compares the performance of Orestes to that of a database-specific access protocol9.
50 100 150 200 250
300 / 1 300 / 2 300 / 3 3000 / 1 3000 / 2 3000 / 3 30000 / 1 30000 / 2 30000 / 3
Time [s]
VOD native Orestes
Setup [#objects/run]
(a) Performance of Orestes compared to VOD for 300/3 000/30 000 total database objects over 3 runs.
50 100 150
1 2 3
Time [s]
Run
Squid 2 Squid 3 Squid 3 patched
Microsoft TMG No cache VOD
(b) Performance for different web caches and Orestes with and without caching.
Figure 3.12: Evaluation of the Orestes REST/HTTP layer in a micro-benchmark compared to native database access.
In the experiments, 50 client machines connected to an Orestes server with a Versant Ob-ject Database (VOD) are separated by a network latency of165 ms±2 msusing the Amazon EC2 regions Ireland and California. Web Caching is performed through a forward-proxy cache co-located with the clients. The workload that is concurrently executed by all clients
9The detailed results are published in [GBR14].
is a micro-benchmark modeled after a social networking scenario (500 operations per sec-ond, 90% reads, 10% writes, navigational access with sporadic queries and transactions).
There were three consecutive runs for different sizes of the database comparing Orestes exposing VOD against VOD with its binary TCP protocol.
Figure 3.12a shows that the average execution time of the test is heavily reduced with Orestes. The performance improvements are not only a consequence of the applied web caching. The ability of the Orestes unified interface to combine different operations in a single round-trip, makes network communication significantly more effective in high-latency environments. For example, by batching a transaction commit into a single HTTP request, multiple round-trips can be saved.
Figure 3.12b reports the results of the same micro-benchmark for a setup of hardware machines using a single client, different caches (both in Hamburg) accessing Orestes/VOD (California). The results show that the large performance advantage is consistent across different web caches. This is a consequence of Orestes relying on standard HTTP caching.
Furthermore, the experiments also show that Orestes without any caching is competitive to custom database protocols. For detailed results in this setting, we refer to [GBR14] as well as the evaluations discussed in Chapter 4.
Due to the low overhead and efficient communication of updates in Orestes, even without any caching, the overall performance of Orestes is roughly 30% better compared to VOD’s native protocol. Thus, the overall performance of REST/HTTP as the only interface of Orestes, does not impose a substantial overhead. Any latency optimization achieved by Orestes therefore directly improves performance over native database protocols.