sanne.grinovero wrote:
Hi,
I got a bit confused on your last post. Are you saying that you are loading the user ids from a separate Lucene index rather than the database?
That surprises me a bit for two reasons:
- usually loading any stored field from the index is quite slow, it's CPU intensive and also quite IO heavy. People generally prefer to load from a database for such simple data extractions. Is this performing better in your case? We had recently introduced a FieldSelector to reduce the index extraction overhead: I'm wondering if that's helping with this.
>To be honest, I haven't yet done any comparisons in terms of response times and I just separated the user retrieval part which previously was stored at the Post level. So, it's a natural progression. The various filters to display the appropriate posts to the right user make it sensible to store the user ids and retrieve the users based on that (from the db or index). Otherwise I would have to retrieve the Posts themselves from the database which would kill the performance.
Honnestly, I never considered data retrieval from the index a constraint. I will have a look at the FieldSelector. Where can I find the documentation on this?
- How do you deal with transactions? Index operations might be stale (async) or generally just not as reliable as the database.
That is not a problem in this use case. If a change of photo or nickname doesn't come through immediately, it's not a disaster.
But I'm more interested in the other aspect which remains: if you store a variable in the index that may change and that is actually a selection attribute, the solution I chose for the User doesn't work. In that case, you actually need to keep that field updated resulting in the dreaded cascading database reads.
- Marc