Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Thinking Outside the Table PART 2

Storing search results

A two-part series looks at techniques for shifting workload away from the application server and onto the database by using "extra" database tables.

It's just an average search - three full text indexes, ten subselects on many-to-many joins, and a bit of Pythagoras - to find results within 2km using latitude and longitude. It's the sort of query that makes your database give up just thinking about it, and your customers want to run it twice every second.

Sometimes databases will surprise you with just how quickly they can perform complex tasks. Sometimes, it's the opposite. You've normalized everything, indexed everything, cut down NULs, applied foreign keys, etc., and still it runs slowly.

The usual suspects are the tools that get used far more in Web publishing than the financial and administrative tasks on which database performance benchmarks are often based, for instance, outer joins and subselects. Both are vital tools for classifying and sorting the often semi-structured data that goes onto Web sites.

For example, imagine that you have products joined to subcategories joined to categories via a chain of joins (shown in Figure 1), and to search by category you have to first find which subcategories belong to that category and then find which products are in that subcategory.

Looking at an execution plan for that query using subselects, you can see why your database is feeling the strain.

Using joins would be a more efficient way of doing this, but sometimes when search criteria and relationships are optional, you have to either use an outer join, which is slow, or you end up having to construct the query in ColdFusion and optionally include joined tables, which can be torturous.

If you're working on Web sites, the chances are good that you're going to end up writing queries that run slowly (hopefully not too often). Fortunately, ColdFusion has several features to help alleviate the problem; timed caches and putting queries into shared scopes are the two primary means, and the only two that most programmers will ever need. There are times, though, when these techniques aren't enough. Timed caches can't currently use parameters and aren't advisable on queries that get supplied with many different values (product searches would probably fit this criteria), as the cache will quickly fill up.

Putting queries into a persistent scope is the most underused technique by new developers and is probably the most over-used technique by experienced ones. It's ideal for storing queries that rarely change, but putting search queries into the session scope is not the answer for storing the results of complex queries.

In early versions of my database front-end system, Article Manager, I attempted to relieve load on the database for complex queries by storing the value list of primary keys from search results in the session scope and then running a subselect for subsequent results pages. It worked fine for small results sets, but the implications for large result sets are obvious and not good. I soon changed it to the more scalable solution outlined later in this article, but not before I'd realized it had a lot of advantages besides cutting down load.

By storing valuelists in the session scope, it was easy to achieve some of the features of desktop database packages - such as "omit records," whereby you exclude records from your results in order to refine your search. The main reason you'd want to do this is so you can use another common feature, "save results," which allows you to save your results and then revisit them at a later date. These were very easy to achieve using list operations, but the system was limited to light use and small results sets.

I needed a more scalable system and one that did a better job reducing the database load, but I wanted to preserve the useful functions of "omit" and "save results." The solution was to store the results of the search not in the session scope, but in the database itself. By adding an additional table for search results and storing the primary keys of results sets in it, subsequent searches can be performed using an inner join and a single criterion.

The only thing that needed to be stored in the session scope was the ID number of the search, which could then be used to query the stored results. Say, for instance, you have a table of articles, and you want to perform a search on it. Instead of returning the results directly, you insert the results into a results table first, and then query the database; e.g., to perform the search:


INSERT INTO search_table (am_record_id, am_saved_searches_id)
SELECT 	articles_id AS am_record_id, #search_id# 
FROM 		articles
WHERE		[search clause here]

To get the results themselves, you then join to this table:


SELECT      headline, description, pubdate
FROM		articles     A
INNER JOIN	search_table S
ON		A.articles_id = S.am_record_id
WHERE		S.am_saved_searches_id = #search_id#

This technique is not without its critics. It places an overhead on any given search, with insertions and indexing of the search table, and the join required to get the results carries an overhead when compared to the simplicity of a single search on one table, albeit a small one. Figure 4 shows the execution plan for the following query:


SELECT      headline, description, pubdate
FROM		articles     A
where		pubdate > {d '2004-11-01'}

Databases are built to ensure that queries such as this run quickly, and provide caching mechanisms to ensure that repeated calls run even quicker. If all your queries look like this, then saving results in the database is not for you. If, however, your queries look like my queries sometimes do (large and unwieldy), and you like the idea of result sets and saved results, then this technique has many advantages.

First, your queries don't have to get much more complicated than this before you'll see a performance gain from storing results. If you're returning small numbers of results compared to the total number of records, then the overhead of adding to the search results table becomes less important. Searches using the LIKE operator can also be slow, as can OUTER joins, and if you have big, complex queries that aren't completely parameterized, then compiling them will take time, and storing results can alleviate load.

But it's not until you start to use some of the techniques discussed earlier that this technique comes into its own. Omitting records from a search set is simply a matter of deleting records from the join table. Saving search sets is as easy as saving the ID of the search in question. The search results can be reloaded at any time without having to rerun the query.

Another neat feature is the ability to search within the found set or add to the found set. Figure 5 shows the search options for Article Manager when a found set already exists. This is easily achieved as the results of the found set are in the search table and can be used in a join or a subquery.

If you're in a situation where you don't have any write access to the tables, then obviously the technique can't be used. If you're in a position where you have SELECT and STORED PROCEDURE access only, then you can still use the technique in SQL Server by making use of a new feature in SQL Server 2000, the ability of a user-defined function to return a table. First you write a function that takes a varchar list of IDs and splits them to return a table of separate IDs. You can then use a select query to generate your results and a stored procedure, which takes a varchar parameter to store them. The stored procedure would look something like this:


INSERT INTO search_table (am_record_id, am_saved_searches_id)
SELECT	ID,  @searchID from SplitParameterWithCommas(@IDLIST)

where @IDLIST would be a varchar, something like "1,3,5,3,7,1,4,6,7,3."

See Listing 1 for an example of returning a table from a UDF.

Conclusion
In summary, this isn't a technique for everybody. The downsides are obvious - the extra overhead on the initial search and the need to have write access to the tables. You need to have good reasons to adopt it, but there are plenty of them. If your site's performance is suffering under the load of many-to-many joins, text searches, grouping, filtering, and sorting, then it may be the answer. If you like the idea of saved search sets, then it's definitely for you.

More Stories By Tom Peer

Tom Peer has been in electronic publishing of one sort or another for ten years, including a stint as manager of New Scientist Online (www.newscientist.com). He specializes in taking printed publications online and has recently completed the online edition of The World Handbook of Stock Exchanges (www.exchange-handbook.com).

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
R Martin Ladner 12/16/04 05:53:05 PM EST

We sometimes underestimate what the database can do for us. Suppose you want to list the distance between families able to help and families that need help. (Most families are in both categories.) Supply map coordinates (such as B13) using three fields: a letter (Ltr) for the X coordinate (for entry or later display), the number corresponding to the letter (XNr), and the number corresponding to the Y coordinate (YNr). Then use aliases to process one table as if it were two: families with a need (alias a) and families that can help others (alias b). The .857 below adjusts for the map scale. (To use this list, you would start with the most isolated families and work inward, but that's a subject for a different place and time.)

select a.family as Helper, a.XLtr as HelperLtr,
a.XNr as HelperX, a.YNr as HelperY,
b.Family as Family, b.XLtr as FamilyLtr,
b.XNr as FamilyX, b.YNr as FamilyY,
((a.XNr-b.XNr)^2+(a.YNr-b.YNr)^2)^.5*.857 as Distance
from Family a, Family b
where a.helps = TRUE
and b.needs = TRUE
and a.family <> b.family
and ((a.XNr-b.XNr)^2+(a.YNr-b.YNr)^2)^.5*.857 <> NULL
order by ((a.XNr-b.XNr)^2+(a.YNr-b.YNr)^2)^.5*.857

Also, we often don't DE-normalize enough when more speed is required. An X12 document used for Electronic Data Interchange has segments which use standard elements in fixed positions; these elements have codes corresponding to human-readable information. A single page of code can do the lookups to convert X12 to human-readable format.

Ignoring hierarchy enforcement of interest only when testing or writing X12, tables to do this conversion could be represented in a normalized fashion as:
- segment: segment, meaning
- segmentelement: segment, position, element
- element: element, meaning, elemtype, length, typemodifier
- elemementcode: element, code, meaning

However, this is dog-slow when accessed. A better alternative is to pre-join some of the information. Even though one of the tables is larger than the two it replaces, the retrieval time is cut way down:
- segment: segment, meaning
- big: segment, position, element, elemtype, meaning (of element), length, typemodifier
- elemcode: element, code, meaning

To recap, when we think the database has nothing more to offer, we're usually wrong. =Marty=

IoT & Smart Cities Stories
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...