As you mention, ES is pretty aggressive with its caching and higher capacity IO helps with everything else.
Fusion is better than SSD and it's pretty awesome if you can afford it. But when it comes to what type of SSD it's really a financial decision around your capacity requirements. We run ES boxes with 24 SAS disk RAID10 and the IO capabilites are good enough for what we need ES to do, so we aren't looking to change that for now. But we have options to upgrade these to SSD if the capacity is needed. If you are at scale and have the processes to handle it, running something like quanta gear with commodity SSDs (ie not "enterprise" branded ones) makes a lot of sense. Then it's a matter of treating hardware as a real throw away commodity and not worrying if you lose N units, which leveraged along with ES's scalability and redundancy would be very effective. Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: [email protected] web: www.campaignmonitor.com On 11 July 2014 06:13, John Smith <[email protected]> wrote: > Using 1.2.1 > > I know each system and functionality is different but just curious when > people say buy SSDs for ES, what types of SSDs are they buying? > > Fortunately for me I had some Fusion IO cards to test with, but just > wondering if it's worth the price and if I should look into off the shelf > SSDs like Samsung EVOs using SAS instead of pure SATA. > > So far from my testing it seems that all search operation regardless of > the drive type seem to return in the same amount of time. So I suppose > caching is playing a huge part here. > > Though when looking at the HQ indexing stats like query time, fetch time, > refresh time etc... The Fusion IO fares a bit better then regular SSDs > using SATA. > > For instance refresh time for Fusion IO is 250ms while for regular SSDs > (SATA NOT SAS, will test SAS when I get a chance) it's just above 1 second. > Even with fusion IO I do see some warnings on the index stats, but > slightly better then regular SSDs > > Some strategies I picked for my indexes... > - New index per day, plus routing by "user" > - New index per day for monster users. > > Using JMeter to test... > - Achieved 3,500 index operations per second (Not bulk) avg document size > 2,500 bytes (Fusion IO seemed to perform a bit better) > - Created a total of 25 indexes totaling over 100,000,000 documents > anywhere between 3,000,000 to 5,000,000 documents per index. > - Scroll query to retrieve 15,000,000 documents out of the 100,000,000 > (all indexes) took 25 minutes regardless of drive type. > > P.s: I want to index 2,000,000,000 documents per year so about 4,000,000 > per day. So you can see why Fusion IO could be expensive :) > > Thanks > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/24928d08-6354-4661-8164-9ff665709285%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/24928d08-6354-4661-8164-9ff665709285%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624b-u6hK_gjFfkKZm7GxxTGx%2B71Wm5amW0KGnvzXNs5X3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
