4 ms·

I have something similar. Although I don't use any database in the middle. I just read the files. I have a cache layer, which is totally useless since I got an

I have something similar. Although I don't use any database in the middle. I just read the files. I have a cache layer, which is totally useless since I got an SSD drive. The only problem I have now is generating `similar posts` under each posts, which takes just too much time. And I have no comments. I used disqus, but didn't like that.

stevekemp 10y ago
I used to just read all the posts into a big hash, but when you have 1200+ the RAM usage started to get too high. That's when I started sticking them into an SQLite database. Even if you remove the database post-build, such that each post must be re-parsed and re-added, the reduction of RAM meant things were still very fast on my desktop.
- pleasecalllater 10y ago
  I have only 76 posts, and all of them cached on disk take 3MB, so don't have this problem yet. However I'm thinking about something else: I'm going to write a blog software with a nice api. It will be storing posts in a database on the server side, and will store them on the local too (as cache) - however the source files will be on disk, versioned by git. And it will send just new versions to server using a local command line utility. I really love publishing with a one liner. This way I could have fast search, and comments on the server side.
  - stevekemp 10y ago
    There are definitely different trade-offs to be made on storage, but it would seem that using both a database and a flat-file structure would be the worst of both worlds. If the database is used to serve the content it must be online, and so you lose one of the big appeals of static-sites: That they are static and can be served trivially. If you're writing in text-files you need some kind of update-process which might become tricky if you edit past-entries, etc. I suspect that publishing with one command doesn't really matter too much on technology; in my own case I just use a Makefile: * Download the comments from the remote server, via rsync. * Rebuild the blog. * Upload the generated HTML-site, via rsync.
brennen 10y ago
> And I have no comments. This is probably a feature.

stevekemp 10y ago

I used to just read all the posts into a big hash, but when you have 1200+ the RAM usage started to get too high. That's when I started sticking them into an SQLite database. Even if you remove the database post-build, such that each post must be re-parsed and re-added, the reduction of RAM meant things were still very fast on my desktop.

pleasecalllater 10y ago
I have only 76 posts, and all of them cached on disk take 3MB, so don't have this problem yet. However I'm thinking about something else: I'm going to write a blog software with a nice api. It will be storing posts in a database on the server side, and will store them on the local too (as cache) - however the source files will be on disk, versioned by git. And it will send just new versions to server using a local command line utility. I really love publishing with a one liner. This way I could have fast search, and comments on the server side.
- stevekemp 10y ago
  There are definitely different trade-offs to be made on storage, but it would seem that using both a database and a flat-file structure would be the worst of both worlds. If the database is used to serve the content it must be online, and so you lose one of the big appeals of static-sites: That they are static and can be served trivially. If you're writing in text-files you need some kind of update-process which might become tricky if you edit past-entries, etc. I suspect that publishing with one command doesn't really matter too much on technology; in my own case I just use a Makefile: * Download the comments from the remote server, via rsync. * Rebuild the blog. * Upload the generated HTML-site, via rsync.

brennen 10y ago

> And I have no comments. This is probably a feature.