Data Store API

Facebook also has implemented an API for basic database manipulations with its Data Store API. This API provides a basic create, read, update, and delete (CRUD) API for storing data that you access through REST. If you’re unfamiliar with object-oriented database management systems (OODMSs), some of the terminology is a bit different from that for relational database management systems (RDBMSs). For instance, to use the Data Store API, you must define your schema (your database), which consists of object types (tables) and properties (columns).

One of the really nice features of the Facebook Data Store API is that Facebook does not plan to charge for normal use! You basically have use of Facebook’s servers to perform your database manipulations for you. However, it’s probably not quite time to get rid of your RDBMS yet, because there aren’t any structured queries, full-text search, or transaction-level query processing in the Facebook Data Store API.

Note:
Data Store API may be in beta stage. Please consult the wiki documentation for the latest information before you deploy any projects using the Data Store API.

The Data Store API consists of three basic functions: specialized tables, distributed tables, and associations that are split into five separate APIs (User Preference, Object Data Definition, Object Data Access, Association Data Definition, and Association Data Access). Since Facebook provides access to millions of users, the tables (objects) you create are distributed. Facebook does provide a specialized table of users that is optimized (if you find that you really need more, let the Facebook developers know at their Bugzilla site, http://bugs.developers.facebook.com/). The associations component of this API is a mechanism to provide performance for fast lookups (such as indexes). Because indexing tables in a distributed environment won’t necessarily provide a performance boost, this mechanism has been implemented to provide fast lookups without centralized indexes or parallel queries.

The user preferences for the API consist of 128-character strings, for which you can store up to 201 for each user (numbered 0–200). Access to the getters/setters are accessed through getters and setters in the REST API (facebook.data.setUserPreference and facebook.data.getUserPreferences).

Data objects (that is, tables) are created with facebook.createObjectType. The object type takes a name and contains a set of object properties (that is, columns). Object properties have names and data types. You don’t quite have the same type of control over the data types with the API as you do with your own RDBMS because you are limited to integers, strings (less than 256 characters), and text blobs (with a maximum of 64KB).

After defining your objects and object types, you create, read, update, and delete through the Object Data Access API. These are rather straightforward (facebook.data.createObject, and so on).

To work with the associations between objects, you first need to define the relationship between objects in the facebook.defineAssociation call. You can define two types of associations: one-way, symmetric associations and asymmetric associations. If you’re familiar with RDBMS joins, think of an asymmetric association as a many-to-many join and a symmetric association as a one-to-many join. One-way associations are an association between objects that can happen only one way (in other words, there’s no need to look up a value by some ID) for a given object. You then create the actual associations with the Association Data Access API. These methods allow you to create, remove, and retrieve these associations and retrieve the object details from the data contained in the data definition.

This can be confusing at first, so let’s look at an example:

<?php

$createObject = $facebook->api_client->data_createObjectType("wallpost");

$uid = $facebook->api_client->data_defineObjectProperty("wallpost", "uid", 1);

$time = $facebook->api_client->data_defineObjectProperty("wallpost", "timePosted",2);

$post = $facebook->api_client->data_defineObjectProperty("wallpost", "post", 3);

?>

The previous snippet of code is analogous to the following SQL DDL:

CREATE TABLE wallpost(

uid integer,

timePosted timestamp,

post text

)

As you can see in this simple example, this can take a little bit to get used to because you’re not performing your typical SQL DDL; however, once you get your mind around how to create the objects, it’s relatively trivial to use the API as the persistence layer for your application. I suspect that this API will eventually make it out of beta and be quite a powerful tool in the Facebook developer’s toolbox, at least for those who choose to have Facebook manage their data.