No Query Language Needed: Using Python with an Ordered Key-Value Store by Stephen Pimentel.
From the post:
FoundationDB is a complex and powerful database, designed to handle sharding, replication, network hiccups, and server failures gracefully and automatically. However, when we designed our Python API, we wanted most of that complexity to be hidden from the developer. By utilizing familiar features- such as generators, itertools, and comprehensions-we tried to make FoundationDB’s API as easy to us as a Python dictionary.
In the video below, I show how FoundationDB lets you query data directly using Python language features, rather than a separate query language.
…
Most applications have back-end data stores that developers need to query. This talk presents an approach to storing and querying data that directly employs Python language features. Using the Key-Value Store, we can make our data persistent with an interface similar to a Python dictionary. Python then gives us a number of tools “out of the box” that we can use to form queries:
- generators for memory-efficient data retrieval;
- itertools to filter and group data;
- comprehensions to assemble the query results.
Taken together, these features give us a query capability using straight Python. The talk walks through a number of example queries using the Enron email dataset.
https://github.com/stephenpiment/object-store For code and the details.
More motivation to take a look at FoundationDB!
I do wonder about the “no query language needed.” Users, despite their poor results, appear to be committed to querying and query languages.
Whether it is the illusion of “empowerment” of users, the current inability to measure the cost of ineffectual searching, or acceptance of poor search results, search and search operators continue to be the preferred means of interaction. Plan accordingly.
I first saw this in a tweet by Hari Kishan.
Stephen with FoundationDB here. On the “no query language needed” aspect, we certainly recognize that there are users who desire – and applications that require – a declarative query language. For example, we offer a SQL Layer* that maps full ANSI SQL down to the Key-Value Store. It’s a great option, if you know that you want or need SQL. We also intend to offer further query languages for NoSQL data models (documents, etc.).
* https://foundationdb.com/layers/sql
The point of my talk is to alert developers to an additional option, that of using the Key-Value Store directly. Our API is sufficiently powerful that, combined with flexibility of Python, it can be used “out of the box” to cover a broad range of use cases.
Stephen Pimentel
FoundationDB
https://foundationdb.com
Comment by stephenpiment — October 18, 2014 @ 9:33 am
Stephen, I may have worded it inartfully but my point was that for adoption purposes, applications built on top of FoundationDB should consider having a declarative query language.
Personally I consider the flexibility of FoundationDB both in terms of data structures and query languages to be an advantage. No criticism was intended, just a warning to developers who think they can improve on SQL and that users will readily fall in line. Not my experience.
Comment by Patrick Durusau — October 18, 2014 @ 10:49 am