Updates followed by queries on fields will lag a bit, depending on the
default index interval. But a get-by-id will be realtime.
For example, I wrote a performance test case in which I created a custom
mapping with no indexing on the fields. My driver had one or more writer
threads that created unique _id values and added documents to the index +
type + _id. The writers then passed the _id values onto one or more reader
threads that queried based on index + type + _id. Also, all of the
documents in the index + type were given a 10s time to live, and the
default TTL processing was left at 60s. (This meant that expired documents
would remain for up to about 50s).
No errors were seen; no update failures, and no query failures. ES and its
use of the JVM were solid, showing steady and sustainable throughput.
On a quad-core i7 MacBook Pro laptop (disk spindles, not SSD), I could
sustain a throughput of about 5000 documents created, added, and queried
per second. This also included serialization to and from JSON. I used the
Jackson 2 libraries and Jackson data binding to do the serialization. (ES
provides only the streaming API of Jackson 1.9. It would seem a good update
for ES 1.0 to include the full (3 jars worth) of Jackson 2. But if not,
then the jars are easy to add, as ES nicely re-packages all of its internal
dependent jars to avoid conflicts:
Hope this helps. It's not a typical use case, but one of the several
important ones to me.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c4455406-8873-47a2-b160-0b1508aac272%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.