• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 43
  • Last Modified:

Design for SQL Server data solution to handle constant inserts/updates/deletes and also constant searching

Hi,

We are developing a database solution that will run on SQL Server 2014/2016 and wanted to see if any experts could pass comment or suggest a better/different approach.

The solution will involve a collection of tables (we'll call these the 'data' tables) that will be constantly updated by an external multi-threaded application running on a collection of external servers, probably around 20 data tables.  The data in these tables is updated using SQL MERGE and performs well already.  

The part we need to design is regularly (minimum of every minute) moving that data into the search tables which will be constantly searched on from a public website.

Our plan is to create a view/query to perform some basic calculations to create a subset of relevant data from each of the data tables, and use the output of that query to push the data into our search tables every minute.  We plan to use a stored procedure that will run every minute for each data table. Each stored procedure will select the relevant data from the data table and use SQL MERGE to insert/update/delete the records into the search tables.

We then plan to use the (NOLOCK) hint when querying the search tables in case any locking slows down the searches.  We'll probably create a view that UNIONS all the search tables to enable us to search across them.

This is our basic plan, along with optimizing the indexes to try and find a balance between optimizing the searches without degrading the time it takes to perform each merge.

Key points to consider are...

* There are around 20 'data' tables
* A subset of the data in each 'data' table is (after some basic calculations are used select the relevant subset) merged into the search tables
* Queries on search tables need to be as fast as possible with no delays (due to locking etc)
* Queries on search tables CAN allow for dirty reads
* Total amount of records in the search tables will be around 500,000 to 1m

Think that's the basics - please ask if you need any more information, but would love to hear any potential issues you see with our plan, or a better suggestion on how to approach this to put the most efficient solution in place.

Thank you :)
0
cp 30
Asked:
cp 30
2 Solutions
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
<knee-jerk one minute short attention span answer>

Sounds like SP's that fire every x minutes to drop a table (20 tables..), create the table per your specs, then slap a COLUMNSTORE index on it to optimize SELECT statements on it.

You'll want to time this as it might not be conducive to an every-minute update scenario, and if it's not then we're talking a MERGE statement without the columnstore index.
0
 
cp 30Author Commented:
Hi Jim,

Thanks for the suggestion.  Do you know how the  queries on the search tables be handled if the tables were in the process of being dropped and recreated?

Thanks
0
 
Scott PletcherSenior DBACommented:
Use a separate db for the search data.  Set RCSI on for that db.

You would only need the data that was modified since the previous minute.  Add a column with mod datetime and index it appropriately.  Then simply SELECT from the tables where the mod datetime > the time of the previous pull.

The data in these tables is updated using SQL MERGE and performs well already.  
Interesting ... typically MERGE does not perform as well as a separate UPDATE and INSERT (so-called "UPSERT").
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now