Paul M Foster wrote:
On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote:
Let's go back to my 1st e-commerce example. The manufacturers list is
about 3,700. The categories is about about 2,400. The products list
is right now at 500,000 and expected to be around 750,000. The site
is only in English. The store owner wants to expand and be I18n:
Chinese, French, German, Korean, Spanish. You see how big and complex
that database gets? The store owners want to have this happens when a
customer clicks on a category:
* show all subcategories for that category, if any
* show all products for that category, if any,
* show all manufacturers, used as filtering, for that category and
subcategories
* show price range filter for that category
* show features & specifications filter for that category
* show 10 top sellers for that category and related subcategories
* the shopper can then select/deselect any of those filters and
ability to sort by manufacturers, prices, user rating, popularity
(purchased quantity)
* have the ability to switch to another language translation on the fly
* from the moment the shopper click on a link, the response time (when
web browser saids "Done" in the status bar) is 5 seconds or less.
Preferably 2-3 seconds. Will be using stopwatch for the timer.
Now show me a website that meets those requirements and uses PHP, I'll
be glad to support your argument about PHP w/o threads :) BTW, this
is not even enterprise requirement. I may have another possible
project where # products is over 10 million easily. With similar
requirements when the user click on category. Do you think this site,
which currently isn't, can run on PHP?
That strikes me as a pretty stiff target, no matter how you look at it.
You effectively want 6 major queries at once, plus response in under 3
seconds on a 750000 row product table. I'm not sure I could produce that
kind of performance in C at the command line. (I'm sure some smart guy
on the list will say he can do it in 2 seconds flat over a 10 Base 2
network with teletypes and acoustic modems.)
I'm not sure why you consider this 6 major queries. To show all
sub-categories for a category is a major query only if you need to
recursively gather sub-categories. Admittedly that would be a slow hit
to the database server on first request, but afterwards one would expect
the tree to be cached so the next request would be very fast due to
priming of the cache.
Show all products for a category should be quite fast, the category
would be associated with an integer ID upon which I would presume
indexing has occured. Presumably "show all" means show all products in a
paged manner. The same principles should show true for manufacturer.
Price range also plays nicely with indexes. Features and specifications
may be a biut of a hump, but it depends. It's hard to say exactly what
is meant by this filter.
The top 10 sellers might be an issue, but I don't see why a cron job
can't handle updating top sellers information so that this is an
indexable field.
I'm not sure why language translation would be an issue. Presumably if
you have support for one, switching to another requires the same legwork
with different pants.
Also, it's notable that all of the search data is based on need to read
only. This screams replication to me if the server is very busy.
The big thing about indexes is that the more rows you add, the time to
retrieve a particular indexed row only grows logarithmically.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
