Very Large Store

[jimski]

I have a very large store with about 450,000 registered customers and 2,000 products. I'm not happy with my current platform and would like to move to another cart that has open source. I ruled out Zencart and OSC because their code was written in medieval times.

1. Can cubecart handle 450,000 users with the expected growth to 3,000,000 users and 5,000 products.

2. Can cubecart run on Postgres. I currently use MySQL but would love to ditch it and move to Postgres

Any advice would be appreciated.

[bsmither]

1. I suppose that depends on the database. MySQL, being written for enterprise type environments, is certainly capable of millions of records -- the schema properly having been set up with appropriate indexes and such. One can make a good case that CC6's schema is not optimized and will suffer with that amount of storage. Certainly, in admin, do not bypass the pagination and ask to see All Records. With proper pre-game strategy, I think CC6 can handle a large-sized database.

2. Not currently. One would need to write a database handler for Postgres. CC6 knows about MySQL (and MySQLi). A few years ago, I tried writing a handler for MS SQL Server. At the time, there were a few unimplemented querys and I gave up (getting the last insert id was one problem).

[havenswift-hosting]

5000 products is not large at all, we have clients with greater than 250,000. I also don't see any issues with that number of registered customers - MySQL can easily handle many millions of records without any problems and a reasonable amount of work has been done over the last year or so adding missing indexes although some optimization can certainly still be done. More important questions would be the number of concurrent users, number of orders being taken and how well the hosting / database server is configured

[jimski]

Thank you for your replies

@bsmither  I can live with MySQL if Postgres is not available but can the CC application and particularly db queries handle large number of clients and orders. For example, in the shopping cart that I'm currently using, in the admin section, searching for orders take sometimes 30 seconds before the result is displayed. This is caused by multiple joins on large tables in SQL queries. Many carts suffer this problem. This is just one of very many problems with my current application so instead fixing it I decided to find a better solution.

@havenswift-hosting    The number of clients is by far more important to me than number of products. My target is 3,000,000 so unfortunately 250,000 is not a good reference point. Most carts break down in the admin section when searching through orders and users.

What is the largest shop ever build on CubeCart cart in terms of number of users.

 

[bsmither]

CC6 will make this query when fetching a chunk of 20 order summaries:

SELECT
  SQL_CALC_FOUND_ROWS 
  CubeCart_order_summary.*, 
  CubeCart_customer.type, 
  CONCAT(CubeCart_order_summary.last_name, CubeCart_order_summary.first_name) AS `customer`, 
FROM `CubeCart_order_summary` 
LEFT JOIN `CubeCart_customer` 
ON CubeCart_order_summary.customer_id = CubeCart_customer.customer_id 
ORDER BY `order_date` DESC LIMIT 20 OFFSET 0;

(See the CubeCart demo admin section to view the list of order summaries and how the data is displayed. The relevant extraneous data is queried only when viewing the details of that order summary.)

There is an index on `order_date`.

So, in this case, not complex at all.

And, of course, if everything is chunked in groups of 20 records in a recordset, it should not matter how many total records there are.

I have come across a few "very complex" queries, but they all (IIRC) are after one particular record.

CC6 uses a Database wrapper class that extends an appropriate connector class.

Therefore, wherever data is needed, the parameters of a query are sent to the Database class. For example:

Database->select('CubeCart_inventory', '*', $where, $order, $per_page, $page);

There, things are sanitized and verified, and the actual SQL statement is built. The SQL statement then goes to the connector class where the appropriate PHP commands are used (the mysql() family or the mysqli() family of commands).

 

[jimski]

10 minutes ago, bsmither said:

There is an index on `order_date`.

So, in this case, not complex at all.

Yes, this doesn't look too bad.

There aren't too many choices when it comes to Open Source carts. I just looked at OpenCart and the code looks little messy but it seems to support Postgres. Though I'm allergic to messy code

[bsmither]

"I'm allergic to messy code."

Get out your antihistamines!

CC code is not "messy", per se. But someone who suffers from rightius coderitis may have to learn some new levels of tolerance.

[jimski]

CubeCart code is pretty clean. There are a few spots that can use some cleaning but overall looks good.

The bigger question is can CubeCart handle a very large site.

What is the biggest website using CC in terms of registered users and orders?