Seems sane. A lot of these questions are answered based around *your* use case. If you have low volume for one new dataset, it totally makes sense to leverage existing infrastructure and then make future decisions as you go.
On 23 March 2015 at 10:35, Nick Malcolm <[email protected]> wrote: > Hi Mark! > > Good question - that gave me something to Google. Seems the issue is > pretty subjective. > > I guess the question becomes "Is an index equivalent to a traditional > database, or is a cluster equivalent"? In my mind index = traditional > database. Types = tables, etc. In which case we would add event indices to > the same cluster. > > Maybe we'll do it that way, and if it hurts later we'll look at putting it > on its own cluster, or other performance improvements. > > > > On Monday, March 23, 2015 at 11:26:18 AM UTC+13, Mark Walkom wrote: >> >> There's no real best practice here at this stage. >> But if you think about traditional datastores (ie DBs), would you mix >> these data sets? >> >> On 22 March 2015 at 13:34, Nick Malcolm <[email protected]> wrote: >> >>> Hi, >>> >>> We have a cluster set up already for indexing customer documents (bigger >>> documents, medium traffic). We want to add event logging (small documents, >>> lots of traffic). >>> *Should we do this on a new cluster?* >>> >>> - When do you typically create a separate cluster vs. add indexes to >>> a cluster? >>> - Is it straightforward to move indices to a new cluster at a later >>> date? >>> >>> >>> Reasons I can think of for using the same cluster: >>> >>> - Fewer servers to administer >>> - ES is already well equipped to handle multiple indices with >>> various mappings >>> - Simple searching across event & document indices, if needed >>> - If we were planning to add new servers for an events cluster, why >>> not have them in the same cluster for more redundancy >>> >>> Reasons I can think of for a new, separate, cluster: >>> >>> - The cluster can be tuned to the relevant performance needs >>> - Don't have to worry about the flood of events using up all the >>> disk space >>> - Separation of responsibility / "single responsibility" design >>> pattern >>> - If one cluster goes down / hits performance problems, the other >>> can continue along fine >>> >>> >>> >>> I couldn't see any blog posts or documentation around best practice for >>> this, so your insight would be most welcome! >>> >>> Cheers, >>> Nick >>> >>> -- >>> 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/ebb7afb0-9efb-45b1-b6e7-dba67bb52d1b% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/elasticsearch/ebb7afb0-9efb-45b1-b6e7-dba67bb52d1b%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/bae2e441-7a7e-4f56-be21-a584ebde5df5%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/bae2e441-7a7e-4f56-be21-a584ebde5df5%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/CAEYi1X-yQ2C0PG2M1mHuF7%3D1bMBhtPwBAxywM6qHh4bvETfMJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
