пытаясь понять схему Ebay

Question

Я хочу создать сайт, похожий на ebay (его мини-версия с использованием стека LAMP в качестве базовой установки, я думаю, или, может быть, вы, ребята, предложите что-то еще), и мне интересно, как они создали свою систему. Больше всего я не понимаю, как они управляют своими категориями. У них есть один код поиска и, вероятно, один код для размещения товаров на продажу, а также один код для отображения товаров. Но как они создают / хранят шаблон для каждой категории? Кроме того, какова структура базы данных за их настройкой? И, наконец, у них так много категорий и подкатегорий, скажем, кто-то размещает элемент внутри (что, скорее всего, процесс ebay использовал для добавления категорий) Моторы -> Запчасти и аксессуары> Гоночные запчасти

Через несколько дней люди запрашивают дополнительные подкатегории в разделе "Racing Parts":

• Аксессуары
• Автозапчасти для гонок
• Крепеж, жидкости и прокладки
• Kart Racing Parts
• Оборудование для обеспечения безопасности
• Другое

Так что теперь у них есть новый уровень для гоночных деталей, который выглядит следующим образом:

• Моторы -> Запчасти и аксессуары> Гоночные запчасти> Аксессуары
• Моторы -> Запчасти и аксессуары> Гоночные детали> Крепеж и т.д ..

Что происходит с существующими списками, которые были размещены до добавления новых подкатегорий? они перемещены в подкатегорию? Вызывает ли eBay новые элементы для перечисления в подкатегориях и удаляет их старую форму публикации "Racing Parts"? Если они это сделают, то, что, если пользователь пропускает категорию, пользователь может запутаться и не публиковать сообщения, и тогда ebay потеряет деньги. И если они не удалят общую форму публикации Racing Parts, то пользователи будут публиковать в категории, которая является слишком общей, и теперь станет трудно использовать опцию «Уточнить поиск», потому что все формы имеют разные поля, которые может фильтровать ebay. на.

Если у вас есть идеи, пожалуйста, дайте мне знать. Я очень смущен тем, как они это делают, и очень хотел бы понять :)

Answer 1

Вот Рэнди Шуп по архитектуре Ebay

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

Из его стенограммы чата

"Это даже реляционная база данных или она действительно другая?

Это совсем другое. Это поисковая система, как Google или Yahoo! разработанный теми же людьми, которые разработали поисковую систему AltaVista, и, как и многие другие поисковые системы, он разработан по схожим принципам, а именно, что это инвертированный индекс. Есть набор документов с идентификаторами, ключевые слова индексируются в эти документы, и операции запроса выполняются путем очень простого пересечения списков или векторов этих ключевых слов, и есть намного больше подробностей о том, как это работает. Задача для поисковой системы в стиле eBay, как и в стороне, заключается в том, что наши пользователи ожидают, что поисковая система будет обновляться практически в реальном времени. Когда кто-то делает ставку на товар, который меняет цену, а цена - это фильтр, к которому люди очень интересуются. Так что на самом деле это означает, что стиль - своего рода классический стиль веб-поисковой системы «вы создаете индекс в своего рода пакетном режиме и затем загружаете его в поисковую систему» ​​- это то, что на самом деле не работает для нас. Это должно быть намного больше в реальном времени. Поэтому я немного расскажу о том, как эта система реального времени работает в моем разделе асинхронности, но в любом случае, чтобы закончить мысль о масштабируемости для поиска, идея заключается в том, что поисковая система может быть разделена по горизонтали. Таким образом, существует общий поисковый индекс любого размера. Мы делим его на куски по десять, двадцать, шестьдесят или сто, и таким образом делим инфраструктуру. И затем у нас есть часть агрегатора, которая теперь разбрасывает / собирает все эти разные части индекса. Поэтому кто-то запрашивает «iPod», «Mickey Mouse» или «Wii», и агрегатор отправляет запрос каждому из разных разделений или сегментов, возвращает результаты, объединяет их и отправляет обратно пользователю. "

Answer 2

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

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