Как обрабатывать 2 миллиона продуктов

Question

Я работаю в веб-компании, и в настоящее время мы используем сильно модифицированную версию OSCommerce в качестве основного приложения для электронной коммерции, но в последнее время к нам обратились многие компании с более чем 2 миллионами отдельных моделей продуктов, которые они хотите продать онлайн.

По существу, мой вопрос: есть ли какие-либо готовые приложения для работы с PHP/MySQL, которые будут обрабатывать эти многие продукты изящно или мне не повезло на этом фронте? Мне нужно создать собственное приложение? Какие у меня варианты?

Будет ли база данных nosql лучше, чем MySQL?

Answer 1

Вы не даете понять, является ли это инвентаризация 2 миллионов продуктов или 2 миллиона отдельных предметов, которые они хотели бы продать. В любом случае, традиционная база данных SQL должна быть в состоянии справиться с этим, хотя это полностью зависит от того, как разрабатывается схема и т. Д. Я не уверен в уже существующих решениях, хотя, хотя я слышал хорошие вещи о Magento.

Answer 2

Вы определенно хотите создать индивидуальное решение, и вы определенно хотите взимать гораздо больше, чем обычно, потому что вам нужно много риска и должной осмотрительности.

Что касается вашей архитектуры, использование NoSQL возможно и есть некоторые веские причины использования NoSQL для электронной коммерции - основная причина заключается в том, что это схематично, и если у вас есть тонна категорий и тонна продуктов, которые все должны продаваться по-разному (т. е. вы продаете компьютеры по-другому, чем продаете часы), потому что атрибуты продукта разные, управление сложностью баз данных становится очень важным.

Это видео покажет вам, что происходит в самом начале в Нью-Йорке. Они используют MongoDB для всей базы данных продуктов. Это видео должно быть реальным сенсационным, как он описывает много подводных камней в MySQL для больших сайтов электронной коммерции, и много игрового меняющегося потенциала NoSQL:

http://engineering.shopopensky.com/topics/mongodb

Что касается обработки платежей, вы определенно НЕ хотите хранить их в NoSQL. Храните своих пользователей, сеансов и платежных данных в MySQL и убедитесь, что они защищены. Вот большая (даже старая) часть на крепежных сессиях в PHP-приложениях:

http://www.troubleshooters.com/codecorn/php/persist.htm

Как примечание, это последнее звено должно помочь вам понять теорию лучше. Большинство фреймворков PHP поддерживают этот тип обработки сеанса из коробки. CodeIgniter, Yii и ZendFramework являются одними из лучших.

Answer 3

По существу мой вопрос - есть ли прекомпилированное PHP/MySQL торговых приложений, которые собираются обрабатывать эти много продуктов грациозно

No. Если есть эти компании с 2000000 продуктами будут использовать его ,

Должен ли я создать пользовательское приложение?

У вас уже есть. Вы начали с OS Commerce в качестве базы и создали над ней собственное приложение. Вы можете не думать об этом как о приложении, но это так.

Какие у меня варианты?

Признайте, что вы будете нуждаться в достойной IT/команда разработчиков гоняться за эту работу, и ослов, если это стоимость и R & D стоит идти после этого нового бизнеса.

Будет ли база данных nosql лучше, чем MySQL?

Нет. Но база данных MySQL не была бы лучше, чем база данных «nosql».

Answer 4

В зависимости от бюджета Magento Enterprise может быть хорошим решением для вас. (Я не говорю, что продать это, я не партнер). Вы могли бы либо заархивировать решение, либо помочь хостинговой компании. Rackspace является ведущим партнером хостинговой компании и отлично сочетает эти решения. В игре много цифр, таких как максимальные одновременные соединения, просмотры страниц в час, транзакции в час и т. Д. Вам нужно взглянуть на то, что имеет как минимум 2 сервера MySQL (репликация master/slave) и несколько интерфейсные серверы за балансировщиком. Вместо Apache загляните в nginx. Вы также захотите проверить apc & memcached для кэширования. Подобная установка будет проходить долго. При правильной настройке Magento Enterprise легко справляется с этим множеством продуктов. Важно помнить, что настраиваемое решение не нужно разрабатывать - оно должно быть инженером.

Answer 5

В ответ на предложение Magento Enterprise мы недавно внедрили это приложение для нашего сайта, на котором размещено приблизительно 150 000 единиц SKU. Мы тоже переходим от широко распространенной версии osCommerce. Наш опыт был одним из разочарований и задержек проекта из-за медленной скорости работы системы предприятия, а также отсутствия документации для ее реализации. Из-за этого мы фактически не смогли использовать большую часть функциональных возможностей корпоративного выпуска.

Приложение печально известно из-за отсутствия документации и медленного ответа команды поддержки Varien, которую мы испытали из первых рук. Система шаблонов, кажется, только частично завершена и не особенно хорошо продумана. Один из ответчиков на ваш вопрос, Алан Сторм, на самом деле был спасителем нашей команды с его хорошо написанными учебниками и щедрыми ответами stackoverflow.com.

Моя рекомендация - провести обширное исследование на платформе Magento Enterprise - это не то же самое, что версия сообщества. Как сказал Боб Броди выше, требования и настройки сервера не для слабонервных, и они не стоят недорого. Изучите доступные варианты повышения скорости - вам понадобятся они, накладные расходы сервера, рассмотрите кривую обучения и дополнительное время, которое она добавит к временной шкале проекта. Magento значительно отличается от osCommerce - и, прежде всего, найти надежного, опытного веб-хостинга прежде чем вы заплатите лицензионный сбор в размере 12 000 долларов США.

Answer 6

Мне просто интересно, если кто-нибудь подумает, что это настроение может это сделать. сообщество magento с обратным прокси (возможно, лаком) и memcached в качестве кеша приложения. без динамического контента на страницах продукта (поскольку он может отображаться при пользовательском взаимодействии с кэшированным ответом), чтобы поддерживать запросы приложения до абсолютного минимума. с использованием серверов nginx с балансировкой нагрузки.

Кроме того, вы можете реализовать более структурированные процедуры обслуживания и оптимизации базы данных в качестве отдельного приложения.

Возможно, вы могли бы сделать что-то довольно радикальное, но довольно дешево (я думаю, что у парней с 2 ​​миллионами продуктов есть другая идея дешево для вас и для меня), измените модули продаж, налога и продаж на что-то менее гибкое, но более эффективным.

i dunno кажется лучшим способом для меня. платя за magento EE каждый год против первоначального расхода до похвастаться производительностью.

Answer 7

Один из лучших ответов на такого рода нагрузки продукта (и, между прочим, один мы используем) является https://magento.stackexchange.com/questions/459/running-magento-in-an-aws-environment

Мы бежим пользовательского Magento Community сервера (1,9) на веб-служб Amazon beanstalk с RDS для продуктов, redis для кеша & S3 -> CDN для медиафайлов, связанных с Magento. Это первые дни, но пока мы не нашли реальных проблем. Расчетное время разработки ... может быть, через неделю или около того перейти от VPS к локальному mysql/cache/apache/php?