Как организовать серверную часть магазина на 1 миллион товаров?

Question

[Русдан Киба]

В общем есть магазин, расположени на 1 VDS, уже более 300 тыс. товаров. Хотим расти. Как лучше организовать серверную часть. Понятно что на 1 сервере уже не поместимся, да и хотелось бы базу разнести нанесколько серверов чтоб ускорить обработку. В какую сторону копать, где может есть гайды?

Answer 1

[Назар Мокринский]

Ничего не понятно. Кто сказал, что не поместитесь?
Вы с мониторинга начните и статистики, а потом делайте выводы по ситуации.
А то пальцем в небо Понятно что на 1 сервере уже не поместимся...

Comments

[Русдан Киба]

Я не в плане места имел ввиду. Очень большая база, потому медленно выполняет запросы. С отключенным кешем может секунды 2.

[Руслан Федосеев]

а вы еще задержек в код подобавляйте... а то че только кеш отключили...

[Макс]

Русдан Киба: поддержу Руслан Федосеев - начните с анализа узких мест текущей БД. 300 000 - не то число, ради которого надо срочно изобретать сложные решения. Хотя Вы опустили вторую, не менне важную характеристику сайта - количество посетителей.

[Русдан Киба]

Макс: Посетителей пока в пределах 2000 но планируем около 7000.

[Макс]

Русдан Киба: это всего/в день/в час/в что-то еще? хотя в любом случае начать стоит с анализа текущего состояния БД. 2 сек на запрос и 300 000 строк - вероятнее всего у Вас либо какие-то немерянные JOIN-ы, либо отсутствие/неверные индексы, либо крайне криво сконфигуренный MySQL. Ну или крайне унылое железо. Включите лог медленных запросов, запустите mysqltuner - проанализируйте, из-за чего и какой запрос выполняется так медленно.

Answer 2

[Влад Животнев]

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

Просто так взять и размазать CMS на пачку серверов получается достаточно редко (и достаточно дорого).

И это я не говорю про то, что "300к товаров" - вообще ни капли не характеристика для планирования инфраструктуры проекта.

Answer 3

[xmoonlight]

Оперативки x2 добавьте и все. Остальное судя по-всему - сделано более-менее нормально.

Answer 4

[beduin01]

Посмотрите в сторону ArangoDB. Как минимум затык по БД уберете.

Comments

[Русдан Киба]

К сожалению проект уже готов MySQL

Answer 5

[Александр Прядко]

Все зависит от того на сколько активно пользователи работают с номенклатурой и какие характеристики необходимо обрабатывать. 1 миллион SKU для любой современной базы данных обычное явление. На 99% информация по номенклатуре - это редко изменяемая часть, которая может кешироваться, под остальное (наличие и цены) много ресурсов под 1 миллион записей не требуется.