17

I hesitate to call ElasticSearch a database. It is not a replacement for a database, but it makes a good addition to add functionality, specifically advanced text searching, along side your existing database. I see where you can get them confused. They can actually fit the same need, but not always. ElasticSearch does exactly what it sounds like, searches. ...


11

MongoDB is a database. Elasticsearch is a search engine. Since their aims are different, they have different priorities. MongoDB is focused on storing data consistently with good performance and to support different access patterns. Elasticsearch is focused on building low-latency indexes for search specifically text search. MongoDB does have full-text ...


6

You don't have to block the complete UI before the response comes back. You only have to disable the parts of the UI which allow to make another API call before the first one is processed completely (in an asynchronous operation, of course!). If that is feasible or not depends heavily on the UI, the features of your application and how they are tied to ...


6

I have a few recommendations based on my experience. I would call user action logs user audit logs to differentiate them from application logs. ELK should be a fine place to store both kinds of logs. I would use a separate index for application logs and user audit logs so you can use all logging levels for each. INFO logs can be very helpful for application ...


4

Even fetching all details for just one hotel may results in a JOIN query from at least four tables, and scanning over all hotels records. A four-join query is absolutely trivial if you have the appropriate indexes for all joins. The second part of this question is far more troubling. Why the scan over all records? Is is because of missing indexes? or ...


4

Is it good to consider elastic search a datastorage? It is even better to consider it a search engine. But you are right, some people indeed use Elasticsearch as database. See: Jetslide uses ElasticSearch as Database This post explains how one could use the search server ElasticSearch as a database. I’m using ElasticSearch as my only data storage ...


4

I think that your search results can greatly improve through a number of techniques or database design approaches that will improve performance in your typical RDBMS. I suggest looking into and possibly prototyping the following improvements to see if they help you in performance testing first before you commit to an entirely new database technology that ...


3

Both of these database has their specific need to solve specific problem at certain level of application requirement. Although we have not used Graph Database. But we are using elasticsearch with MySQL in one of our project from last 5 years. That project has a massive data to be searched through 6m documents and has massive relationships between those ...


3

Full text search in Meteor is supported in Meteor 1.0.4 or later. In order to perform a full text search you'll, need to build a text index. This is a data structure that allows MongoDB to efficiently perform text searches. Whenever data is inserted or removed from the indexed collection, MongoDB updates the corresponding index. Here is a "Guide to Full ...


2

It's quite unclear what exactly you are asking. We can't write an Elasticsearch tutorial here. As a rough overview: You should have an ES index that contains all the information you possibly want to search/aggregate/facet and also all or most information you want to display. Your search has two basic parts: The search itself that returns the products. ...


2

Why either/or? I've worked very successfully with a hybrid approach, using a relational db (SQL Server, but pick your favourite) to hold data that needs a relational structure - most of this is IDs linking all the various domain objects, very little textual data and certainly no blobs - and a nosql db (Dynamo) to hold large relatively unstructured data, ...


2

NoSQL is generally not very good with relational data. NoSQL is often great for non-relational but structured data like documents or time series. Your "one to many" relationships may look quite like a document: e.g a "hotel" document may carry all its images, room info, etc stored together and fetched with one operation. On the other hand, if you see a ...


2

I Would avoid a 'Central Service' you can end up with a big blob of unstructured data. Presumably once the user has found something in there, you will want to do something with the result and this will require structured data. Each MicroService should be responsible for its own data and supply a search function. When the user does a global search, you ...


2

The common term for what you're describing is "expert system", or for a particular style a "software wizard". That you're talking about implementing it via text interface is just an implementation detail. Whether it's the correct tool I can't answer: you have to decide that yourself by comparing the difficulty of creation with the value to it's users. It is ...


2

What is the goal of your logging? Logging request, response, and user info is perfectly valid if your goal is to build a profile of your users. Google certainly does. If all you want to do is debug your service it's a bit much. Your focus should be on errors not recording how things went when it worked. My 11th grade English teacher has the best advice for ...


1

Think of Elasticsearch as an eventually inconsistent index on top of your DBMS. The index is built once for a specific state of the database, but when the content of the DB changes, one will have to update this index afterwards (for example, in regular intervals, or somehow coupled to these changes). Depending on how one implements the update strategy, there ...


1

It's a managed service operated by AWS. That being said I'd look at https://cloud.elastic.co/ which can run on AWS, GCP and Azure. 14 days for free. It's managed by elastic, creator of elasticsearch. Cloud by elastic is one way to have access to all features, all managed by us. Think about what is there yet like Security, Monitoring, Reporting, SQL, Canvas,...


1

If you've already decided (and I'd agree) to store the text in an another database and a key reference to it inside the graph edge, there's no need to store a copy of text there as well, that would just give you an overhead of having to provide consistency between the databases with no benefits. I'd place a caching layer in between the two databases (graph ...


1

Method 2 Sounds Best It's simplest and seems most suited to the situation you describe. It has been over a year since I worked on Elasticsearch. This is what I recall. Why? Method 1 vs. Method 2 If I had to pick between these with no further knowledge I would pick Method 2. It's hard to see why a parent-child relationship is beneficial if you are going ...


1

I also dont think that you need to decouple the two if your only concern is that ElasticSearch is updating the interface. If you have a decoupled layer then it should be more or less the same effort to change the code in the intermediate layer or in the coupled code. A reason to decouple the code would be that you want to plug your BL to a new underlaying ...


1

As you've written this question, it describes the standard usage for a search engine: you index the fields that you want to search by, then run queries against those fields. A search engine, however, is not a cache, even if it happens to store its indexes in-memory. If you want to have fast ID-based lookup for data, you should use an actual cache such as ...


1

Comparison with an oracle is always a good idea, when available. Comparison with a principle competitor is also a good idea. Your metric for comparison doesn't appear well thought out (what if the results come in a much different order? What if they come in a slightly different order?). If you are indexing one set of URLs (documents) and your oracle (...


1

Seems like you want to have a search engine. Have you already considered using elasticsearch, instead of implementing such a complex piece of software by yourself?


1

Well, I would advocate performance that benefits client over the choice of developer ease (after all client is the one who is paying). If you really have these two options then go with Search-> BL -> ElasticSearch(much faster compared to sql search) Suggestion: Implement an interface between Bl and ES. this interface will give you some abstraction. ...


1

We are building a new product in real estate space and the end users of this product are not so tech savvy. To have better user experience with our product, we want our users to find relevant things quickly and easily. Apart from a simple UI, a universal search bar seems to add value. The search bar with auto-complete will allow users to find ...


1

I would somewhat disagree with @Ewan. While yes, you can wind up with a big blob of unstructured data, that’s only an inevitable consequence if you don’t work to prevent it. In counterpoint, I’d argue that the public internet is actualy a collection of microservices, most of which happen to serve HTML documents of one flavor or another. Google, Bing, etc ...


1

There are multiple things to consider in your case. What program are you using to create your dashboard? There are tools, such as Tableau that could help via creation of extract - though this may cost money. You could try using PostgreSQL - it is known to be faster than MySQL and it is free. You could set up your batch process to real time where it cleans ...


1

Of course you can use the ElasticSearch Index API directly: https://www.elastic.co/guide/en/elasticsearch/reference/1.4/docs-index_.html Logstash's main responsibility in the ELK stack is the efficient collection and conversion of a stream of logs into individual, indexable documents. If you already have individual, indexable documents, Logstash may be an ...


1

ElasticSearch is effective enough for the searches you are looking for; ElasticSearch had sustained the benchmarks I've done(100 user/sec about 3 days); but from persistence perspective you need to hold one step back, if one of the node went down then it need Hugh time to recover and again it depend on the cluster configuration(take keen decision). It's able ...


1

There are also some tweaks you can apply on server configuration, in order to reduce split-brain problems in large(ish) clusters, namely the so-called discovery.zen.* parameters. There is not that much information about the inner workings and algorithms of ES, but what I found during my evaluation was the reference documentation about the server setup. In ...


Only top voted, non community-wiki answers of a minimum length are eligible