4 ms·

We are using it for our conceptual AI with space-time digital twin, and so are many others: https://solr.apache.org/community.html#powered-by https://solr.apach

We are using it for our conceptual AI with space-time digital twin, and so are many others: https://solr.apache.org/community.html#powered-by https://solr.apache.org/community.html#powered-by

simonw 4y ago
I've used Solr and Elasticsearch to build all sorts of things over my career, but I've rarely used them as the central point of truth for my data. Instead, I keep my data in a relational database and denormalize aspects of it out to them in order to answer queries that aren't a good fit for my database: https://2017.djangocon.us/talks/the-denormalized-query-engine-design-pattern/ https://2017.djangocon.us/talks/the-denormalized-query-engin...
- gibsonf1 4y ago
  And why is that, what do you get out of relational in that case that Solr doesn't give you? The Solr boolean query interface is very impressive and very fast. The caveat is you need a good essentialized schema.
  - simonw 4y ago
    Transactions and joins.
    - gibsonf1 4y ago
      I would call joins a bug of relational rather than a feature. If you have all the data in one collection, you don't need or want joins. For transactions, we do that server side (in our own system) as we have what we call temporary awareness created for each request that only writes when all operations have completed successfully before importing the state changes into primary awareness for that user.
      - simonw 4y ago
        Every large system I've ever encountered that's built on a NoSQL system such as MongoDB or Elasticsearch has inevitably ended up reinventing joins, poorly.
        gibsonf1 4y ago
        We have 1 collection with 4 doc types (attribute, state, event, process) and 14 relations between them, so a join concept makes no sense for us. I think the schema is the key issue in having success vs not. (Apache Solr - billions of docs)

4 ms·

We are using it for our conceptual AI with space-time digital twin, and so are many others: https://solr.apache.org/community.html#powered-by https://solr.apach

by gibsonf1 4y ago

We are using it for our conceptual AI with space-time digital twin, and so are many others: https://solr.apache.org/community.html#powered-by https://solr.apache.org/community.html#powered-by

simonw 4y ago
I've used Solr and Elasticsearch to build all sorts of things over my career, but I've rarely used them as the central point of truth for my data. Instead, I keep my data in a relational database and denormalize aspects of it out to them in order to answer queries that aren't a good fit for my database: https://2017.djangocon.us/talks/the-denormalized-query-engine-design-pattern/ https://2017.djangocon.us/talks/the-denormalized-query-engin...
- gibsonf1 4y ago
  And why is that, what do you get out of relational in that case that Solr doesn't give you? The Solr boolean query interface is very impressive and very fast. The caveat is you need a good essentialized schema.
  - simonw 4y ago
    Transactions and joins.
    - gibsonf1 4y ago
      I would call joins a bug of relational rather than a feature. If you have all the data in one collection, you don't need or want joins. For transactions, we do that server side (in our own system) as we have what we call temporary awareness created for each request that only writes when all operations have completed successfully before importing the state changes into primary awareness for that user.
      - simonw 4y ago
        Every large system I've ever encountered that's built on a NoSQL system such as MongoDB or Elasticsearch has inevitably ended up reinventing joins, poorly.
        gibsonf1 4y ago
        We have 1 collection with 4 doc types (attribute, state, event, process) and 14 relations between them, so a join concept makes no sense for us. I think the schema is the key issue in having success vs not. (Apache Solr - billions of docs)