3 ms·
And what about adding a million rows to the RDBMS and querying it in under 100ms (which Redis allowed them to do). I will say that it was an implementation bug
by hashhar 10y ago
And what about adding a million rows to the RDBMS and querying it in under 100ms (which Redis allowed them to do).
I will say that it was an implementation bug which doesn't warrant the swapping out of entire data storage layers.
- kuschku 10y agoEasily doable. On a 10$/month server I frequently run queries doing text operations over 120 million rows for fulltext search of an IRC client backlog. In 64ms. Without caching. Using PHP. It's definitely doable, but you'll need to heavily fine-tune your queries. My first one was at over 2 hours for the same.
- nebabyte 10y ago> It's definitely doable, but you'll need to heavily fine-tune your queries Misrepresentation; then it's not actually over 120 million rows. You're basically encoding which subset to actually search in the query, rather than building a proper overall schema that trivializes queries.
- kuschku 10y agoNo. I mean stuff like using aggregation functions to let the database build a bitset out of them, and reading from every row a value into that bitset. I mean stuff like CLUSTER table ON (pixel_y_index, pixel, x_index) to change the order in which they are stored. Do those two optimizations alone and you improve speed massively.