July 7, 2010 at 8:16 am
Supporting several SQL 2008 OLTP database servers and the web teams have begun digging into Lucene to speed up the web searching ( the web apps are only a component of the order taking, not the main application which is more client/server).
Per any caching mechanism, they need a method to update their cache and the typical requirement is real time - but I have hopefully tamed their expectations since the servers are not dedicated for web work.
As anyone run Service broker and utilized query notifications on their main servers before? I am a bit leery of having all these additional services running and the indexed views that go with them on some reasonably large tables that get changed fairly frequently. I have had many of these requests - some have requested writing small apps to sit on our DB servers to do the Lucene index update requests, etc
Any thoughts - tales of wisdom that you can throw out?
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
July 7, 2010 at 12:18 pm
I am not familiar with Lucene. I have used service broker in several designs and it has worked out well. It does have certain quirks limitations and you should understand the ramifications completely before you cavalierly use it as a major component of a OLTP system.
I would have to understand your system requirements and existing architecture a lot better before I could make any useful recommendations.
The probability of survival is inversely proportional to the angle of arrival.
July 7, 2010 at 12:48 pm
Lucene is basically indexing for .NET apps. It basically allows web apps to search the Lucene index versus heading off to the DB to do the search. In that aspect, its quite nice and used by some big companies.
The issue is more generic - handling cache refreshes - constant "polling" of the data and scanning it seems to be the easy way out. (with the expenses of those calls) Service Broker is the other, but it seems to be a bit of an unknown to the SQL DBAs and not real mainstream as of yet. Not to mention what query notification requires.
Cheers
http://twitter.com/widba
http://widba.blogspot.com/
July 7, 2010 at 1:04 pm
Sounds like it is basically a middle tier that provides caching/fast access to often accessed data. COuld be a good performance benefit with the right architecture. In many cases you can achieve similar results by partitioning data across 2 or more servers.
As stated, one would have to understand the application requirements, typical and expected performance in terms of transactions per second and aggregate data transfer. There is no magic bullet; it just needs to be scalable and have no performance bottlenecks.
The probability of survival is inversely proportional to the angle of arrival.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply