The Solr index directory lives directly on the SSD (running on Windows - where the word symlink does not appear in any dictionary within a 100 mile radius of Redmond :-)
Currently, the main limiting factors of SSD are cost and size. SSDs will get larger over time. Splitting indexes across multiple shards on multiple SSDs is a wonderfully fast, if not slightly extravagant method of getting excellent IO performance. Regarding cost, I've seen many organizations where the use of fast SANs costs at least the same if not more per GB of storage than SSD. Hybrid drives can be a good cost-effective alternative as well. Peter On Tue, Aug 23, 2011 at 3:29 PM, Gerard Roos <l...@gerardroos.nl> wrote: > Interesting. Do you make a symlink to the indexes or is the whole Solr > directory on SSD? > > thanks, > Gerard > > Op 23 aug. 2011, om 12:53 heeft Peter Sturge het volgende geschreven: > >> Just to add a few cents worth regarding SSD... >> >> We use Vertex SSD drives for storing indexes, and wow, they really >> scream compared to SATA/SAS/SAN. As we do some heavy commits, it's the >> commit times where we see the biggest performance boost. >> In tests, we found that locally attached 15k SAS drives are the next >> best for performance. SANs can work well, but should be FibreChannel. >> IP-based SANs are ok, as long they're not heavily taxed by other, >> non-Solr disk I/O. >> NAS is far and away the poorest performing - not recommended for real >> indexes. >> >> HTH, >> Peter >> >> >> >> On Mon, Aug 22, 2011 at 3:54 PM, Rich Cariens <richcari...@gmail.com> wrote: >>> Ahoy ahoy! >>> >>> Does anyone have any experiences or stories they can share with the list >>> about how SSDs impacted search performance for better or worse? >>> >>> I found a Lucene SSD performance benchmark >>> doc<http://wiki.apache.org/lucene-java/SSD_performance?action=AttachFile&do=view&target=combined-disk-ssd.pdf>but >>> the wiki engine is refusing to let me view the attachment (I get "You >>> are not allowed to do AttachFile on this page."). >>> >>> Thanks in advance! >>> >> >> > >
