Why would you even consider putting static HTML in a search engine? You don’t want to search it.
1. Filesystems are very fast, and operating systems are very good at caching them. 2. Files can be pre-compressed for some web servers (Apache, at least) saving CPU for compression 3. Solr is not a repository, so you need a copy of the files somewhere, maybe in the file system. You cannot get around the “double” copy by keeping the originals in Solr. 4. Filesystems are much, much more reliable than Solr. Solr is very good, but much more complicated than filesystems. If you really want to fetch blobs by ID and don’t want to use a filesystem, use a database designed for that. That was the original focus of MySQL, for example. Solr is not a database. Solr is not a repository. A design using Solr for primary storage of data is a broken design. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Jan 4, 2018, at 8:19 AM, Matthias Geiger <matzschman...@gmail.com> wrote: > > Hello, > i have a web application that delivers static html content to the user. > > I have been thinking about the possibility to deliver this content from > solr instead of delivering it from the filesystem. > This would prevent the "double" stored content (html files on file > systems + additional solr cores) > > Is this a viable approach or a no go? > In case of a no go why do you think it is wrong > > In case of the suggestion of a nosql database, what makes noSql superior to > solr? > > Regards and Thanks for your time
