Single Table For Subscribers

Spiro

Member
Hi,

I have just recently purchased and setup Mailwizz. I have just looked through the database structure and have a concern that you may be able to put to rest, or at least elaborate on?

We service probably around 100 clients with lists in the region of 5,000 to 8 million subscribers. This potentially means that i might have close to 100 million subscribers in the system. Please could you give me examples of how you query this table, and whether there would be speed implications with this table if it grew to this size.

Have you got clients whom are sending this type of volume?

Any insight would be great.

Thanks,
 

Spiro

Member
I have seen in other systems they allocate lists to individual tables, rather than dumping it all in one.
 

twisted1919

Administrator
Staff member
Big data will always pose problems regardless if you store it into one table or multiple tables.
As you can imagine, and as it makes sense, having 100M records in a database table will make it hard to query, even if we use proper indexes in the sql statements, it's just the way things works.
As for having multiple tables to store the same data... if you look at the current mailwizz database structure, you'll notice that this is impossible without having to duplicate several other tables and i really think that ending up with hundred of tables into your database is a real mess that should be avoided at any price.
If you are concern about this, you can always have your big clients on separate installs, after all mailwizz is pretty cheap to allow you this.
Hope it helps.
Thanks.
 

Spiro

Member
Have you done any load testing on these types of numbers? Do you know when/if it does become a problem?

Sharding should definitely take care of large database issues!
 

Jamie Whittingham

Active Member
I am facing the exact same issue.

Here is the planned solution / path we are going to take.

Server's with RAIDed SSD drives to speed things up, cron job to check / re-index each table once a day

Now using MySQL InnoDB as it offers ROW level blocking unlike the default MyiSAM which runs on table level blocking which slows performance.
 

Spiro

Member
Hey Jamie,

Please let me know how this works out for you! I would be interested in implementing this too.
 
Top