Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elasticsearch 1.0.0 released

elasticsearch.org

Post reply on HN
Print view View original

91–100 of 139 posts

Re: Elasticsearch 1.0.0 released

#91

Post by buckbova »

gibrown wrote: post #80
alecco wrote: post #66

Why is it awesome? Why "it just works"? Is it just a mongodb-kind document store over Hadoop+Lucene? What makes it so special to have hundreds of votes and tweets all around within 2 hours? I don't understand. A DB engine engineer.

There are a lot of features thoughtfully combined that make ES great. Top of my list would be: 1. It handles human written language. Any language. The same technology that let's it handle strings written in human language provides a lot of flexibility in handling string in other applications. Particular when handling logs. 2. Non-string data it also handles very fast and cleanly (numbers, dates, geo). 3. Lucene has a…

Is this accurate to elastic search since it is build on Lucene?

https://lucene.apache.org/core/

"index size roughly 20-30% the size of text indexed"

That seems excessive for an index.

Re: Elasticsearch 1.0.0 released

#92

Post by nasalgoat »

troels wrote: post #16
m0th87 wrote: post #5

It was two weeks ago, and our startup was on the precipice of a major launch. We had completely rewritten our online publication site, which drives the bulk of our traffic. The product had to be shipped on-time - we had press releases, eager investors and a launch party dependent on it. A few days before launch, things were not looking good. As admins manipulated articles in preparation for the launch, the servers ke…

Did you try/consider Sphinx? It's simple and it's quite fast. I'm using that and I'm pretty happy with it, but I might investigate ES at some point to see if I can squeeze a bit more speed out of it.

Sphinx is a bit too 1:1 - it only works as a single server, not a cluster.

Re: Elasticsearch 1.0.0 released

#93

Post by gibrown »

buckbova wrote: post #91
gibrown wrote: post #80

Earlier quoted context omitted.

There are a lot of features thoughtfully combined that make ES great. Top of my list would be: 1. It handles human written language. Any language. The same technology that let's it handle strings written in human language provides a lot of flexibility in handling string in other applications. Particular when handling logs. 2. Non-string data it also handles very fast and cleanly (numbers, dates, geo). 3. Lucene has a…

Is this accurate to elastic search since it is build on Lucene? https://lucene.apache.org/core/ "index size roughly 20-30% the size of text indexed" That seems excessive for an index.

Not sure how that's calculated. I assume it is accurate, but the index size is going to depend a lot on what kind of text you have and how it is separated into individual terms (or n-grams or all the other ways you can tokenize and filter to create individual terms).

Personally, I think of disk space as cheap, and am far more concerned with having options to improve speed and quality of search results.

Re: Elasticsearch 1.0.0 released

#95

Post by troels »

nasalgoat wrote: post #92
troels wrote: post #16

Earlier quoted context omitted.

Did you try/consider Sphinx? It's simple and it's quite fast. I'm using that and I'm pretty happy with it, but I might investigate ES at some point to see if I can squeeze a bit more speed out of it.

Sphinx is a bit too 1:1 - it only works as a single server, not a cluster.

Well, you could simply have multiple instances running on different nodes. It's manual work, but by no means impossible. In my setup, I have a sphinx server running on the same node as my web server (Which is the consumer of the search). So they scale with each other. For more advanced uses, it's probably not adequate, but it's not a big concern of mine.

Re: Elasticsearch 1.0.0 released

#96

Post by dreamdu5t »

We recently switched from using MixPanel + Crittercism + Sphinx to using qbox.io (hosted elasticsearch) and Kibana to do all our analytics, crash reporting, and search.

I can't recommend qbox.io enough! Point-and-click scaling of managed elasticsearch clusters + Kibana == bliss.

Re: Elasticsearch 1.0.0 released

#97

Post by chriscareycode »

Zilog wrote: post #40

Too bad they have yet to address the split brain issue.

I haven't had a split brain on my 15 node cluster in over 6 months even though the cluster is split among multiple data centers which do drop connectivity from time to time. When the setting was wrong, it happened constantly. Tune it properly and it won't happen. n/2+1

Re: Elasticsearch 1.0.0 released

#98

Post by room271 »

curun1r wrote: post #56
brasetvik wrote: post #21

Earlier quoted context omitted.

I can't comment much on MongoDB, but I've written a bit things to keep in mind when considering Elasticsearch as a NoSQL store here: https://www.found.no/foundation/elasticsearch-as-nosql/

An interesting read, but I'd disagree with your contention that NoSQL isn't about ACID. When NoSQL databases started coming out, it was really about which CAP guarantee a database chooses to compromise. Traditional SQL databases are either partition-intolerant or become unavailable (for writes) in the event of a partition. NoSQL databases compromise on consistency. If a database is claiming to be NoSQL and have ACID…

I'm not sure you have this right. CAP says nothing about ACID - it only mentions consistency.

NoSQL was in large part about precisely what the name implies - giving up relational (SQL) data in exchange for better performance and the ability to have a distibuted store. Yes, part of this is also about being willing to trade off consistency for availability. But Elasticsearch is an example of a NoSQL store which does focus on consistency (in this case at the expense of availability and, to some extent, partition tolerance).

Re: Elasticsearch 1.0.0 released

#99

Post by room271 »

axionike wrote: post #85

ES has performed very well for us as the backbone for the solution we deployed for a large government-sector customer. Had some GC issues initially, and were worried about user concurrency, especially since we were not restricting queries (i.e. users can do full-scale wildcard searches against the entire data set of 1BN+ records). But ES continues to shine. Congrats to the ElasticSearch team, and all the supporters a…

This may require a bit more lengthy answer than makes sense here, but I'm curious about what was causing your GC issues and how you fixed them (we have GC issues at the moment).

Re: Elasticsearch 1.0.0 released

#100

Post by wikyd »

nzadrozny wrote: post #29
bryanh wrote: post #27

The thing that worried me the most about Elasticsearch was how fragile it got around the limits of its performance. Run out of memory because of a nasty query? Boom, data corrupted. I hope you weren't using it as your primary persistence layer... Otherwise, we love ES. The other comment about it being a better Mongo than Mongo rings true. With the backup/restore API and the some of the circuit breakers, I'm hopeful t…

Ditto open file handles, which is easy to push when aggressively over-sharding. Not an uncommon mistake for the enthusiastic newbie. Having supported Solr/ES/Lucene in production for 4+ years now (websolr.com / bonsai.io) I would be pretty hesitant to trust Lucene in general as a primary data store. Beautiful for secondary indexing, but otherwise, Why Not Postgres?™ ;)

I think the CSS for bonsai.io is not loading.
Post reply on HN