CountTableRows
Support Programs
Oracle NoSQL Database provides a separate distribution in Oracle Technology Network consisting of example programs and utility classes that you can use to explore various aspects of interacting with an Oracle NoSQL Database system. With respect to exploring the integration of Oracle NoSQL Database with MapReduce, in addition to providing the CountTableRows
example program presented in this document, the Oracle NoSQL Database examples also provide the LoadTableVehicle
program that you can use to create and populate an example table in the store you deploy.
The sections below describe the LoadVehicleTable
program; including the schema employed when creating the table, as well as how to compile and execute the program.
Schema for the vehicleTable
Example
To execute the CountTableRows
MapReduce job, a table named vehicleTable
having the schema shown in the table below must be created in the Oracle NoSQL Database store deployed for this example. The data types specified in the schema shown below are defined by the Oracle NoSQL Database Table API (see oracle.kv.table.FieldDef.Type
) .
Table 4-1 Schema for vehicleTable
Field Name | Field Type | Primary Key | Shard Key |
---|---|---|---|
type | FieldDef.Type.STRING | Y | Y |
make | FieldDef.Type.STRING | Y | Y |
model | FieldDef.Type.STRING | Y | Y |
class | FieldDef.Type.STRING | Y | |
color | FieldDef.Type.STRING | ||
price | FieldDef.Type.DOUBLE | ||
count | FieldDef.Type.INTEGER | ||
dealerid | FieldDef.Type.NUMBER | ||
delivered | FieldDef.Type.TIMESTAMP |
The example vehicleTable
consists of rows representing a particular vehicle a dealer might have in stock for purchase. Each such row contains fields specifying the "type" of vehicle (for example, car, truck, SUV, etc.), the "make" of the vehicle (Ford, GM, Chrysler, etc.), the "model" (Explorer, Camaro, Lebaron, etc.), the vehicle "class" (4WheelDrive, FrontWheelDrive, etc.), the "color" and "price" of the vehicle, the number of vehicles currently in stock (the "count") having those characteristics, a number that uniquely identifies the dealership selling those vehicles (the "dealerid"), and finally, the date and time those vehicles were "delivered" to the dealership.
Although you can enter individual commands in the store's admin CLI to create a table with the above schema, the preferred approach is to employ the Table Data Definition Language (DDL) to create the desired table. One way to accomplish this is to follow the instructions presented in the next sections to compile and execute the LoadVehicleTable
program, which will populate the desired table after using the DDL to create it.
Create and Populate vehicleTable
with Example Data
Assuming an Oracle NoSQL Database store (secure or non-secure) has been deployed with KVHOME
equal to /opt/oracle/kv-ee
, the LoadVehicleTable
program that is supplied as a convenience with the CountTableRows
example can be executed to create and populate the table named vehicleTable
. Before executing LoadVehicleTable
though, that program must first be compiled. To do this, assuming you have installed the example distribution under the base directory /opt/oracle/nosql/apps/kv/examples
, type the following from your client node’s OS command line:
cd /opt/oracle/nosql/apps/kv
javac -classpath \
/opt/oracle/kv-ee/lib/kvclient.jar:examples \
examples/hadoop/table/LoadVehicleTable.java
This should produce the file:
/opt/oracle/nosql/apps/kv/examples/hadoop/table/LoadVehicleTable.class
Run LoadVehicleTable
when the Store is Non-Secure
To execute LoadVehicleTable
to create and populate the table named vehicleTable
with example data in a store configured for non-secure access, type the following at the command line of the client node, which must have network connectivity with a node running the admin service of the non-secure store you deployed (for example, kv-host-1
itself):
cd /opt/oracle/nosql/apps/kv
java -classpath \
/opt/oracle/kv-ee/lib/kvstore.jar:\
/opt/oracle/kv-ee/lib/sklogger.jar:\
/opt/oracle/kv-ee/lib/commonutil.jar:examples \
hadoop.table.LoadVehicleTable -store example-store \
-host kv-host-1 -port 5000 -nops 79 [-delete]
The following parameters are required: -store
, -host
, -port
, and -nops
, whereas the -delete
parameter is optional.
In the example command line above, the argument -nops 79
requests that 79 rows be written to the vehicleTable
. If more or less than that number of rows is desired, then the value of the -nops
parameter should be changed.
If LoadVehicleTable
is executed a second time and the optional -delete
parameter is specified, then all rows added by any previous executions of LoadVehicleTable
are deleted from the table prior to adding the requested new rows. Otherwise, all pre-existing rows are left in place, and the number of rows in the table will be increased by the requested -nops
number of new rows.
Note:
Because of the way LoadVehicleTable
generates records, it is possible that a given record has already been added to the table, either during a previous call to LoadVehicleTable
, or during the current call. As a result, it is not uncommon for the number of unique rows added to be less than the number requested. Because of this, when processing has completed, LoadVehicleTable
will display the number of unique rows that are actually added to the table, along with the total number of rows currently in the table (from previous runs).
Run LoadVehicleTable
When the Store is Secure
To execute LoadVehicleTable
against the secure store that you deployed and provisioned with a non-administrative user according to the steps presented in the Deploying a Secure Store appendix, an additional parameter must be added to the command line above. In this case, type the following on the command line:
scp <username>@kv-host-<n>:\
/u01/nosql/sn1/kvroot/security/client.trust /tmp
cd /opt/oracle/nosql/apps/kv
java -classpath \
/opt/oracle/kv-ee/lib/kvclient.jar:\
/opt/oracle/kv-ee/lib/sklogger.jar:\
/opt/oracle/kv-ee/lib/commonutil.jar:examples \
hadoop.table.LoadVehicleTable -store example-store \
-host kv-host-1 -port 5000 -nops 79 \
-security /tmp/example-user-client-pwdfile.login \
[-delete]
The client.trust
file generated when the secure store was deployed must be installed in the /tmp
directory of the client node from which LoadVehicleTable
is executed. If the client node is different than any of the store nodes (kv-host-1
, kv-host-2
, kv-host-3
), then the installation of client.trust
is accomplished by performing a remote copy; using the appropriate username and the number 1 in place of the <n>
token. On the other hand, if LoadVehicleTable
is run from one of the nodes making up the store itself, then a local copy operation can be used for the installation.
The additional -security
parameter in the command above specifies the location of the login properties file (associated with a password file in this case rather than an Oracle Wallet) for the given user or alias. All other parameters are the same as for the non-secure case.
To understand the -security
parameter, recall from the Deploying a Secure Store appendix that a non-administrative user named example-user
was created, and a number of credential files based on a password file (rather than an Oracle Wallet) were generated for that user and placed under the /tmp
system directory. As a result, you should see the following files under the /tmp
directory of the client node:
/tmp
client.trust
example-user-client-pwdfile.login
example-user-server.login
example-user.passwd
For this example, the user credential files must be co-located, where it doesn't matter which directory they are located in, as long as they all reside in the same directory accessible by the user. It is for this reason that the shared trust file (client.trust
) is copied into /tmp
above. Co-locating client.trust
and example-user.passwd
with the login file (example-user-client-pwdfile.login
) allows relative paths to be used for the values of the system properties oracle.kv.ssl.trustStore
and oracle.kv.auth.pwdfile.file
that are specified in the login file (or oracle.kv.auth.wallet.dir
if an Oracle Wallet is used to store the user password). If those files are not co-located with the login file, then absolute paths must be used for those properties.