Community Page
- phildawes.net/blog/ Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Hi, Do you feel that your agility in Factor has improved since this post? Roger
- Thanks for the pointer - I've cleaned up the spam and regrettably added some moderation
- I'm loving the comments thread for this post. Can't decide whether to get my upholstery cleaned or do something about my fast food obesity.
- Cool - thanks Eric
- I pasted some code that does the moving sum in factor. http://paste.factorcode.org/paste?id=569#282
Jump to original thread »
I’ve made some modifications to the table layout used by my experimental smushing store. In particular, I’ve ditched the hashes table, and lumped node hashing in with the literals table. This improves smushing performance as it reduces the number of tables to update (th
... Continue reading »
4 years ago
In some ways using MySQL would have been the way to go, since it provides all the transaction support, remote APIs, etc, that we had to build into Kowari. On the other hand, we could never get it to load data very quickly, even without extensive indexing. I've also found that joining a table onto itself numerous times starts to make most relational databases slow down (including MySQL). Tracing a transitive predicate is an extreme example of this.
Basically It would be great to get all the MySQL features for free, but having a datastore that is purpose built for triples (or quads) seems to be the only way to get really high performance on both loads and queries. Depends on how big you need to scale I suppose.
Out of curiosity, have you considered different models in your system? Are you doing this with different "databases", tables, or something else?