CloudSearch
Amazon launched a search service called CloudSearch in April of 2012. It's a start (in the HA realm, a very good one) but in terms of features (say compared to Solr), it's pretty weak right now.
It always boils down to that feature that's missing from a new Amazon Web Service that forces me to come up with a (usually big) workaround. And when I'll be launching that "workaround", AWS will release that missing feature..as usual [sigh].
One hurdle with load balanced slaves is the latency between them leading to inconsistent paginated results.
My approach is to let ELB load balance for any first page search. When requesting subsequent pages of results, I pass the ELB cookie to the Solr request (via custom HttpClient).
.png)
The web site relies mostly on the Solr Slaves (SS) to display non-protected dynamic pages. With Beanstalk we can set it up to use 2 availability zones (AZ in the diagram) making searches (and consequently the web site itself) more fault-tolerant.
The Solr Master (SM) will receive updates from either our background process, keeping the index in sync once in a while, and the web servers, trying to keep an almost-real-time index of our relational database.
The standby would help in case the master in use "goes down", especially if creating the index from scratch would take a very long time but it's not a necessity.
Costs
It's all good and pretty but how much does it cost?
The biggest cost will be the computing costs (EC2). If we go with 1 SM (no standby) and 2 SS, only Large Instances (for better I/O) we're talking ~$215/month (3 x $71.5/month, using heavy utilization reserved instances for a 3 year term) minimum.
The biggest cost will be the computing costs (EC2). If we go with 1 SM (no standby) and 2 SS, only Large Instances (for better I/O) we're talking ~$215/month (3 x $71.5/month, using heavy utilization reserved instances for a 3 year term) minimum.
No comments:
Post a Comment