Pros/Cons of Voat Cost Saving Measure: Compress comment chains into a single db record
5 18 May 2017 02:33 by u/speakoutforamerica
Obviously, we need to think outside of the box and I was trying to but I was thinking currently the Voat api has a bunch of small requests to chain comments how we view them.
What if comments were all saved into their parents record. So (cutting out a bunch of junk( instead of
Comment table:
CommentID PostID ParentCommentID Comment
1 2 NULL "I am a parent comment"
2 2 1 "I am a child comment"
We devised some way (obviously more work involved to not lose out on the functionality of who said what) that is was saved like so:
Comment table:
CommentID PostID Comment
1 2 NULL "I am a parent comment -> I am a child comment"
This of course potentially removes tons of features like voting up/down comments, reporting individual comments, clicking into a commentators profile but honestly, those are mostly things attract opportunities to censor or dox. I am not saying this is perfect or cool in any way but couldn't this be a way to cut costs drastically instead of just shutting down? Anyways what are some pros/cons of this.
6 comments
0 u/speakoutforamerica [OP] 18 May 2017 02:35
Please post pros here.
0 u/speakoutforamerica [OP] 18 May 2017 02:37
0 u/speakoutforamerica [OP] 18 May 2017 02:36
Please post cons here.
1 u/speakoutforamerica [OP] 18 May 2017 02:39
0 u/greyhat399321 24 Jun 2017 14:58
Celko nested sets would be most efficient and maintain the ability to infinitely nest records. The only cost is recalculation on the upsert...
If I were to do this, I'd have a key for the thread ID the post goes with and then have a left/right val for each thread:
https://en.wikipedia.org/wiki/Nested_set_model
You should also probably consider whatever model is in place for the voats/karma/comment relationships as that data may be stored discretely to avoid cheating as much as possible since everyone only counts one vote per item.
0 u/WhatWouldOdinDo 06 Jul 2017 02:34
I think it's a really bad idea to consider doing this. You're actually gaining nothing via this method and may actually be introducing significant processing overhead. You would be better off setting up a caching mechanism and using redis or memcachedb to store prerendered html snippets for the most often accessed parent comments, which itself is pretty substantial. I won't delve into those details though.
I'll deal with your pros one-by-one.
Unless you're caching, as I've already mentioned, then you'd likely end up with higher load. Not on the DB, mind you, but on the web server from parsing the comment(s) string. Sure, you probably have a plan to make it as well-formed and regular as possible to work around that, but you're still taking processing from one place and putting it where you really can't afford it. Very likely, you could get better improvement by optimizing the query grabbing the comments. And yeah, I do mean one and only one query.
Are you sure about that? Have you calculated the amount of disk space you'd save per record on this? How about the amount you'll need trying to shoehorn the old features back in when the community calls you a niggerfaggot kike cock muncher for removing features to try and save a few bytes like they're fucking shekels?
Yeah, you're removing functionality that the site needs, which the community will not stand for, with only the vague notion that this will actually help. Seriously, I'm pretty sure that bandwidth is more of a problem than saving a little disk space.
If space is a real concern, maybe we should play with the idea of deleting comment threads that don't meet an upvote threshold after 3 months until you come back with numbers that can be checked. Here are data type sizes in SQL Server to help you get started. If voat is using MySQL or something similar at this point then I'm sure a similar table is also available.