MySQL Database Size?

joshcUK

My host has a 1GB limit on the MySQL Database size.
What is the typical size of a Vanilla Forum that has thousands of posts?
How likely is it to go over the limit?

Linc

By the time your data gets to 1 GB you wil have left a host with those kind of crappy limits anyway. It takes a LOT.

GaryFunk

It would take over 1 million records to grow that big.

joshcUK

That's what I needed to know, thanks for your help.

Gillingham

My activity table alone is 1.7G because activity is mostly terrible and has many many duplicate activities. Note that the entire forum is only 2G. 85% of the database is nothing but entries in GDN_Activity

Anonymoose

@Gillingham said:
My activity table alone is 1.7G because activity is mostly terrible and has many many duplicate activities. Note that the entire forum is only 2G. 85% of the database is nothing but entries in GDN_Activity

Yup. And still looking on a way to disable GDN_Activity...

peregrine

@Anonymoose

One could certainly write a plugin to purge certain activities type from the activity table prior to a certain date; or disable writes to the table for certain activities.

joshcUK

@Gillingham and @Anonymoose - How many posts are in your forums?

Anonymoose

50K. I don't have an issue with the activity table yet, but it is getting to the point that adding extra plugins that "cause more activity and lookups" is going to require an upgrade of server resources due to the extra overhead that seems to be there ever since upgrading to Vanilla 2.

Slimming down Vanilla, perhaps with a non-activity version, is definitely a better solution that paying for more resources.

Gillingham

364,913 comments, 866 threads

Anonymoose

I'm at about 4K threads.

Linc

Version 2.1 reworks the activity system. I can't promise it uses less records, but it does increase query efficiency in many places.

x00

why not purge the activity? you don't need to keep all those records, you can set up a cron job.

Activity mostly drivel that we have been conditioned to care about.

• "brushes teeth"
• "goes to bed"

Linc

If you're going to prune, do it carefully and selectively based on ActivityType. Otherwise you'd lose anything people wrote on each others walls.

peregrine

@Lincoln - what about putting a if (C statement and matching config statment where it adds activity in general functions and the other two or so places.
or even an event.

psuedo-

addActivity function

   $UseActivity = C(someserializedlistofactivityid);

   if (in array (blah blah) == ActivityID)
        return

since some people don't even use activity or want it viewed. it would save on database writes period - faster???

Same goes with a conditional and matching config statement right before the edit/delete log gets written (alot of people don't even know they have one and it takes up a tremendous amount of space if you allow editing of comments.
It would only be two lines of code.

Linc

@peregrine said:
It would only be two lines of code.

Write 'em, test 'em, and send a pull request.

peregrine

I'll have to investigate pull request - but I can certainly post the code in a bit.

Linc

Emphasis on the "test" part.

Personally I am terrified at the potential bugs & consequences from aborting some activity types arbitrarily.

Anonymoose

@Lincoln said:
Version 2.1 reworks the activity system. I can't promise it uses less records, but it does increase query efficiency in many places.

Excellent.

peregrine

As far as the Activity Table - you've sufficiently scared me off to post anything for public consumption. And the edit/deletelog functions are more involved.

However for the edit/delete log table in 2.0.18.4. It works for me. Your mileage may vary....

/applications/dashboards/models/class.logmodel.php

 public static function Insert($Operation, $RecordType, $Data, $Options = array()) {
 
$EditDeleteLog = C('Garden.EditDeleteLog',TRUE);


......  intermediate code in function

 } else {
           //added if statement here  
            if ($EditDeleteLog == TRUE) {
                $LogID = Gdn::SQL()->Insert('Log', $LogRow);
            }
         }
      } else {
          //added if statement here        
          if ($EditDeleteLog == TRUE) {
               $LogID = Gdn::SQL()->Insert('Log', $LogRow);
         }
      }
      return $LogID;
   }

for config.php

// if the following config statement exists in config.php - logging will be disabled. with changes to the function above.

$Configuration['Garden']['EditDeleteLog'] = FALSE;

x00

@Lincoln said:
If you're going to prune, do it carefully and selectively based on ActivityType. Otherwise you'd lose anything people wrote on each others walls.

Which isn't really the issue, unless they are spamming the activity.

Frankly not pruning your activity if you know how, is madness (or koshing it all together).

Keeping all that pointless data after months. Why on earth, would you do that?

Especially with 2.0 it is a massive waste of resource, it is a waste of resource in general.

I understand the convenience of having recent activity, but after a while the cons outweigh the pros. Get a decent search. They can also look through their old posts, the standard way.