Innobd или MyISAM

[mrprometei]

Добрый вечер Гуру =)

 

Подскажите какую подсистему выбрать для 2.0 с товаром тыс в 12 со временем может вырости до 25 и категориями штук 100 примерно.

 

Начал гуглить и тут столкнулся что кто-то хвалит одно кто-то другое.

 

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

 

[snastik]

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

1. Дальше будет только хуже. Так как базовые конфиги даже на VPS заточены под более менее быструю работу с MyIsam.

2. Если почитаете внимательно референс Mysql про типы таблиц - то там достаточно ясно написано что MyIsam намного быстрее работает с операциями чтения. А чтение - как раз узкое место базы данных в интернет-магазине.

3. Прелесть InnoDb состоит в более надежном хранении данных, за счет транзакционных блокировок. Т.е. шансов покрашиться у таблицы InnoDB меньше. Но. Для того чтобы использовался транзакционный механизм в полной мере, необходимо чтобы база изначально была спроектирована с учетом транзакционных зависимостей между полями таблиц.

А есть ли такой механизм в Opencart? Правильно - нету. Сответственно использование InnoDb для Opencart - это редачйшая глупость. Большей глупостью может быть только кеширование результатов всех mysql запросов всредствами php.

И еще. InnoDb не подддерживают индексы FullText, с помощью которых в Opencart реализован поиск по описаниям товаров и выборка тегов.

[mrprometei]

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

1. Дальше будет только хуже. Так как базовые конфиги даже на VPS заточены под более менее быструю работу с MyIsam.

2. Если почитаете внимательно референс Mysql про типы таблиц - то там достаточно ясно написано что MyIsam намного быстрее работает с операциями чтения. А чтение - как раз узкое место базы данных в интернет-магазине.

3. Прелесть InnoDb состоит в более надежном хранении данных, за счет транзакционных блокировок. Т.е. шансов покрашиться у таблицы InnoDB меньше. Но. Для того чтобы использовался транзакционный механизм в полной мере, необходимо чтобы база изначально была спроектирована с учетом транзакционных зависимостей между полями таблиц.

А есть ли такой механизм в Opencart? Правильно - нету. Сответственно использование InnoDb для Opencart - это редачйшая глупость. Большей глупостью может быть только кеширование результатов всех mysql запросов всредствами php.

И еще. InnoDb не подддерживают индексы FullText, с помощью которых в Opencart реализован поиск по описаниям товаров и выборка тегов.

 

Подскажите пожалуйста на сколько повышается процент возможности краша базы?

И есть ли возможность безболезненно и с наименьшими потерями перевести базу?

 

Сори за вопросы не гуглил, но может подтолкнете в нужное направление =)

[snastik]

Подскажите пожалуйста на сколько повышается процент возможности краша базы?

И есть ли возможность безболезненно и с наименьшими потерями перевести базу?

 

Сори за вопросы не гуглил, но может подтолкнете в нужное направление =)

 

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

[mrprometei]

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

 

Спасибо большое  за то что поделились опытом!

Буду сейчас переводить свое детище =)

[mrprometei]

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

 

 

Я немного ошибся у меня сейчас только несколько таблиц innobd и то связаны с модулем импорта.

На сколкьо я понимаю они на работоспособность влиять не должны верно?

 

И второй вопросик по оптимизации mysql  накопал вот такие данные 

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

 

1. key_buffer = 400M
2. max_allowed_packet = 48M
3. table_cache = 1024
4. sort_buffer_size = 4m
5. read_buffer_size = 4m
6. read_rnd_buffer_size = 2m
7. myisam_sort_buffer_size = 64m
8. tmp_table_size = 96m
9. query_cache_type = 1
10. query_cache_size = 64m
11. thread_cache_size = 16
12. max_connections = 300
13. wait_timeout = 120

[snastik]

 

Я немного ошибся у меня сейчас только несколько таблиц innobd и то связаны с модулем импорта.

На сколкьо я понимаю они на работоспособность влиять не должны верно?

 

И второй вопросик по оптимизации mysql  накопал вот такие данные 

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

 

1. key_buffer = 400M
2. max_allowed_packet = 48M
3. table_cache = 1024
4. sort_buffer_size = 4m
5. read_buffer_size = 4m
6. read_rnd_buffer_size = 2m
7. myisam_sort_buffer_size = 64m
8. tmp_table_size = 96m
9. query_cache_type = 1
10. query_cache_size = 64m
11. thread_cache_size = 16
12. max_connections = 300
13. wait_timeout = 120

 

Все зависит от параметров сервера и входящего трафика.

кроме wait_timeout = 120 все остальные параметры настраиваются индивидуально. (я бы делал wait_timeout и вовсе 10-15 макс).

 

Также открою секрет. Одной настройкой сервера - вы ничего не добьетесь. На простом примере, если у вас широкая ровная дорога но медленная машина - вы быстрее не поедете, чем она может.

 

Настройка магазина под большой трафик и быструю работу - это несколько слоев оптимизации:

• настройка железа
• оптимизация базы
• кеширование повторяющихся блоков магазина
• полное кеширование html
• анализ и устранение узких мест в модулях
• устранение избыточного кеширования (например кеш сеопро на большом количестве товаров, работает на порядок медленнее чем 200-300 атомарных запросов в базу данных). А на примере 250 000 товаров и 10 000 производителях, кеш сеопро укладывает генерацию страницы секунд на 60
• перенос всех повторяющихся тяжелых однотипных операций, не связаннх с фронтендом в cron.

И это я говорю только о лежащих на виду мероприятиях, которые необходимо сделать для уменьшения TTFB страниц.

Есть еще настройка отдачи статики.

 

Реструктуризация подключения внешних скриптов.

Реструктуризация подключения контента из CDN.

 

Использование собственного CDN для изображений.

 

Внедрение дополнительного слоя обработки для индексирования данных (sphinx), для быстрого релевантного поиска.

 

Также нужно проводить аудит по используемым модулям. Есть из ряда вон выходящие примеры, отключения которых дают + (2-3 секунды) скорости загрузки, просто на голом месте практически. Типа глупо написанные модули редиректов. Или кривые формирователи сео-ссылок. Про авторов и сами модули умолчу, дабы не разводить холивар.

 

Также во многих модулях присутствуют свои настройки кеширования, про которые многие забывают (Mega Filter Pro, SeoBlog и так далее).

 

Если совсем глубоко занииматься тюнингом. То можно еще отключать инкрементальный счетчик просмотра товаров, слежение за покупателями, перевести весь контент изображений на фронтенде в Lazy-load. Настроить Since-modified.

 

Вобщем если заморачиваться - можно придумать себе развлечений на пару-тройку месяцев легко.

[ArtemPitov]

не удержался, стало интересно...

 

 

 

• перенос всех повторяющихся тяжелых однотипных операций, не связаннх с фронтендом в cron.

 

можете навести пример, не совсем понятно.

[snastik]

не удержался, стало интересно...

 

 

можете навести пример, не совсем понятно.

карта сайта, yml, импорт товаров, массовые рассылки пользователям

[ArtemPitov]

 

 

Использование собственного CDN для изображений

А проку городить свой ? Щяс много компаний предоставляют готовые серверы

 

 

 

• оптимизация базы

хотел спросить нюансы, но нашел интересное чтиво на ночь https://habrahabr.ru/post/116142/ =) 

[snastik]

А проку городить свой ? Щяс много компаний предоставляют готовые серверы

 

хотел спросить нюансы, но нашел интересное чтиво на ночь https://habrahabr.ru/post/116142/ =) 

 

Готовые сервисы - я и имел ввиду. Иногда использование CDN под картинки, намного экономически оправдано, чем покупка большого пространства на хостинге. + более быстрая доставка контента в регионы.

 

 

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

[ArtemPitov]

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

Хотя бы чтиво подкинет  :oops: