Does vBulletin 5 have a true archive?

[Birched]

Does vBulletin 5 have the ability to move old forums to a true archive (different database table), so that large boards can run efficiently but still have older material accessible (possibly more slowly, ideally in with a different view)?

[captainslater]

An archive like it was pre vBulletin 5 is not available.

You can move forums/topics to a channel and limit the viewing and posting permissions.

[Birched]

An archive like it was pre vBulletin 5 is not available.

You can move forums/topics to a channel and limit the viewing and posting permissions.

I am concerned about behaviour with 4+ million posts. In the past, we have had trouble with the model where all posts are stored in one table that is regularly accessed in full to populate vB's data structures. Have any improvements been made to vB's behaviour for larger boards?

[Leinad_r]

Does vBulletin 5 have the ability to move old forums to a true archive (different database table), so that large boards can run efficiently but still have older material accessible (possibly more slowly, ideally in with a different view)?

You mean something like http://community.invisionpower.com/b...rchive-system/ ?
AFAIK there's nothing similar available in vB

[Andy]

You mean something like http://community.invisionpower.com/b...rchive-system/ ?
AFAIK there's nothing similar available in vB

An interesting idea, but I suspect searches would be excluded from the archive. Not sure what good it would be if one can't find the data using the search function.

[Birched]

Yes, definitely, and I've seen this requested in the past for vB. People have gone so far as to buy two licenses and hire coders to make a custom bridge between two forums -- active and archive. For something like this, I would be willing to immediately start recoding our many, many lines of custom code for a new version of vBulletin. Without it -- I'm going to have to create a custom archive solution (unless there's some neat database trick that a slick vB hacker has put in for new boards....), and am not sure what I gain from a new version. I am *very* nervous about the performance issues in vB 4 vs vB 3 for big boards, and worried that vB 5 will have another set of performance hits.

Is there any data on how vB 5 performs for large boards vs previous versions? Has attention been paid to this, or is it just 'a new look with more features'?

- - - Updated - - -

An interesting idea, but I suspect searches would be excluded from the archive. Not sure what good it would be if one can't find the data using the search function.

A separate search for the archive would be fine. An admin option could choose whether to perform both or not when a search was requested. I don't think this is a big hurdle.

[Andy]

A separate search for the archive would be fine. An admin option could choose whether to perform both or not when a search was requested. I don't think this is a big hurdle.

How would it lessen the load on MySQL if you choose to search the archive? Seems like you really want to be be able to search old posts all the time.

[Birched]

There would be a huge performance gain if the default was to not search the archive, and to not look up all the posts in the DB every time.

I don't have a problem with people occasionally searching the archive (whether I'd move to using Google only for archive searches is another question), but I do have a problem with those 'archival' posts being searched every time.

[Wayne Luke]

How posts are stored has changed. How they are referenced and accessed are changed. However the system doesn't include partitioning at this time.

[Birched]

How posts are stored has changed. How they are referenced and accessed are changed. However the system doesn't include partitioning at this time.

What changes were made? Was this done with a view to increase performance for large boards, or were the changes for other reasons (security, adherence to perceived 'good style', ...)?

[Wayne Luke]

What changes were made? Was this done with a view to increase performance for large boards, or were the changes for other reasons (security, adherence to perceived 'good style', ...)?

It was switched to a node-chain system. Supporting more content types easier without having to redo code is one of the primary reasons for the change.

[Birched]

However the system doesn't include partitioning at this time.

Are there any plans to do this (create a true archive of threads and posts that are not traversed during most day-to-day usage of the board) in the future?

[Wayne Luke]

Are there any plans to do this (create a true archive of threads and posts that are not traversed during most day-to-day usage of the board) in the future?

I don't specifically know right now. Should probably get PDO classes in place first.

[Birched]

So now I'm at the point of trying to pick what forum software to go forward with (over the next month or so) before we start rewriting all our custom code, and I have to come back and double check on the answer to this. On one hand, it might be much simpler for us to stay with vB. On the other, with the size of our DB (and a good chunk hiding offline because it was slowing us down too much), a positive answer here would really make a big difference in the decision process.

[Wayne Luke]

Unfortunately, the answer hasn't changed. We haven't currently looked into adding partitioning to the system. The changes to the structure such as node-chain implementation, switching to INNODB tables and other optimizations were done based on the feedback from Internet Brands' DBA. Our parent company manages quite a few large forums and databases. One of the largest being honda-tech.com which has over 45 million posts. The changes were made in regards of scaling these sites up.

Other changes have been implemented for performance purposes as well. These are outlined here: https://www.vbulletin.com/forum/entr...e-Improvements. All of these have been implemented. We're working on further performance improvements as well as SEO changes for the software.