3 ms·

hits tiny staple with enormous sledgehammer While it is possible to use ES as your primary store, doesn’t mean it is a great use-case. Pushing ES to durability

hits tiny staple with enormous sledgehammer While it is possible to use ES as your primary store, doesn’t mean it is a great use-case. Pushing ES to durability takes resources (people, time, compute) and rigor. For a blog site this feels like overkill. Your priorities are durable low-freq writes, and more freq-reads. Hands-free day-to-day maintenance, and simple recovery mode such as restore. Caching (and optionally queuing) can absolve sins of many topologies to fulfill these requirements. ES brings a much larger surface area than just store blobs and metadata. Big tax to gain free-text search - which while interesting most users will almost certainly never use (thank Google for that) Focus on a cheaper, lighter, database engine that is durable, checkpoints regularly, and has simple, testable backup/restore processes. Ship the backups somewhere e.g. S3

sombremesa 7y ago
You don't even really need* a backup/restore these days depending on which provider you use. * (They'll do it for you)
jimktrains2 7y ago
Postgres has a basic full text search built in. https://www.postgresql.org/docs/12/textsearch.html https://www.postgresql.org/docs/12/textsearch.html
badrabbit 7y ago
I disagree, both from a programming and admin perspective, I found ES to be the easiest option. With ES, I don't have to explicitly create tables (indexes) ,I find ES queries and results a lot easier to deal with. A single node ES cluster is easy to maintain, I mean, just give it enough ram and disk space and you shouldn't even have to think about it again. And if you want to visualize the data as an admin, you can slap kibana on it. You can even go a bit crazy here and feed ES your web server logs to have even better correlation for stats. ES also has a very simple testable backup proceee (as simple as a curl command!). To your point, it does feel like "using a cannon to kill a mosquito". But I still had a better experience with it than even sqlite.

sombremesa 7y ago

You don't even really need* a backup/restore these days depending on which provider you use. * (They'll do it for you)

jimktrains2 7y ago

Postgres has a basic full text search built in. https://www.postgresql.org/docs/12/textsearch.html https://www.postgresql.org/docs/12/textsearch.html

badrabbit 7y ago

I disagree, both from a programming and admin perspective, I found ES to be the easiest option. With ES, I don't have to explicitly create tables (indexes) ,I find ES queries and results a lot easier to deal with. A single node ES cluster is easy to maintain, I mean, just give it enough ram and disk space and you shouldn't even have to think about it again. And if you want to visualize the data as an admin, you can slap kibana on it. You can even go a bit crazy here and feed ES your web server logs to have even better correlation for stats. ES also has a very simple testable backup proceee (as simple as a curl command!). To your point, it does feel like "using a cannon to kill a mosquito". But I still had a better experience with it than even sqlite.