1

I'm currently managing a fairly large and complex Magento2 site. Admittedly, I'm more of a front-end guy. As such, I had a question.

We have 82 stores (one for each corporate customer). Each store also has external company admins who ONLY approve orders for their respective stores. They can only see their store orders when they log in. Shipping and payment methods also vary by store (in that some methods are turned off for certain stores, and have different names).

Currently, each of these is set up as a unique website (with store and store view). So, 82 websites. (ie pepsi.magento.com, coke.magento.com, fresco.magento.com, etc). This number will grow.

We had it stated to us as fact that the database is being duplicated with each new website > store > store view creation. This seems like someone is pulling my chain. Just wanted to ask the question here.

Does creating a new "website > store > store view" add database bloat, resulting in an unscalable model? Is it better (or even advisable/possible) to use categories for each store, with subcategories for the product?

Thank you!

Improve this question
0

yes database data will grow, but there are no performance penalty in it, you will get some issues only if you have no space to expand/scale. proper infrastructure is a key here.

creating a new "website > store > store view" - is correct way.

im sure you have database in multi-server environment?

Improve this answer
4
  • Thank you for the response! When you say "no space" - I'm assuming you are talking about actual server space. It's currently setup on an ec2 instance. Glad to hear we went in the correct direction. I couldn't see how using categories for each store, with subcategories for products would result in any less database size, or any more managable of a database. – jdevo May 13 '19 at 13:36
  • space is more like memory + cpu + ssd speed. if you hit cpu ceiling this will be it. make sure when you get to that point you will have enough cpu power. – MagenX May 13 '19 at 13:44
  • Thanks man - I got ya. ec2 should make it pretty painless to spread the load out... though i'll have some learning to do i'm sure. ;) – jdevo May 13 '19 at 14:21
  • After hearing some more explanation from the developer about our initial requirements, I'm not certain there is any way other than the website > store > store view method. Payment specific to store, language options by store, logos specific to store, category banners specific to each store and so on... – jdevo May 20 '19 at 20:15
0

Data is duplicated for each store view. Each entity value could and probably will end up with a value for each store. And magento has lots of eav entities which can have values that differ between stores. With this many store views there will be a lot of duplicated data. Indexing will be impacted. Everything will be impacted. I'm in no doubt the store will be slow. Using enterprise/commerce/paid edition will help as the database architecture is split and scalabe.

https://devdocs.magento.com/guides/v2.3/config-guide/multi-master/multi-master.html

But that will be expensive. We've not pushed the boundaries with magento 2 yet but magento 1 indexing really struggles with 10 stores.

Personally I would go down the category route.

Improve this answer
7
  • Thanks for the feedback Dominic! We ARE on the Enterprise version, so I'm sure that is helping. I know that at some point we want around 300-400 stores. Given that, it does sound like the category route is best. I'm just uncertain there's any way to maintain separate admins, shipping options and payment options if going the category route. My main fear is just the amount of customization that will need to take place for each category to function as a website - but maybe that is unfounded. – jdevo May 14 '19 at 13:37
  • Using customer groups could be a solution. With a bit of effort can lock payments/shipping among other things down to groups. That would be your store. Performance ultimately depends on the number of products you have. If you have 100's you might be okay. If you have 1000's you are essentially multiplying the data by the number of stores. There are extensions which might get you closer store.webkul.com/magento-multi-vendor-marketplace.html but this project sounds huge (and expensive) – Dominic Xigen May 14 '19 at 19:48
  • I see - we will certainly have over 1,000 products at some point so its looking like the category / customer groups could be a good solution... – jdevo May 16 '19 at 13:52
  • You might find this useful aionhill.com/how-many-products-can-magento-handle – Dominic Xigen May 16 '19 at 14:25
  • Very helpful, thank you! I am still a bit worried about the amount of customization necessary for admin approval by store and the like. – jdevo May 20 '19 at 18:36
0

There are some thing that would require to be considered here:

  1. Reindexation Processes - This gets impacted by each new Website
  2. Catalog Price Rules - Performance gets impacted by each new Website
  3. Database Size and Replication (if any) in case of Single Master, or Database Split mentioned: https://devdocs.magento.com/guides/v2.3/config-guide/multi-master/multi-master.html - This requires more knowledge and skills from Database Admins / SysAdmins
  4. How easy it is going to be while working in Back-Office with 8x Websites - Dropdowns with Website Selectors etc - Simply UX/UI usability of Admin Area

Different Comments

  • Quite a lot of things can be enabled/disabled per Website/Store View Level
  • Run Performance Tests, Review number of Effective SKUs (Unique SKUs x Websites & Store Views on DB Level)
  • Use Supporting Tools/Solutions:
  • RabbitMQ
  • Redis
  • Varnish
  • Async Data Processing (https://devdocs.magento.com/guides/v2.3/performance-best-practices/configuration.html: Asynchronous email notifications & Asynchronous order data processing & Client side optimization settings)

Hope it helps! :)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.