This problem is definitely not new, indicated by the number of times the same or very similar questions asked on Stack Overflow. In general, there are 3 solutions:
- Add a new field to be filled with a comparable random value, usually a float; index this field for production ready performance.
skip, but it is said to be highly expensive.
- Not exactly a solution just yet, but wait for MongoDB core team to implement a native, server side solution. It is noteworthy that the issue on their JIRA was once closed as “Won’t Fix” but eventually re-opened due to popular demands.
I am fairly certain that the server side solution will be as solid as other APIs MongoDB generally exhibits, but it is not here yet. So crossing out 2 and 3, and I do not really like 1. The project is still very young (young enough that I am not talking about its name at the moment), so I can easily
drop the collection or the entire db in MongoDB to rebuild the structure without worrying about consequences. However, I do not like the fact that one additional field has to be added just to support one use case, especially when it also requires indexing, which could result in a mess if I ever decide to drop it.
So here is my solution:
- No extra field occupying both disk and RAM (if indexed), delegated to a Redis
- No messy random ID determination logic in client code, delegated to Redis
Of course, I will likely switch to the official solution when the time comes. But now, I am more than satisfied with what I came up with.
Let me elaborate more:
- I want to be able to get a sense of urgence when error occurs, but not to make myself panic by browsing through 10 gzipped logs containing the same stack trace
- I want to be able to have a central hub to see all logs, but without worrying too much about system resource consumption, such as disk space and RAM
To solve problem two, I would do:
So imagine that your nicely crafted web app suddenly got hit by hackernews viewers. 5,000,000 views on a particular buggy route resulted in 5,000,000 identical exceptions raised. No sweat, you’ll only get one error log, with a clear indication of how many times it was recorded. You saved resource to store logs, and time to dig logs out. Before they even realized, you have deployed the fix already.
As usual, Redis required.