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

Question

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

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

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

Answer 1

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

Нет.Если бы были эти компании с 2 000 000 продуктов, которые бы использовали его.

Мне нужно будет создать собственное приложение?

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

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

Согласитесь, что вам понадобится приличная команда ИТ / разработчиковгоняться за этой работой и оценивать, стоит ли эта стоимость и НИОКР заниматься этим новым бизнесом.

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

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

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

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

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

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

Answer 4

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

Answer 5

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

Мы запускаем пользовательский сервер сообщества magento (1.9) в среде beanstalk Amazon Web Services с RDS для продуктов, redis для кэша и S3 -> CDN для носителей, связанных с Magento. Это первые дни, но мы до сих пор не нашли никаких реальных проблем. Предполагаемое время разработки ... может быть, неделя или около того, чтобы перейти с VPS с локальным MySQL / кеш / apache / php?

Answer 6

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

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

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

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

Answer 7

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