|
|
|
|
|
|
by rawrmaan
3443 days ago
|
|
|
On the last point--I think trying to do this is one of the big reasons Parse failed. Auto optimizing DBs is an incredibly complex and delicate task. My Parse app's write performance suffered because my biggest table (27m rows, 10 small columns, 15GB) ended up with 17 auto-created indexes, taking up an additional 15GB of space. |
|
|
I personally wouldn't call Parse a "failure" and without going into details, this has absolutely nothing to do with why Parse shutdown.
That said the real challenge, that other such platforms might not have, was handling all the very different DB workloads for all the apps we were hosting.
I worked on some of the pieces of that auto indexer. In most cases, this is a feature that was both necessary for us and extremely useful for our customers who didn't know how to manage their own DB. What was arguably missing was a way to expose the indexing operations to the developers, although this would have brought it's share of other challenges for obvious reasons.
If we created 17 indexes on the same collection (in some cases, it was way! more), that's because there were query families issued that needed those 17 indexes. I can't say this is your case, but in almost all instances I've seen, this was a result of poorly designed DB schemas and query patterns. Of course, for developers who know what they're doing, it's hard to design properly when you're dealing with a blackbox.
Yes, amplification and DB size are an issue when over indexing but our auto indexer was under constant tweaking and wasn't creating indexes "just because".
It remains a very hard problem...