3 ms·
I don't think it's anyway near reality, but there's actually a number of ways this could work. If you prepackage your queries, or do some sort of profiling gui
by foota 7y ago
I don't think it's anyway near reality, but there's actually a number of ways this could work.
If you prepackage your queries, or do some sort of profiling guided optimization, the database could learn what it needs to index to answer your queries efficiently. There's already some precedence for this, with how Facebook for instance packages their graphql queries ahead of time to avoid parsing them at runtime.
Alternatively, you could maybe imagine models where storage is sharded along with the code for running it, so you say declaratively specify the data you need (count for this grouped by that, etc) and then at runtime the data is pre-aggregated per server hosting a certain shard.
- yazaddaruvala 7y agoRather than specifying a schema+indices or an Elasticsearch like mapping, preprocessing queries to derive the mapping will definitely be the next step. However, I doubt we will ever derive mappings from application code or (retroactive) profile guided optimization. The biggest problem will become deployments. We would need to couple application code deployments to deployments of databases even more than we do today (which is a giant problem). When a new index is needed or new data types we would need to “prime” the datastore in order to get optimal queries from the start. Even if this application-database deployment issue is fixed through automation it’s likely we wouldn’t want it to be coupled. Database index creation or schema change can take hours or longer. Application code needs to be very nimble. In the days of CI we don’t want Feature A’s database migration to block the deployment of Feature B or BugFix C.
- foota 7y agoThis is fair. Although I do think the collocated data + serving thing would be pretty neat.