Is there any loopholes or facilities not available in Endeca? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

We are evaluating an ecommerce site as part of our academic project/casestudy. We are from India. We don't have access to any Endeca Systems or any enterprise systems. we use only internet for the details. We have few basic questions as part of our study.

Is Endeca the best or the Solr?
Do the people who have implemented Endeca satisfied with it? If they need to enrich the search & UX capabilites, what should they do?
Does So开发者_StackOverflow中文版lr provide everything that Endeca provides?
What does Endeca doesnot provide but Solr or other products provide?
How does an Endeca system be improved?
What are the alternate capabilities that can be added up for a Endeca System?
If any client who have implemented Endeca wish to enrich their system capabilities, then how can they do? what can be suggested?

[Our study is basically a comparison with most favoured software implementation's loopholes and remediations. We analyzed a lot of softwares and found the Endeca to be the most favoured and every one has satisfied. We couldn't find a negative remark for this product. that's why we chose this product]

You're asking a very broad question that will be based on opinions. I'll offer my opinion.

Someone asked about Endeca on the Solr list and [I responded].1 His question was framed in terms of what Endeca has that Solr doesn't have. But Solr has things that Endeca does not have. For example, Solr has a weighted scoring relevancy model (its a formula) whereas Endeca's is really sort based which I consider to be less desirable. In many ways, the systems have similar capabilities, each feature working a bit differently but can usually accomplish the same customer goals with perhaps different idiosyncrasies. Both are capable. That said, I look forward to not using Endeca again and staying with Solr.

I have worked with Endeca before, but not Solr, so I can only offer one side of the discussion. Endeca is pretty good at what it does, once you get over the learning curve of managing the system configuration and learning how to get tasks accomplished (figuring out how to get this type of search to work, how to join multiple records sets together, etc). There is a certain amount of art to building the pipeline to generate the index for your specific needs, but in fairness I worked on it for a strange search requirement so I would imagine in general it isn't too bad to design the pipeline process appropriately, with a little practice. I would say the biggest and only real problem with Endeca from what I know is the huge price. It's extremely expensive for a license to use the product, and if you need professional consultants to help out, you will be bleeding money. Based on the price, even not having had used Solr, I would venture it is cheaper to hire someone to learn Solr, implement it, and spend a lot of time fine tuning it or buying more hardware to meet any speed requirements.

the first comment on search ranking seems to be one of the few places where SOLR beats Endeca (except perhaps on price). I've been exposed to SOLR in a production environment and am a long-time Endeca user. My impression is that Endeca comes with tons of web interfaces and cmdline deployment tooling whereas you're on your own with SOLR. For us, it's crucial that end users (non-engineers) can manage and configure a variety of options on the system. I'm pretty sure SOLR is 100% configured in config files so all changes will go through engineers. In Endeca, a bunch of options are user -configurable. We also use the Page Builder product for Endeca which allows for basic (and integrated) content management which is great. We can change pages on the site without code pushes (just Endeca config pushes which are super lightweight). We store about 18 million records in Endeca and there are others who store upwards of 100mm. We get sub-10ms response for pulling back individual records and sub-100ms for pulling back most navigation states (though we're not very optimized so you can get that much lower with some effort). SOLR does have another feature where you can access navigation states with your own ID. Endeca uses an intermediate value to get to navigation states (though the Endeca release later this year will add this feature). This is not that big of a deal usually since you generally derive the navigation states from the SOLR/Endeca engine on the fly and you don't have to calculate these yourself.