GridDB Programming Tutorial

A PV site is a plant equiped with (normally thousands to hundreds of thousands of) solar panels, which collects power generated by each panel and transmits it to the power grid. For the convenience of control, panels are grouped into strings or arrays, each consisting of multiple panels. Electric power generated by the panels is collected via facilities, such as a concentrator (CC), a power conditioning subsystem (PCS) and a gateway (GW), and transmitted to the power grid. Each facility is equipped with various sensors to monitor the condition of power generation.

The PV site monitoring system is a system for monitoring the condition of power generation and detecting abnormalities on a PV site. The schematic view below shows a system configuration.

• Electric power generated at the PV site is transmitted from GW to power consumers through the power grid.The PV site measures the conditions of facilities during generating power using various sensors.
• The information on the conditions of facilities measured at the PV site is transmitted from GW to the monitoring server center through the Internet.The monitoring server center accumulates the received various information on the conditions of facilities in a database.At the same time, the PV site determines whether each sensor value is normal or abnormal. If it is determined as abnormal, an alert is sent to the monitoring server center.The configuration and specifications of the PV site's facilities are stored in a database beforehand.In this example, each panel is equipped with a voltmeter, an ammeter, and a wattmeter for measuring the condition of itself.
• A montoring client monitors the PV site for abnormalities, referencing alert information stored in a database in the monitoring server center.

This example shows simplified PV site monitoring capabilities using GridDB as a database, as follows:

• To read in the information on facility conditions and alerts collectively from a CSV file and store the information in a database beforehand by a simplified storing function.
• To search for an alert showing serious abnormality among an alert history within the previous 24 hours and display the information of a facility causing an abnormality and the sensor values around the occurrence of abnormality by a simplified abnormality detection function.

The following data resources are used in the example.

• Facility information
  • Describes the information defined for each facility, consiting of an ID and a name assigned for each facility and its specifications.
• Sensor information
  • Describes the correspondence relation between a facility and a sensor, consisting of a name and a type for each sensor and an ID of a facility to be measured.
• Sensor history information
  • Describes a value measured at a certain time, consisting of a date and time of measurement, a measured value, and status information.
• Alert history information
  • Describes detected alerts, consisting of an alert ID, a date and time of alert, an ID of a sensor detecting an alert, an alert level, and alert detail information.

GridDB creates a data storage collectively called Container (corresponding to a table of RDB) for data management. Basically, a Container stores KV data, including not only simple KV-formatted data, but also original schema definitions. There are two types of Containers:

• Collection for general KV data management
• TimeSeries for time-series data management

A schema of a Container (Collection/TimeSeries) is defined as shown below.

• Define a schema as a class in a client program.
• Be sure to specify either one of member variables in a class as a line key.A line key is used as a key of KVS, which must be unique in a single Container.Add "@RowKey" to specify a line key in class definitions.
• A value of KVS can be multiple member variables, and has no restriction on its type.Accordingly, it can be defined like a normal structure.

TimeSeries has the following restriction and characteristic because of the purpose of time-series data management.

• Only a date and time can be specified as a line key.
• Time-series data can be compressed and interpolated.

GridDB manages transactions for each Container. Therefore, no problem occurs in transactions referencing a single Container; however, there are restrictions on transactions referencing more than one Container, as follows:

• Inconsistent data during update can be referenced by another transaction; therefore, consistency is not strictly guaranteed.
• Transactions are committed individually, and so rollback cannot be done easily; therefore, atomicity is also not guaranteed.

You need to use GridDB for a limited purpose and take necessary actions even if inconsistency is acceptable.

• Do not use GridDB for a critical purpose, such as for an accunting system.
• Implement error checking, such as checking for existence of data, and retrying a check if an error occurs, in order to guarantee consistency.

GridDB provides simple KV-type search with a given key. You can use a dedicated query language TQL for search with more complicated conditions. TQL is a subset of SQL, a query language of RDB, which has the following limitations.

• Supports only SELECT statements which select data for search or update, limited to the syntax shown below.
• Does not accept other than SELECT statemtents, such as manipulation or update of selected data.
• Fetching of all Columns (*) and aggregate operations (e.g., SUM) are available for a select expression. (Fetching of a particular Column is not available.)
• Segments not covered by the syntax below, such as ORDER BY, are not available.

SELECT (select expression) [FROM (Collection name or TimeSeries name)] [WHERE (conditional expression)]

However, GridDB provides original advanced search functions to search for time-series data and spatial data for social infrastracture use.

See "GridDB User's Manual" for more information on TQL.

GridDB can create indexes for each Column of a Row, so as to provide fast search when specifying not only a key condition for KV, but also a condition about values, such as value comparison and a range condition. Accordingly, you can define schemas like those of RDA without having to work out implementation focusing on search with a key condition.

The following types are available for indexing.

• String type
• Integer type
• Floating point type
• Time type
• 2D type

GridDB provides complicated advanced search using a dedicated query language TQL. In complicated search with a combination of multiple conditions, however, search performance would decline because of multiple accesses to Container(s). In order to speed up search, it is effective to analyze search patterns of an application and deliberately design key coding. For example, for the case of search with multiple conditions combined by AND to fetch a pinpoint record, you can use single key search by incorporating key coding related to particular AND conditions. You can reduce the number of accesses to Container(s) to speed up search. Below you can see an example of searching for a Row of a sensor "voltage" of a facility "panel001."

Without any particular key coding, a query as shown below is used when searching for a Row with "'panel001' as a facility ID" and "'voltage' as a sensor type" from a sensor information Collection (Sensor_col) in which sequential positive numbers are assigned to sensor IDs (e.g., 1, 2, 3, …).

select * from Sensor_col
where equipId = "panel001" AND sensorType = "voltage"

On the other hand, a query as shown below is available when searching for a Row with "'panel001_voltage' as a sensor ID" from a sensor information Collection (Sensor_col) incorporating key coding to make a sensor ID by concatenating a facility ID and a sensor ID (e.g., panel001_volatage).

select * from Sensor_col
where sensorId = "panel001_voltage"

GridDB can be composed of multiple nodes, so as to increase storage capacity and improve throughput by scaling out. To do this, a set of Rows need to be divided into multiple sets and distributively stored in multiple Collections. You need to design your application to divide a set of Rows (costruct a Collection) because GridDB does not have automated tooling. Granularity of Collection division should be properly designed in the cases below.

• Divide a huge size of Collection exceeding the real memory size of a computer into multiple small size of Collections for management.
• Prepare a TimeSeries for each tag/sensor to manage time-series data for each tag/sensor.
• Divide a highly frequently referenced Collection into multiple Collections for load distribution.

GridDB manages Rows written in memory; so you can reduce the cost of creating and referencing Rows (memory) and speed up processing by designing proper granularity of Rows in consideration of the performance balance of your application. Additionally, since GridDB does not support JOIN, you have to take time and effort to implement comparable logic in your application. Therefore, it is advisable to design schema implementation so as to avoid use of JOIN in consideration of the performance balance of your application. You should define schemas so as to attain proper granularity of Rows in the cases below.

• If JOIN is frequently used in an application, adopt schema definitions in a form of cartesian product in consideration of data size and storage performance balance.
• In order to speed up referencing particular Columns, separate such Columns to define separate schemas for each, so as to reduce I/O.
• If particular partial Columns are highly frequently updated, separate such Columns to define separate schemas for each, so as to minimize a memory copy.

For data management using GridDB, the following should be considered in schema designing.

• In order to avoid complicated search and speed up processing, properly design key coding rules and use key search only.
• In order to avoid JOIN operations and speed up processing, store data based on the schemas in a form of cartesian product without normalization purposely.
• In order to conduct search with a value condition, index a Column to be specified in a condition.
• In order to improve the performance of scaling out time-series data, create a TimeSeries for each sensor and store each data in it.
• In order to prevent inconsistency in update transactions, put concurrently updated Columns into one Collection, if possible.

Facility information, sensor data history information, and alert hystory information are separately stored in Collections and TimeSeries below, respectively.

Structure of Collection

Data	Quantity	Container name
Facility information	One Collection	equipment_col
Sensor history information	One TimeSeries per sensor	Sensor ID assigned (Example: panel001_voltage)
Alert history information	One Collection	alert_col

And, by preparing a sensor ID naming rule as below, relationship between facilities and sensors can be expressed without using sensor information data.

• Concatenate a facility ID and a sensor type with "_" to make a sensor ID (a form of "facility ID"_"sensor type").
  • Example : panel001_voltage

Facility information, sensor data history information, and alert history information are defined based on the schema shown below.

// Facility information
class Equip {
    @RowKey String  id; // Facility ID
    String      name;   // Facility name
    Blob        spec;   // Specification information
}

// Sensor history
class Point {
    @RowKey Date  time; // Date and time
    double    value;    // Sensor value
    String    status;   // Sensor status
}

// Alert history
class Alert {
    @RowKey int id;     // Alert ID
    Date      timestamp;//  Date and time
    String    sensorId; // Sensor ID
    int       level;    // Alert level
    String    detail;   // Alert detail information
}

• The facility information Collection is a Collection storing the information on each facility.It has a schema defined by "class Equip" shown above and stores a facility ID, a facility name and facility specifications for each record.
• The sensor history consists of a set of TimeSeries for each sensor.Each TimeSeries has a schema defined by "class Point" shown above and stores a date and time of measurement, a measured value, and status information for each record.
• The alert history Collection is a Collection storing alert information detected by a sensor.It has a schema defined by "class Alert" shown above and stores an alert ID, a date and time of alert, an ID of a sensor detecting an alert, an alert level, and alert detail information.

A flow of storing data in a Collection is shown below.

First, if there is no Collection to store data in, newly create a Collection following the procedure below:

1. Get a GridStore instance.
2. Create a Collection.

You can store data in an existing Collection by the following procedure:

1. Get a GridStore instance.
2. Get a Collection.
3. Set operation parameters.
4. Create indexes.
5. Create values to be stored.
6. Store values in the Collection.
7. Perform a commit at proper intervals.
8. Release the GridStore instance.

You can also store data in a TimeSeries by the same procedure as above for a Collection.

A flow of Collection data search is shown below:

1. Get a GridStore instance.
2. Get a Collection.
3. Search a Collection.
4. Get search results.
5. Release the GridStore instance.

The following two search methods are available. See "GridDB User's Manual" for more information on the methods.

1. Method of searching with specification of a key of KV (get)
2. Method of searching with a condition specifying a value of KV (query)

You can also search TimeSeries data by the same procedure as above for Collection data.

Technically, in the monitoring system, the information on facility configuration and specifications needs to be stored in a database. For simplicity, however, this section shows a sample program which loads facility information except facility specifications collectively from a CSV file storing the data. An outline of a processing flow is shown below.

1. Connect to a server and get a GridStore instance.
2. Create a facility information Collection Collection name with a specified name ("equipment_col") in GridStore and get it.
3. Create indexes to be used for search.
4. Store a value repeatedly while reading a CSV file, as follows:
   • 4-1. Analyze a read CSV-formatted line and create a facility information object to store.
   • 4-2. Store (put) the created facility information object in the facility information Collection.
   • 4-3. Perform a commit if repeated the predetermined number of times.
5. Release the GridStore instance if all CSV-formatted lines are processed.

A concrete sample program is shown below:

  1:  package pvrms;
  2:  
  3:  import java.io.FileReader;
  4:  import java.io.IOException;
  5:  import java.text.ParseException;
  6:  import java.util.Properties;
  7:  
  8:  import au.com.bytecode.opencsv.CSVReader;
  9:  
 10:  import com.toshiba.mwcloud.gs.Collection;
 11:  import com.toshiba.mwcloud.gs.GSException;
 12:  import com.toshiba.mwcloud.gs.GridStore;
 13:  import com.toshiba.mwcloud.gs.GridStoreFactory;
 14:  import com.toshiba.mwcloud.gs.RowKey;
 15:  
 16:  // Facility information
 17:  class Equip {
 18:      @RowKey String id;
 19:      String   name;
 20:      //Blob     spec; // For simplicity, spec information is not used.
 21:  }
 22:  
 23:  public class SimplePv0 {
 24:  
 25:      /*
 26:       * Load facility information from a CSV file.
 27:       */
 28:      public static void main(String[] args) throws GSException, ParseException, IOException {
 29:  
 30:          // Specify a server.
 31:          final String gsServer     = "127.0.0.1";
 32:          final String gsPort       = "10001";
 33:          final String user         = "admin";
 34:          final String password     = "admin";
 35:  
 36:          final String equipColName = "equipment_col";
 37:  
 38:          // Get a GridStore instance.
 39:          final Properties prop = new Properties();
 40:          prop.setProperty("host", gsServer);
 41:          prop.setProperty("port", gsPort);
 42:          prop.setProperty("user", user);
 43:          prop.setProperty("password", password);
 44:          final GridStore store = GridStoreFactory.getInstance().getGridStore(prop);
 45:  
 46:  
 47:          // Read a CSV file.
 48:          String dataFileName = "equipName.csv";
 49:          CSVReader reader = new CSVReader(new FileReader(dataFileName));
 50:          String[] nextLine;
 51:  
 52:          /*
 53:           *  Create a Collection.
 54:           */
 55:          Collection<String,Equip> equipCol = store.putCollection(equipColName, Equip.class);
 56:  
 57:          /*
 58:           *  Create indexes for Columns.
 59:           */
 60:          equipCol.createIndex("id");
 61:          equipCol.createIndex("name");
 62:  
 63:          /*
 64:           *  Set autocommit mde to OFF.
 65:           */
 66:          equipCol.setAutoCommit(false);
 67:  
 68:          // Commit interval
 69:          Long commtInterval = (long) 1;
 70:  
 71:          /*
 72:           *  Store a value.
 73:           */
 74:          Equip equip = new Equip();
 75:          Long cnt = (long) 0;
 76:          byte[] b = new byte[1];
 77:          b[0] = 1;
 78:          while ((nextLine = reader.readNext()) != null) {
 79:  
 80:              // Store facility information.
 81:              equip.id   = nextLine[2];
 82:              equip.name   = nextLine[3];
 83:              
 84:              equipCol.put(equip);
 85:              
 86:              cnt++;
 87:              
 88:              if(0 == cnt%commtInterval) {
 89:                  // Commit a transaction.
 90:                  equipCol.commit();
 91:              }
 92:  
 93:          }
 94:  
 95:          // Release a resource
 96:          store.close();
 97:          reader.close();
 98:  
 99:  }
100:  
101:  }

Technically, in the monitoring system, a sensor or a facility directly sends an alerm to and store it in GridDB. For simplicity, however, this section shows a sample program which loads alerm history data collectively from a CSV file storing the data. An outline of a processing flow is shown below.

1. Connect to a server and get a GridStore instance.
2. Create an alert Collection with a specified name ("alert_col") in GridStore and get it.
3. Create indexes to be used for search.
4. Store a value repeatedly while reading a CSV file, as follows:
   • 4-1. Analyze a read CSV-formatted line and create an alert object to store.
   • 4-2. Store (put) the created alert object in the alert Collection.
   • 4-3. Perform a commit if repeated the predetermined number of times.
5. Release the GridStore instance if all CSV-formatted lines are processed.

A concrete sample program is shown below:

  1:  package pvrms;
  2:  
  3:  import java.io.FileReader;
  4:  import java.io.IOException;
  5:  import java.text.ParseException;
  6:  import java.text.SimpleDateFormat;
  7:  import java.util.Date;
  8:  import java.util.Properties;
  9:  
 10:  import au.com.bytecode.opencsv.CSVReader;
 11:  
 12:  import com.toshiba.mwcloud.gs.Collection;
 13:  import com.toshiba.mwcloud.gs.GSException;
 14:  import com.toshiba.mwcloud.gs.GridStore;
 15:  import com.toshiba.mwcloud.gs.GridStoreFactory;
 16:  import com.toshiba.mwcloud.gs.RowKey;
 17:  
 18:  // Alert information
 19:  class Alert {
 20:      @RowKey Long id;
 21:      Date    timestamp;
 22:      String  sensorId;
 23:      int     level;
 24:      String  detail;
 25:  }
 26:  
 27:  public class SimplePv1 {
 28:  
 29:      /*
 30:       * Load alert data from a CSV file.
 31:       */
 32:      public static void main(String[] args) throws GSException, ParseException, IOException {
 33:  
 34:          // Specify a server.
 35:          final String gsServer     = "127.0.0.1";
 36:          final String gsPort       = "10001";
 37:          final String user         = "admin";
 38:          final String password     = "admin";
 39:  
 40:          final String alertColName = "alert_col";
 41:  
 42:          // Get a GridStore instance.
 43:          final Properties prop = new Properties();
 44:          prop.setProperty("host", gsServer);
 45:          prop.setProperty("port", gsPort);
 46:          prop.setProperty("user", user);
 47:          prop.setProperty("password", password);
 48:          final GridStore store = GridStoreFactory.getInstance().getGridStore(prop);
 49:  
 50:          // Read a CSV file.
 51:          String dataFileName = "alarmHistory.csv";
 52:          CSVReader reader = new CSVReader(new FileReader(dataFileName));
 53:          String[] nextLine;
 54:  
 55:          /*
 56:           *  Create a Collection.
 57:           */
 58:          Collection<Long,Alert> alertCol = store.putCollection(alertColName, Alert.class);
 59:  
 60:          /*
 61:           *  Create indexes for Columns.
 62:           */
 63:          alertCol.createIndex("timestamp");
 64:          alertCol.createIndex("level");
 65:  
 66:          /*
 67:           *  Set autocommit mde to OFF.
 68:           */
 69:          alertCol.setAutoCommit(false);
 70:  
 71:          // Commit interval
 72:          Long commtInterval = (long) 1;
 73:  
 74:          /*
 75:           *  Store a value.
 76:           */
 77:          SimpleDateFormat format = new SimpleDateFormat("yyyy/MM/ddHH:mm:ss");
 78:          Alert alert = new Alert();
 79:          Long cnt = (long) 0;
 80:          while ((nextLine = reader.readNext()) != null) {
 81:  
 82:              String dateS     = nextLine[0];//2011/1/1
 83:              String timeS     = nextLine[1];//19 (hundred hours)
 84:              String datetimeS = dateS + " " + timeS + ":00:00";
 85:              Date   date      = format.parse(datetimeS);
 86:              Long   datetime  = date.getTime();
 87:  
 88:              alert.id         = ++cnt;
 89:              alert.timestamp  = new Date(datetime);
 90:              alert.sensorId   = nextLine[2];
 91:              alert.level      = Integer.valueOf(nextLine[3]);
 92:              alert.detail     = nextLine[4];
 93:  
 94:              alertCol.put(alert);
 95:  
 96:              if(0 == cnt%commtInterval) {
 97:                  // Commit a transaction.
 98:                  alertCol.commit();
 99:              }
100:  
101:          }
102:  
103:          // Release a resource.
104:          store.close();
105:          reader.close();
106:  
107:  }
108:  
109:  }

Technically, in the monitoring system, a sensor directly sends a measured value to be stored in GridStore. For simplicity, however, this section shows a sample program which loads sensor data collectively from a CSV file storing the data. An outline of a processing flow is shown below.

1. Connect to a server and get a GridStore instance.
2. Read the first line of a CSV file and create a set of TimeSeries to be used beforehand, as follows:
   • 2-1. Analyze the first CSV-formatted line and obtain multiple sensor IDs (= the names of TimeSeries to be created).
   • 2-2. Create an alert Collection in GridStore for each obtained sensor ID.
3. Store a value repeatedly, while reading the rest of the CSV file, as follows:
   • 3-1. Analyze a read CSV-formatted file and create a Point object to store.
   • 3-2. Store (put) the created Point object in an appropriate TimeSeries.
4. Release the GridStore instance if all CSV-formatted lines are processed.

A concrete sample program is shown below:

 1:  package pvrms;
 2:  
 3:  import java.io.FileReader;
 4:  import java.io.IOException;
 5:  import java.text.ParseException;
 6:  import java.text.SimpleDateFormat;
 7:  import java.util.Date;
 8:  import java.util.Properties;
 9:  
10:  import au.com.bytecode.opencsv.CSVReader;
11:  
12:  import com.toshiba.mwcloud.gs.GridStore;
13:  import com.toshiba.mwcloud.gs.GridStoreFactory;
14:  import com.toshiba.mwcloud.gs.RowKey;
15:  import com.toshiba.mwcloud.gs.TimeSeries;
16:  
17:  // Sensor data
18:  class Point {
19:      @RowKey Date time;
20:      double  value;
21:      String  status;
22:  }
23:  
24:  public class SimplePv2 {
25:  
26:      /*
27:       * Load time-series data form a CSV file.
28:       */
29:      public static void main(String[] args) throws ParseException, IOException {
30:  
31:          // Specify a server.
32:          final String gsServer     = "127.0.0.1";
33:          final String gsPort       = "10001";
34:          final String user         = "admin";
35:          final String password     = "admin";
36:  
37:          // Get a GridStore instance.
38:          final Properties prop = new Properties();
39:          prop.setProperty("host", gsServer);
40:          prop.setProperty("port", gsPort);
41:          prop.setProperty("user", user);
42:          prop.setProperty("password", password);
43:          final GridStore store = GridStoreFactory.getInstance().getGridStore(prop);
44:  
45:          // Read a CSV file.
46:          String dataFileName = "sensorHistory.csv";
47:          CSVReader reader = new CSVReader(new FileReader(dataFileName));
48:          String[] nextLine;
49:          nextLine = reader.readNext();
50:  
51:  
52:          // Presupposing that the 1st line contains sensor IDs and the rest of lines contain data.
53:          // Presupposing that 0:date, 1:time, ...
54:  
55:  
56:          /*
57:           *  Read a sensor ID and create a TimeSeries.
58:           */
59:          String[] tsNameArray = new String[nextLine.length];
60:          for(int j = 2; j < nextLine.length; j++) {
61:  
62:              tsNameArray[j] = nextLine[j];
63:              store.putTimeSeries(tsNameArray[j], Point.class);
64:  
65:          }
66:  
67:          /*
68:           *  Store a value in each TimeSeries.
69:           */
70:          SimpleDateFormat format = new SimpleDateFormat("yyyy/MM/ddHH:mm:ss");
71:          Point point             = new Point();
72:          while ((nextLine = reader.readNext()) != null) {
73:  
74:              String dateS     = nextLine[0];//2011/1/1
75:              String timeS     = nextLine[1];//19 (hundred hours)
76:              String datetimeS = dateS + " " + timeS + ":00:00";
77:              Date   date      = format.parse(datetimeS);
78:              Long   datetime  = date.getTime();
79:  
80:              for(int i = 2, j = 2; j < nextLine.length; i++, j+=2) {
81:  
82:                  TimeSeries<Point> ts = store.getTimeSeries(tsNameArray[i], Point.class);
83:  
84:                  point.time   = new Date(datetime);
85:                  point.value  = Double.valueOf(nextLine[j]);
86:                  point.status = nextLine[j+1];
87:  
88:                  ts.append(point);
89:              }
90:          }
91:          
92:          // Release a resource.
93:          store.close();
94:          reader.close();
95:  
96:  }
97:  
98:  }

This section shows a sample program which simulates monitoring abnormalities (displaying facility information related to a serious alert occuring within 24 hours and time-series data just before the alert), referencing facility information, sensor data and alert data stored in GridDB. An outline of a processing flow is shown below.

1. Connect to a server and get a GridStore instance.
2. Get an alert Collection with a specified name ("alert_col") from the GridStore instance.
3. In order to search the alert Collection for serious alerts (level > 3) occurring within 24 hours, conduct a search with a condition about level and time.Use TQL for search with a condition specifying values.
4. Search for facility information related to a serious alert obtained in search results and time-series data just before the alert, as follows:
   • 4-1. First, obtain a facility ID string from a string of a sensor ID causing a serious alert.
   • 4-2. Next, get a facility information Collection with a specified name ("equipment_col") from the GridStore instance.
   • 4-3. Get facility information from the facility information Collection by specifying the obtained facility ID as a key.
   • 4-4. Then, get a TimeSeries with a name indicating a sensor ID from the GridStore instance.
   • 4-5. Search the obtained TimeSeries for time-series data for ten minutes before the alert.Specify a time range in a search condition.

A concrete sample program is shown below:

 1:  package pvrms;
 2:  
 3:  import java.sql.Blob;
 4:  import java.io.IOException;
 5:  import java.text.ParseException;
 6:  import java.util.Date;
 7:  import java.util.Properties;
 8:  
 9:  import com.toshiba.mwcloud.gs.Collection;
10:  import com.toshiba.mwcloud.gs.GSException;
11:  import com.toshiba.mwcloud.gs.GridStore;
12:  import com.toshiba.mwcloud.gs.GridStoreFactory;
13:  import com.toshiba.mwcloud.gs.Query;
14:  import com.toshiba.mwcloud.gs.RowSet;
15:  import com.toshiba.mwcloud.gs.TimeSeries;
16:  import com.toshiba.mwcloud.gs.TimeUnit;
17:  import com.toshiba.mwcloud.gs.TimestampUtils;
18:  
19:  public class SimplePv3 {
20:  
21:      /*
22:       *  Displays facility information related to serious alerts occurring within 24 hours and time-series data just before each alert.
23:       */
24:      public static void main(String[] args) throws GSException, ParseException, IOException {
25:  
26:          // Specify a server.
27:          final String gsServer     = "127.0.0.1";
28:          final String gsPort       = "10001";
29:          final String user         = "admin";
30:          final String password     = "admin";
31:  
32:          final String alertColName = "alert_col";
33:          final String equipColName = "equipment_col";
34:  
35:          // Get a GridStore instance.
36:          final Properties prop = new Properties();
37:          prop.setProperty("host", gsServer);
38:          prop.setProperty("port", gsPort);
39:          prop.setProperty("user", user);
40:          prop.setProperty("password", password);
41:          final GridStore store = GridStoreFactory.getInstance().getGridStore(prop);
42:  
43:          /*
44:           *  Search for serious alerts (level > 3) within 24 hours.
45:           */
46:          Collection<Long,Alert> alertCol = store.getCollection(alertColName, Alert.class);
47:          Long now = System.currentTimeMillis();
48:          String from =    TimestampUtils.format(TimestampUtils.add(new Date(now), -24, TimeUnit.HOUR));
49:          Query<Alert> alertQuery = alertCol.query("select * where level > 3 and " +
50:                                                   "timestamp > " + "TIMESTAMP('" + from + "')");
51:          RowSet<Alert> alertRs = alertQuery.fetch();
52:  
53:          /*
54:           *  Display facility information related to a sensor occurring a serious alert and time-series data just before the alert.
55:           */
56:          while(alertRs.hasNext()) {
57:  
58:              Alert seriousAlert = alertRs.next();
59:  
60:              /*
61:               *  Obtain a facility ID and a sensor type.
62:               */
63:              String equipId = seriousAlert.sensorId;
64:              String sensorType = seriousAlert.sensorId;
65:  
66:              /*
67:               *  Obtain facility information.
68:               */
69:              Collection<String,Equip> equipCol = store.getCollection(equipColName, Equip.class);
70:              Equip equip = equipCol.get(equipId);
71:              
72:              System.out.println("[Equipment] " + equip.name  + " (sensor) "+ sensorType);
73:              System.out.println("[Detail] " + seriousAlert.detail);
74:  
75:              /*
76:               *  Search for time-series data just before the alert.
77:               */
78:              String tsName = seriousAlert.sensorId;
79:              TimeSeries<Point> ts = store.getTimeSeries(tsName, Point.class);
80:  
81:              Date endDate   = seriousAlert.timestamp;
82:              Date startDate = TimestampUtils.add(seriousAlert.timestamp, -10, TimeUnit.MINUTE);
83:              RowSet<Point> rowSet =  ts.query(startDate, endDate).fetch();
84:  
85:              while (rowSet.hasNext()) {
86:                  Point ret = rowSet.next();
87:                  System.out.println(
88:                          "[Result] " + TimestampUtils.format(ret.time) +
89:                          " " + ret.value + " " + ret.status);
90:              }
91:  
92:          }
93:  
94:          // Release a resource.
95:          store.close();
96:  
97:  }
98:  
99:  }