to be honest, the way compound index is implemented in mongo is problematic (index intersection never worked for me). you have to tinker a lot sometimes, so the query params are in the right order so the query planner don't decide to pick other index or not use index at all.
not sure if this was fixed in recent versions, but if you have index on array of strings/ints, and then use `addToSet` operator, the index is not used for the `addToSet` operation, and the disk is hammered for each update to verify if the content of the array has unique values. with pretty high volume, you can easily saturate the disk queue, wondering what is happening and how you can fix that
after few years of working with few TB collections (tables) in mongo, I can say that this DB is good if you want to insert data, but don't need to read the data that much often. if you need json and read heavy DB, consider something else eg elastic (with all it's drawbacks), because at some point the limiting factor for you will be indexes in mongo, that are the most weak part of this DB (even more weak than the infamous data loss)
can you link these issues? i'm planning upgrade from 22.x but i'm afraid of some breaking issues. also did you upgrade or reinstall ? if upgrade, were there some issues with that ?
it's the other way around: `wait_for` waits for the next refresh (there is configurable refresh interval, 1s by default), `refresh: true` forces refresh without waiting for the next refresh interval.
the difference is that waiting for refresh assures that the data will be available for search after the "insert" finishes. forcing refresh might be foot gun that will criple the servers.
in my case, i ultimately introduced linters, formatters, git hooks, gh actions, etc. i've tried to explain and tried other things, but it felt like babysitting at that point. if someone is unaware of their own weaknesses, there isn’t really much you can do about it; you'll just end up fighting, which will make both of you resent each other
make everything as code, introduce linters, formatters, hooks and checks. when you work in a small team with people of a relatively similar mindset, such things aren't necessary, but when the team grows, there will always be issues with such things. so having a mechanism to enforce rules is necessary for your own sake
very nice. there are things that won't show up in the network panel and you had to resort to proxy for debugging, especially when you are using puppeteer/etc for testing.
recently had to research "residential proxy", and the number of websites that claim that they have millions of IPs on hand was very strange. then the fact that a lot of them work in the exact same way, and a lot of them accepted payment mostly in crypto was very strange. so now connecting the dots, makes sense now why these "residential proxy" websites looked and worked the same way
it happened because the story of dependencies (system & application) was terrible. the ability to run the app on different distribution/kernel/compiler/etc was hard. there were different solutions like vagrant, but they were heavy and the DX wasn't there
exactly, i'm using "google phones" since nexus s, and they always have some discounts few months after release. other thing is that they currently offer 5y of updates, so even one year later with heavy discounts the phones are still good. i've got my P8 Pro with 1/3 discount
it is madness, you would be surprised how many ppl take things too serious. been there, had talk with HR cause i've said that the solution is mediocre and we have to do something better than that.
not sure if this was fixed in recent versions, but if you have index on array of strings/ints, and then use `addToSet` operator, the index is not used for the `addToSet` operation, and the disk is hammered for each update to verify if the content of the array has unique values. with pretty high volume, you can easily saturate the disk queue, wondering what is happening and how you can fix that
after few years of working with few TB collections (tables) in mongo, I can say that this DB is good if you want to insert data, but don't need to read the data that much often. if you need json and read heavy DB, consider something else eg elastic (with all it's drawbacks), because at some point the limiting factor for you will be indexes in mongo, that are the most weak part of this DB (even more weak than the infamous data loss)