Skip to content
Michael Mior edited this page Mar 26, 2018 · 2 revisions

Input to NoSE consists of two components: the model and the workload. For the examples distributed with NoSE, these two components are stored in separate files. For example, the RUBiS workload references the RUBiS model with the line Model 'rubis'. This is to allow multiple workloads to reuse the same model. Currently, if you want to supply your own input to NoSE, the workload and the model must be given in the same file. An example is given below.

NoSE::Workload.new do
  # Model
  NoSE::Model.new do
    (Entity 'items' do
      ID     'ItemID'
      String 'Title', 50
      String 'Desc', 200
    end) * 1_000

    (Entity 'likes' do
      ID         'LikeID'
      Date       'LikedAt'
    end) * 10_000

    HasOne 'item',    'likes',
           'likes' => 'items'
  end

  # Workload
  Q 'SELECT items.* FROM items WHERE items.ItemID = ?', 0.9
  Q 'INSERT INTO items SET ItemID = ?, Title = ?, Desc = ?', 0.1
end

Model

The example includes an excerpt from the provided eBay model. There are three things to note here: entities, fields and relationships. The model above defines two entities, items and likes. Within each item are several fields. Fields have a type and a name (and for string fields, an optional expected length). The multiplication after the entity definitions defines the expected number of each entity. In this case, the model suggests that there will be 1,000 items and 10,000 likes. Note that these values are relative so they simply define a ration between entities.

Below the entities are relationship definitions. Currently the only relationship defined is HasOne. This represents a one-to-many or relationship. HasOne has four parameters, the first two are names for each side of the relationship. The third specifies the entities the relationship is between. In the model above, the relationship specifies that one item has many likes.

Workload

The workload example contains a single query and a single update. Both queries and updates are defined using the Q function and the format of each is similar to SQL. However, instead of referencing tables and columns, entitites and fields are used. The number given after each query or update is the expected frequency in the application workload.

TODO: Add example of traversing relationships

Workload groups and mixes

TODO

Clone this wiki locally