Home ›

NoSQL Tutorial

Issue 67

From Issue #67
November 1999

Nov 01, 1999  By Giuseppe Paterno
 in
A comprehensive look at the NoSQL database.
Section 2: Getting and Printing Billing Name

cat $TMPFILE: reads the table written from previously stored temp file.

  • nosql join -j CODE - customer.rdb: joins the STDIN table (minus sign) and the customer.rdb table on the CODE column.

  • nosql column NAME PHONE EMAIL: selecting NAME, PHONE and EMAIL columns.

  • nosql body: gets only table content, without printing the header lines.

  • head -1: prints only one line; all the lines are identical since who sent the file (or order) is the same customer.

Section 3: Printing the Order Content

  • cat $TMPFILE: reads the table written from previously stored temp file. ''nosql rmcol CODE: removes CODE column from the STDIN table (it's not useful for us at this moment).

  • nosql print -w: prints the results in a simple but useful form. Columns containing only numbers are right-justified with blanks, while anything else is left-justified. The -w switch forces the print command to fit in a terminal window.

Section 4: Getting Total Amount Due

  • cat $TMPFILE: reads the table written from previously stored temp file.

  • nosql subtotal -T SUBTOTAL: calculates the sum of the SUBTOTAL column. The result of this command is a NoSQL compliant table.

  • nosql body: gets only table content, without printing the header lines.

  • rm $TMPFILE: removes the temporary file created before. The commands used at this moment have, of course, more options. For a complete overview, please check out the documentation included with the NoSQL package.

Indexing the Tables

The best way to search information on a large amount of data is, of course, indices, and NoSQL obviously has its own operators to interact with them.

Suppose our customers are increasing greatly since Acme Inc. started, so we need to speed up our searches. Most of the time, we look up on the CODE column, so it would be better to build the index on it last.

The command nosql index customer.rdb CODE will create an index on customer.rdb table against the CODE column. Index files are named by appending an x and the column name(s) (separated by a dot) to the base name of the table it refers to. In our case, the index file name is customer.x.CODE. If we want to update the index without rebuilding it, we should run

nosql index -update customer.x.CODE

A crontab job on our system will ensure a periodic index update, by running the command: 

cd /var/tables/acmeinc; nosql index -update
Not specifying any index file name on nosql index -update will update all indices in the current working directory.

Now that indices are built, let's try a search. In order to search against indices, you should create a small key table as input to the nosql search command, for example:

echo -e "CODE\n----\nACM004" | nosql search -ind customer.x.CODE

This command will extract the ACM004 value in the CODE column using the customer.x.CODE index. Creating this key table may not seem handy, but this ensures the maximum reuse of commands. Suppose you extracted some data from table1, you can search this last result on table2 easily with a single pipe. Try to think a bit about it, this is not a bad idea at all.

Your Lifebelt: The RCS

What if you discovered that last write caused a disaster and you do not have a backup? You will never have the latest copy of the table before the disaster happened.

The Revision Control System (RCS) is one of the best configuration management tools available, it can be used for version control of many types of files, including tables. The command nosql edit, for example, will automatically check out a table for editing, and then check the new version back into RCS. Other commands can utilize tables that are under RCS control by using explicit commands like:

co  -p  table | nosql row  ... | nosql column  ... | nosql print

or relying upon the cat command to handle interactions with RCS automatically: 

nosql cat table | nosql row  ... | nosql column  ... | nosql print
Note that this checks out a table, sends it to nosql row, then to nosql column, and finally, prints the data with nosql print. In general, any series of commands necessary can be constructed to do a given task even if the tables are checked into RCS.

Now that you have RCS keeping watch for you, if the disaster happens in real life, you can easily rollback: the command

nosql rollback [-d datestring] tablename

will extract the table updated at the desired time.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

dbms

srikanth.v's picture
Submitted by srikanth.v (not verified) on Mon, 08/24/2009 - 05:09.

my query is i want the thing as price * qty should give the amount and the total should be calculated for that what is the query in oracle sql(structured query language).

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions