Hacker News Reader

Comment by marginalia_nu | Hacker News Reader

To be fair, if you manage to make search slow for a database with ~10,000 entries, you're doing something very strange. Even allowing for egregious post-sizes of 100Kb/entry, that's less than 1 Gb. A raspberry pi could keep the database in RAM with room to spare.

View on HN

Full text search is tricky no matter how small the dataset is. But yes the speed should be instantaneous as long as you use standard FTS solutions.

It really isn't. You could have implemented this site using a single MySQL LIKE query and it would have been equally performant. Or even download the full dataset to the client on page load and do the search locally in JavaScript. The problems all arise when you need to scale.

> Or even download the full dataset to the client on page load and do the search locally in JavaScript.

That's exactly what I did for a recent hobby project of mine[0]. In my case, I've a db of 30K entries with gzipped size of ~600kb. This serves well for the few hundred visitors I get every day.

[0] https://theshowgrid.com/

Using like operators isn’t full text search. It won’t find results where the words you typed are switched around for example. It wont even work if you accidentally put double spaces. This could work for a toy project but for any respectable app, using like as the search operator will suck. Not to mention it’s unscalable.

> Not to mention it’s unscalable

How does this affect anything in a discussion about an explicitly fixed scale problem?

Reply on news.ycombinator.com