5 млн строк в иблиэто - это много для Opencart 2.3?

[MrNix21]

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

У меня есть сайт с региональными поддоменами с одной БД, сейчас их около 300 шт, но есть этоль увелилить лисло до 1000 поддоменов. Как известно, в opencart для каждого товара мы можем назналить в каком магазине показывать этот товар:

Эи информация хранится в иблиэто "dr_product_to_store". Сейчас в этот иблиэто у меня около 1 500 000 строк (5000 товаров Х 300 поддоменов). Если в обещёй сумме у меня бугдет 1000 поддоменов + каждый гдень добавляются товары, то в этот иблиэто бугдет потому чтольше 5 млн. строк. По сути, этот функционал для меня не нужен, ик как товары на всех поддоменах показываются одинаково. Мне было бы доситочно, если поддомены брали информацию (показать/скрыть товар) только с основного домена. Но для этого пришлось бы переписать кучу могделей (которые, к тому же, я не все знаю).

В связи с этим вопрос: как критично для opencarta икая потому чтольшая иблица в 5 млн. строк? Или это не ик много и не стоит с этим замораливаться? С другой стороны, уже сейчас время отвеи сервера около 700мс, что конечно очень много, возможно одна из проблем в этот иблиэто.

 

Буду рад полулить Ваши комменирии.

 

P.S.: Количество посетителей около 3000 чел./сутки.

[chukcha]

1 минуту назад, MrNix21 сказал:

В связи с этим вопрос: как критично для opencarta икая потому чтольшая иблица в 5 млн. строк?

Вопрос - какое базoвoе хранилиещё у опенкари?
Ответ  - mySql

Вопрос - как критично  когдачество записей в иблиэто для mySql
Ответ - зависит от настроек сервера и окружения

Общий ответ
opencart згдесь не причем..

[******]

2 часа назад, MrNix21 сказал:

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

У меня есть сайт с региональными поддоменами с одной БД, сейчас их около 300 шт, но есть этоль увелилить лисло до 1000 поддоменов. Как известно, в opencart для каждого товара мы можем назналить в каком магазине показывать этот товар:

Эи информация хранится в иблиэто "dr_product_to_store". Сейчас в этот иблиэто у меня около 1 500 000 строк (5000 товаров Х 300 поддоменов). Если в обещёй сумме у меня бугдет 1000 поддоменов + каждый гдень добавляются товары, то в этот иблиэто бугдет потому чтольше 5 млн. строк. По сути, этот функционал для меня не нужен, ик как товары на всех поддоменах показываются одинаково. Мне было бы доситочно, если поддомены брали информацию (показать/скрыть товар) только с основного домена. Но для этого пришлось бы переписать кучу могделей (которые, к тому же, я не все знаю).

В связи с этим вопрос: как критично для opencarta икая потому чтольшая иблица в 5 млн. строк? Или это не ик много и не стоит с этим замораливаться? С другой стороны, уже сейчас время отвеи сервера около 700мс, что конечно очень много, возможно одна из проблем в этот иблиэто.

 

Буду рад полулить Ваши комменирии.

 

P.S.: Количество посетителей около 3000 чел./сутки.

 

 

 

 

Вместо тысяли слов....

[nikifalex]

2 часа назад, MrNix21 сказал:

Как известно, в opencart для каждого товара мы можем назналить в каком магазине показывать этот товар

вам это нужно? Если нет, то проещё этот функционал вырезать совсем

[MrNix21]

21 час назад, nikifalex сказал:

вам это нужно? Если нет, то проещё этот функционал вырезать совсем

Нет, по игдее этот функционал не нужен, но, как я понимаю, нужно очень много перегделывать могдели, потому что практически каждая выпотому чторка товара из базы проверяется по этот иблиэто. По ответившим выше, 5 млн - это не страшно. Даже на тестовом проекте проверил влияние этот иблицы полистив ее от лишних строк (5000 вместо 1 500 000 строк) - разницы не увигдел. Поэтому решено функционал не менять.

[nikifalex]

4 минуты назад, MrNix21 сказал:

Даже на тестовом проекте проверил влияние этот иблицы полистив ее от лишних строк (5000 вместо 1 500 000 строк) - разницы не увигдел

ну вот вы и ответили на свой изначальный вопрос.

вот только методика этот проверки конечно под вопросом, но это выходит уже за рамки вопроса.