elastic search in action ch1

Lucene index vs. Elasticsearch index

A Lucene index is a shard or a directory of files containing an inverted index.
An Elasticsearch index is made up of one or more such shards.

Near real-time, optimistic concurrency through versioning

• Realtime: once a transaction is complete, you expect to be able to read the newlycommitted data right away.
• Concurrency control: different operations are not allowed to work with the same piece
of data at the same time.

lasticsearch deals with these two in a different way.
 Let's take the realtime aspect first.  With Elasticsearch, if you index a new document, you will be able to get it right away, by specifying its unique ID – and we'll talk more about documents and IDs in chapter 2. On the other hand, when you search, by default the newly indexed document might not show up for up to a second. That's why we call Elasticsearch near-realtime.

Another thing that typically comes with transactions, but not with Elasticsearch, is
pessimistic concurrency control via locking.
This means that we are pessimistic and expect concurrent operations to cause problems. To prevent problems from occurring, the database would lock the data handled by that transaction. This makes other transactions wait for the lock to be released before they can change the same piece of data.
With Elasticsearch, we have optimistic concurrency control, by using versions: each
document has a version number, which is incremented each time a change is made. If a
concurrent application changed your document, you'll know, because its version has
changed. So you can take any action at this point: cancel your operation, or retry it. There is no locking, which helps performance: nobody has to wait, and nobody has to spend resources to lock and unlock data.

from elasticsearch in action