Did you consider SSD with RAID0 (Linux, ext4, noatime) and SAS2 (6g/s) or SAS3 (12g/s) controller?
I have for personal use at home LSI SAS 2008 of 4x128g SSD RAID0 with sustained 800 MB/s write and 950 MB/s read, on a commodity dual AMD C32 socket server mainboard. I do not test with JMeter but on this single node hardware alone I observe 15k bulk index operations per second, and scan/scroll over 45m docs takes less than 70 min. I'm waiting until SAS3 is affordable for me. For the future I have on my list: LSI SAS 3008 HBA and SAS3 SSDs. For personal home use, Fusion IO is too heavy for my wallet. Even for commercial purpose I do not consider it as a cost effective solution. Just a note: if you want spend your money to accelerate ES, buy RAM. You will get more performance than from drives. Reason is the lower latency. Low latency will speed up applications like ES more than the fastest I/O drive is able to. That reminds me that I'm waiting since ages for DDR4 RAM... Jörg On Thu, Jul 10, 2014 at 10:13 PM, John Smith <java.dev....@gmail.com> 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 elasticsearch+unsubscr...@googlegroups.com. > 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEnPy0QrjmSgSY0syCyt3N5gT4XFzDypE3mq85TFVjdvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
