|
Trevor Tessier
|
June 2, 2016 at 12:15 pm
Hello, I have been looking around to see what people are doing for their EE data as it starts to get big. We have been using EE for several years and now the database tables for EE are massive. Slowing the site down from the admin side majorly.
We are considering backing up the data to a completely separate site as an “archive” and then deleting anything older then 1 year.
A) would this be a good course of action? If so, are there any special considerations for deleting old data?
B) would you suggest anything else as a better solution to our issue?
|
|
Josh
|
June 2, 2016 at 1:33 pm
You might consider starting with a new site for a season. This is even simpler if you set up a subdomain or sub site that’s set up for managing events.
|
|
Trevor Tessier
|
June 2, 2016 at 4:19 pm
That would be nice and I wish I could. We have tickets sales from last year for events this year through to the end of the year and it is ongoing as such. We would have no clear break in events that would allow for a clear break in the database which is why I mentioned an archive of the data from a year and later.
|
|
Josh
|
June 3, 2016 at 11:01 am
The end of the year could be a nice clear break then. For example, you could set up a new site now to begin ticket sales for next year.
|
|
Trevor Tessier
|
June 3, 2016 at 11:18 am
Somehow the idea of running two ticketing website over the course of a year is not going to be an idea that will fly very well. This is not a small place with a few events. Tickets are already being sold for next year’s events and general admission. There will never be a clean break. So assuming that a second website is not an option, and going back the original question, do you have recommendation that do not include requiring admin staff to look at and scan from 2 separate sites?
|
|
Josh
|
June 3, 2016 at 12:37 pm
They’d only be scanning from 1 site at a time if all the events for one season or one year where on that one site. I’d recommend the one site per year/season solution over the other ideas that involve going through and deleting data from past events.
|
|
Trevor Tessier
|
June 3, 2016 at 12:47 pm
Hey Josh, I appreciate the solution proposed is the best solution, but it is not going to work for us. I am looking for any other solution ideas.
|
|
Josh
|
June 3, 2016 at 1:06 pm
I’m sorry that the solution I proposed isn’t going to work for you.
|
|
Trevor Tessier
|
June 3, 2016 at 1:48 pm
Hey Josh, don;t get me wrong. Agree and have agreed over this entire thread that the second clean site is the best solution. I’m simply stating that we can not do that so I was hoping for a potential alternate. Or a quick discussion of the complications associated with deleting records. Do we need to delete by event tables, by people tables, by both and if so what will that, for a lack of a better work, screw up. For example I know that user entries are tied to the locations available under the geographic settings.
|
|
Josh
|
June 3, 2016 at 2:32 pm
If you delete events and people records via phpmyadmin, which are in the wp_post table, and it will break the relationships to the other event data that’s stored in the other tables.
So when you delete older Event Espresso data, you’ll want to be sure that you delete the associated transactions, registrations, event meta, and other associated data.
If you’re using one of the more recent versions of EE4 that were released you’ll find that the tables are indexed and even a larger table shouldn’t slow things down.
|
|
Trevor Tessier
|
June 3, 2016 at 3:24 pm
We upgraded from EE3 2 weeks ago to the most recent version of EE4. It was getting very sluggish in EE3. We even moved it to a different server to test. Everything is fast until EE is turned on and we start to filter events and users in the back end. Front end is fine. Adding and editing is fine. Settings no problem. Anything the queries the database, super slow. We have somewhere around 1.5 million records now from what I understand.
|
|
Josh
|
June 6, 2016 at 9:00 am
Yeah you’ll solve the too much data for one database problem if you can make a clean break and start with a new database at some point.
|
|
Trevor Tessier
|
June 6, 2016 at 9:12 am
So Josh, what you are saying is unless I make a clean break (which I can’t) I am SOL?
|
|
Josh
|
June 6, 2016 at 9:37 am
I am not saying that. You are in for a lot more work that is fraught with error if you try to go through and delete the old data though.
|
|
Trevor Tessier
|
June 7, 2016 at 2:08 pm
No other options at all that any of the EE team can think of?
|
|
Josh
|
June 8, 2016 at 10:57 am
One option that another EE team member thought of was building out a script that goes through and deletes the records that are associated with events and registrations that happened over one year ago. The considerations that one would need to take care to make include:
1) Making sure *current* transactions and registrations aren’t deleted.
2) Making sure data isn’t orphaned (e.g. transaction line items do not get deleted that belong to a transaction record that’s not deleted, and vice versa).
|
