These two features look pretty simmilar, but Atlas Search is fresh and maybe more powerfull.
Is Atlas Search a replacement for Text Indexes in MongoDb? Will Text Indexes be deprecated?
Did I missed some essential difference? Is Atlas Search a proprietar feature of Atlas as cloud platform?
Is Atlas Search a proprietary feature of Atlas as cloud platform?
Yes, as of now.
Atlas Search is one of the selling points of Atlas (among many).
Atlas Search is [newer] and more powerful
Also true.
Will Text Indexes be deprecated?
I would say unlikely given that on-premise customers then would be left without text search at all, but I am not involved in this decision.
Atlas search is different from Text search, because atlas search uses Apache Lucene Engine in the backend for search functionality, which uses an “inverted indexing” to store the data, which makes it much faster due to how data is stored - It saves all keywords like glossary of a book with each page & its keywords.
Some more famous search engines uses same Backend (Apache Lucene) are:
Elastic Search
Solr
Search engines based on Lucene are very fast than regular text search & has many extra features such as:
Faceting (Filters functionality like in e-commerce website).
Fuzzy (If we type 1-2 incorrect words it'll still give correct results).
Memory based filters
Analysers for your needs (which can modify words on the spot while giving results).
Multi - Language Support
Autocomplete search
Much, much more
Atlas search is powerful search engine can search through millions of documents due to it's backend.
So, Yes atlas search is very different from Text Search, it saves alot of time, without need to use 3rd party search engines such as Elastic.
No, text search will not be removed because it can be used for normal applications & search requirements.
Atlas search is beneficial for projects such as E-Commerce or any application with a-lot of filters & search requirements with millions of documents.
I My self had used it in Australian E-commerce marketplace as primary search engine.
Related
I have to start an application where I need to decide which db should I use
For complex queries which should I prefer mongodb or firestore
Thanks
Personally, I would choose MongoDB but that strongly depends upon which application you want to build.
MongoDB is open source and not Cloud based, it is high portable and supports many programming languages and external products, although query syntax looks a bit more complicated.
If you need auto scaling feature and integration with other Google services then Firestore would be the best choice.
To wrap up, MongoDB seems to be more secure and consistent while Firestore is better suited for mobile apps or application based on real time data.
I have a string for eg: "My name is John" stored in Firebase.
How would I query firebase so I can find all the posts in Firebase that have "John" ?
I can search for the first term in a string now using:
DataService.dataService.BASE_REF.child("Posts").child(selectedComment.commentKey).queryOrderedByChild("userComment").queryStartingAtValue(comment).queryEndingAtValue(comment+"\u{F8FF}").observeSingleEventOfType(.Value, withBlock: { (snapshot) in
where comment = "My"
I read about using Elastic search with Firebase but wanted to check if there was an easier way in Firebase before I looked at ElasticSearch/Flashlight for Firebase,
Unfortunately, Firebase doesn't support searching thru content like that (in any language SDK). From a Google Groups Post in July '16:
As a company that understands search, we're also a company that
understands using the best tool for the job. For fuzzy matching and
contains, a NoSQL, realtime data store isn't the correct tool--these
queries would be slow and scale poorly. BigQuery or ElasticSearch are
the right tool for providing useful results in a scalable and robust
manner.
Right now, this involves deploying a small node script to sync your
search results with the realtime data, as explained in the article
with the sample Flashlight lib. In the future, it will become more
"effortless" as we add integrations between Firebase and Cloud
products, particularly Cloud Functions and BigQuery interoperability.
BigQuery is, as I understand it, not specifically designed for user-facing search.
Elasticsearch (specifically, the Firebase plugin Flashlight) is a potential solution, but as you alluded to, it's an incredible amount of overhead (deploying/managing or renting an ES cluster, configuring the plugin, etc.). If content search is an important enough part of your app to justify that time/$, you may want to consider solutions beyond Firebase for your database needs, as it's by far one of the service's weakest areas.
In my opinion, you have a few options beyond Flashlight:
Algolia, a Search-as-a-service provider, does offer integration with Firebase, but I've never used it & so can't offer much more than to say that it exists.
Another alternative might be maintaining a collection of documents you want to search on another service, like AWS Cloud Search
Depending on the stage of your project & your needs, consider other Backends-as-a-Service that support more in terms of querying. E.g., GraphQL-as-a-service backends, like Scaphold.io, Graph.cool, and Reindex are all built on SQL databases, and (I believe) all support multiple types of querying.
Good day, everyone.
I have an e-commerce website (Kohana php framework + Mysql + Sphinx search).
I want to integrate faceted search (also called faceted navigation, guided navigation, or parametric search) on my e-commerce shop.
1. I found several opinions that Solr was the best solution for faceted browsing? I want to be sure in my choice. Is Solr the best in doing that?
2. Also I want to migrate products (with attributes) from mysql to MongoDb. Is MongoDb good in cooperation with Solr?
3. Does someone know modules, ui, api for faceted search? Maybe there is some Zend library, Rest api...
Thanks for your help.
I found several opinions that Solr was the best solution for faceted browsing?
I am pretty sure that those who say that are most likely the same sales men who say that MongoDB pwns MySQL in every role.
Sphinx (the tech you are currently using) has been proven to support massive sets in a performant manner, for example: http://infegy.com/ uses it for a result set of 22 billion records ( http://sphinxsearch.com/info/powered/ )!
Solr is dead fast too but saying one is better than the other when both support facets and both support super fast speed on super big result sets is just utter nonsense.
Also I want to migrate products (with attributes) from mysql to MongoDb. Is MongoDb good in cooperation with Solr?
Solr uses a separate XML schema and files to represent its internal files (Lucence here) unlike Sphinx which can do this transparently without you knowing.
So to get MongoDB to work with Solr is no different than using MySQL with it. You build up the XML files and commit (or soft_commit) them to Solr.
As for faceting, here is a very simple page on it with links to the places you need to go: http://wiki.apache.org/solr/SolrFacetingOverview
Solr has a built in REST (JSON) API on top of Jety ( http://jetty.codehaus.org/jetty/ ) which you can use to fetch all the facets you need easily.
Say, if I want to store PDFs or ePub files using MongoDB's GridFS, is it possible to perform full-text searching on the data files?
You can't currently do real full text search within mongo: http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo
Feel free to vote for it here:
https://jira.mongodb.org/browse/SERVER-380
Mongo is more of a general purpose scalable data store, and as of yet it doesn't have any full text search support. Depending on your use case, you could use the standard b-tree indexes with an array of all of the words in the text, but it won't do stemming or fuzzy matches, etc.
However, I would recommend combining mongodb with a lucene-based application (elastic search is popular). You can store all of your data in mongodb (binary data, metadata, etc.), and then index the plain text of your documents in lucene. Or, if your use case is pure full text search, you might consider just using elastic search instead of mongodb.
Update (April 2013):
MongoDB 2.4 now supports a basic full-text index! Some useful resources below.
http://docs.mongodb.org/manual/applications/text-search/
http://docs.mongodb.org/manual/reference/command/text/#dbcmd.text
http://blog.mongohq.com/blog/2013/01/22/first-week-with-mongodb-2-dot-4-development-release/
Not using MongoDB APIs, not that I know of. GridFS seems to be designed to be more like a simplified file system with APIs that provides a straightforward key-value semantic. On their project ideas page they list two things that would help you if existed in production-ready state:
GridFS FUSE that would allow you to mount GridFS as a local file system and then index it like you would index stuff on your disk
Real-Time Full Text search integration with tools like Lucene and Solr. There are some projects on github and bitbucket that you might want to check out.
Also look at ElasticSearch. I have seen some integration with Mongo but I am not sure how much has been done to tap into the GridFS (GridFS attachment support is mentioned but I haven't worked with it to know for sure). Maybe you will be the one to build it and then opensource it? should be a fun adventure
I have a lots of documents stored on Amazon S3. My questions are:
Does Amazon provide any services/APIs using which I can index the contents of the document and search them (full text indexing and searching)?
If it does could someone please point me to any link in the documentation.
If it does not then could this be achieved with Lucene and Zend Framework? Have any one of you implemented this? Can I get some pointers?
UPDATE: I do not intend to save my index on Amazon S3 rather I am looking forward to indexing the contents of the documents on S3 and serving them based on a search.
You can see this question, or this blog post if you want to do pure lucene, or you can use Solr, which is probably easier. See also this post.
Zend has a PHP port of Lucene, which ties in very well. You can look at the Zend documentation for how to use it.