Оптимизация Базы данных
Уважаемые создатели плагинов, оптимизируйте свои таблицы в базе данных и запросы к ним!
Рекомендации:
- При создании таблиц, старайтесь избегать Тип TEXT, хотите использовать и нужно, лучше это выносить в отдельную таблицу. Соответственно со связью ID, Text, а в рабочей таблице по каким делаете выборки избегайте TEXT.
Тип TEXT вмещает в себя только 64 Кб. Для того, чтобы вместить более объемные тексты, нужно использовать LONGTEXT. TINYTEXT = 255 (2 8−1) bytes TEXT = 65,535 (216−1) bytes = 64 KiB MEDIUMTEXT = 16,777,215 (224−1) bytes = 16 MiB LONGTEXT = 4,294,967,295 (232−1) bytes = 4 GiB !!! Причем некоторые по умолчанию ставят Longtext, прямо в своей служебной таблице.
В версиях MySQL до 5.0.3 VARCHAR была ограничена 255 символами, однако в более старших версиях ограничением является 65535 символов.
2. Старайтесь избегать множественных Join, нужны слияния, стройте запросы с использованием временных таблиц, т.к. чем раньше ваш запрос освободит БД, при множественном слиянии, тем раньше к нему, получат доступ остальные, стоящие в очереди, по блокировкам описал ниже.
3. Старайтесь избегать Select *, выбирайте из ваших таблиц, только то, что будете использовать!
Это крайне важный аспект, т.к. при MyIsam - таблице, она блокируется для остальных, пока вы не получите результат. При использовании InnoDB - блокировка осуществляется непосредственно при обращении к ячейке.
4. По возможности, держите в голове, что скоро будет переход на InnoDB, повсеместно, и то что MyIsam, совсем не будет, соответственно, полнотекстового поиска, надо избегать, у меня есть в другой теме пример, построения более короткого индекса при типах VARCHAR
CREATE INDEX `url` ON shop_product (url(10));
Соответственно аналогичным образом, можно ускорять и обращения к индексу 1С. Вы должны понимать что поиск в БД осуществляется по технологии BTREE, т.е. дерево, по индексам, соответственно старым методом деления пополам.
P.s. На этом пока все, если у кого то есть еще рекомендации, о оптимизации БД, пожалуйста пишите и комментируйте.
39 комментариев
Я сознательно, не стал перечислять, плагины, которые используют данные ошибки, и их таблицы, часто занимают размер, больше чем остальная База Данных, надеюсь на вашу сознательность и внесенные корректировки.
P.s. Часто создатели таких творений, плохо реагируют на критику!
можно узнать где когда разработчики платформы Webasyst сие сказали? Или это просто копипаст и к платформе отношение у этого текста косвенное? Если так, то это не есть хорошо. Да и перед тем как паучать разработчиков, может представите свои плагины и приложения, мы изучим, вдруг вдохновимся?
А то, если честно копипастить шибко большого интеллекта не требуется. Будет как с удалением плагинов...
Развитие Mysql, кидаю ссылку, поддержку MyIsam в ближайшем времени прекратят!
https://dev.mysql.com/doc/refm...
https://www.opennet.ru/opennew...
В находящейся в разработке ветке CУБД MySQL 8.0 (версия 8.0 будет выпущена следом за 5.7, вместо 5.8) представлены изменения, ограничивающие использование хранилища MyISAM. Поддержка MyISAM пока сохраняется, но использование данного хранилища в самом MySQL практически прекращено. В частности, после реализации в MySQL 8.0 нового механизма хранения системных данных, таблицы MyISAM больше не используются для хранения системной схемы (БД mysql) и теперь невозможно просто скопировать таблицы MyISAM на работающий сервер MySQL (скопированные таблицы не будут определены, в отличие от таблиц InnoDB, для которых можно выполнить "ALTER TABLE … IMPORT TABLESPACE"). Возможность создания таблиц с опцией "engine=MyISAM" сохранена.
Мне очень жаль, что разработчики, не знают что происходят с движками, и то что общероссийский стандарт будет PostgreSQL. Мало того я более чем уверен, скоро хранение персональных данных вне Российской СУБД, будет запрещено!!! Пробный шар уже запущен, с запретом хранения персональных данных, вне Российских серверов, первые штрафы уже выписаны, читайте судебную практику!
Версия 8.0.0 была выпущена 12.сентября 2016, к использованию не рекомендовалась, первая рекомендованная 8.0.11 от 19 апреля 2018 года, актуальная 8.0.32 от 17 января 2023 года.
Никаких будет выпущена нет, это стабильная ветка и Webasyst на ней работает...
Велди, вы видимо просто часть сообщений, пропускаете мимо. Я даже рассказал как это будет обставлено со стороны государства, или думаете Вебасист просто так начал уже заниматься PostgreSQL, потому что он во первых хорошо работает на больших БД, хорошо масштабируется, можно создавать свои классы.
В ближайшие годы, всех заставят перейти на отечественное ПО, кто это не сделает, останется за бортом. Плюс приход "Чебурашки", исключать нельзя!
А мне статья понравилась. Человек не критикует, а предлагает, подкрепляет цифрами, нацелен на благое дело развития проекта, а Вы набросились.
В дополнение к теме рекомендую тем у кого проблемы с скоростью бд попробовать плагин от Креатив Монитор БД для переезда на innodb и создания и удаления индексов и инструмент mysqltuner.pl
Спасибо, за честный отзыв, а то честно, тяжело, набрасываются просто пачками и без повода. Про проверку согласно HTML5 стандартам, зря удалили, подниму ее отдельно, но может сам Вебасист, запретит, так как у них до сих пор старый код Метрики, Гугла и прочие ошибки даже в базовых шаблонах. Просто сейчас идет упрощение и уменьшение кода HTML, и вскоре разрешат, частично не писать закрывающие теги.
в топике, кроме пункта 4 есть рациональные зерна, но стиль автора своеобразен.
А вы попробуйте на больших базах, и будет прирост скорости. Почему вам дают, гарантированную информацию, проверенную на больших магазинах, вы без повода пишите критику? У меня на больших проектах, почти везде база полностью в InnoDB за исключением пары таблиц, и сайты летают, не просто так мне отзывы люди пишут, с максимальной оценкой в 5ть баллов. Если бы я плохо выполнял свою работу, то и отзывов наверное не было бы?
А что пробовать? Все уже есть как оно есть и по другому никто не сделает. Shop-Script тормозит на построении фильтров из характеристик товаров. Это самые медленные запросы. Ну и соответственно самый тормознутый плагин - это сео-фильтры. Его отключение дает ускорение работы сайта на 100 тыс товаров примерно в 2 раза. Если бы еще сами таблицы характеристик в корне переделать (что имхо не возможно), то было бы еще быстрее.
А innodb хорош, в первую очередь, связями между таблицами, и возможностью применения ORM. И этого тоже нам никогда не видать.
Для понимания полезности, есть такой плагин, загрузка прайслистов от поставщиков, так вот после моей оптимизации, время загрузки прайса меняется с 2х часов, до 5ти минут, наверное разница все же есть.
Можно названия плагина и список внесённых изменений? А то как то попахивает дурно заявление о 24 кратном приросте скорости.
Плагин "kmsuppliers", оптимизация БД, с построением индексов.
Сделал не на одном сайте, и такая ситуация когда люди обновляли прайсы раз в неделю, теперь обновляют каждый день и обновление с кучи поставщиков укладывается в 30 минут, раньше уходило 6-8 часов, т.к. при длительных соединениях коннект прерывался.
На любой мой ответ, я трачу время, которого не много, даю его развернуто, пожалуйста пишите по существу, либо обращайтесь лично
все срочно делаем mysqlcheck -o и это решит все проблемы, заявленые в старте топика. так бы и сказали сразу. и текстовые поля уберутся и индексы добавятся.
А на этом поподробней? Что и как? или опять пустые слова?
Ну что такое оптимизация базы? Это стандартная процедура mysql
Записи в таблицах не удаляются, а просто помечаются на удаление, и оптимизацией ты проводишь окончательное стирание из БД, но честно у вас каша в понимании Базы данных, почитайте хотя бы о MySQL.
а почему опять пустые слова? когда были пустые слова первый раз?
mysqlcheck насколько знаю только с MyISAM работает. Так в мануалах было написано
Можно конечно расковырять плагин и посмотреть что там, но, скорей всего, ничего революционного. Да и таблицы у нас и так в MyISAM.
У меня, если прочесть выше почти на 100% идет переделка таблиц в InnoDB, и добавление в последствии индексов. Но видимо вам это не понять, хоть сколько раз бы не написал об этом. По поводу анализа таблиц конфига БД, мог бы лучше написать mysqltuner. То что вы написали это просто оптимизация таблиц, она не ведет к увеличение скорости выборок, если только не совсем запущенный случай.
один из примеров улучшение конфига БД
То, что в примерах, делают все, если в этом есть необходимость. А вот от добавления индексов будет толк только если движок начнет их использовать. Я уже говорил что это архитектурные проблемы, которые возникли еще на стадии первичной разработки движка. Если сейчас все переделывать, то, скорей всего, на больших проектах, метаобновления могут не сработать и куча больших сайтов перестанут работать. Соответственно возникнут претензии к разработчикам Webasyst.
Когда вы кому-то что-то оптимизируете, клиент к этому морально готов и все происходит под вашим контролем. А вот массовая переработка всего - это сродни миграции на новый фреймворк. И дело не в том, что ваши советы никто не слушает, а в том, что все это технически не всегда возможно.
Я не знаю, насколько можно быть, талантливым и под какими веществами, чтобы такое писать и ему еще лайкают. Что у вас за каша в голове.
Сейчас проверил, везде есть индексы. До этого поверил вам на слово что их нет. Теперь вообще не понимаю ради чего был затеян весь этот сюжет.
Если мы в db.php описываем например
':keys' => array( 'PRIMARY' => 'id', 'url' => 'url', 'total_sales' => 'total_sales', ),То по всем этим полям создаются индексы при установке плагина. А мы всегда это описываем. Это же касается и всех приложений.
Индексы добавлять, для ускорение части запросов, включите на сутки вывод в лог медленных запросов, какие выполняются более 1 секунды и соответственно запросы, которые не используют индексы. Проанализируйте, и на основе анализа, можно для InnoDB добавить индексы, которые будут ускорять обработку запросов. Я уже писал об этом, можно ускорять обработку запросов в более чем 200 раз. Я высылал пример, когда запрос длился 4-7 секунд, а стал 0.04 секунды.
https://habr.com/ru/company/ru... - кидаю статью для ознакомления по методам ускорения обработок, просто иногда очень тяжело, когда не все понимают о индексах, методах построения запросов, и методах оптимизации таблиц, при выборе способе их хранения.
А было бы очень хорошо, если бы в моделях были прописаны все связи. Удалил товар, а за ним следом все картинки, характеристики товара, прочие данные, все, что в плагинах привязали к товару. Сейчас все это делается через хуки и нет гарантии того, что разработчик учел эти хуки для удаления или описал их верно.
Сейчас в шопскрипте появилась API построена очень красиво, и удобно что можно дописать свой функционал, попробуй через него, тем более что пока быстрее и безопасней чем API обменов нет.
Как же нет? Плагины быстрее :)
И сколько я помню, всегда был API.
Распишите пожалуйста досконально путь исполнения плагинов и соответственно API, и поймете что плагины почти всегда медленней.
Расписываю на пальцах путь API:
1. Запрос к серверу на выдачу данных
2. Выполнение кода PHP, очень короткого очень маленького
3. В PHP обычно одинокий запрос к БД, бывает несколько
4. Выдача результата по API, стороне которая запрашивала
Распишите аналогично путь плагина, особенно учитывайте, что часто куча плагинов, висит на одном и том же хуке. И учитывайте если мы говорим о фронте, они часто за собой тянут на сайт свои CSS, JS, а часто и не один CSS и JS, занимают хук (с толпишкой других плагинов), заставляют исполнять кучу PHP кода, и часто с кривыми запросами к БД и так себе оптимизацией по скорости, и потом через Smarty, который не может себя достроить пока плагин не даст ему ответ, что тоже замедляет отдачу и Smarty, начинает генерироваться в разы медленней.
Я так взял, один из проектов заказчика, с какими борюсь в сторону уменьшения плагинов, просто для примера, хуки которые переполнены плагинами:
Каждый из вас уважаемые коллеги прав по своему. И Андрей прав и Александр. C определенной стороны конечно написание плагина который будет работать по API дает преимущества, перед "хуками", И некоторые вещи тут реально лучше использовать через некое подобие "микросервиса", в виде - дернули API, вернули результат, хук не трогаем. Это к примеру ярко видно постом ниже, тут Александра я поддержу. Но и Андрей по своему прав. Если я не ошибаюсь (а это довольно редкое событие), Андрей один из самых первых разработчиков, и хорошо знает "коробку" и валатильность проекта. Т.е., да идея здравая, но ее реализация очень сложна, и живем как есть. К примеру на дворе 2023 а хука перед терминальным "body"- как не было, так и нет. Да много чего нет, хотя реально позволило бы ускорить движок. Поэтому ваш коллеги спор это беседа теоретика и практика, причем с попеременным успехом каждый из вас меняется местами.
P.S. Александр, а почему вы обходите стороной всегда вопрос роутинга? Это самое узкое место в движке, есть частные наработки которые ускоряли сайт кратно именно на роутинге, но они не могут быть примерены в коробке сейчас. Просто интересно...
Немного лирики.
Мне тоже не нравится множество плагинов в том или ином хуке, но какие альтернативы сейчас? Со временем сложилось так, что большую часть хуков не использую вообще, но всегда тщательно анализирую все хуки перед тем как отказаться от какого-то. Если плагин в каком-то хуке мне без надобности, то просто немного переписываю код, кое-что меняю в плагине, стараюсь не допускать избыточной концентрации плагинов в одном месте. Всякие CSS и JS плагинные, если они реально нужны, то интегрирую в основной pack, попутно оптимизируя и встраивая это органично, забирая у плагина эту инициативу по возможности. По итогу плагины мне отдают только то, что надо и только там, где надо, а любую перегруженность стараюсь сводить к минимуму, "размазывая" слой используемых функций плагинов по фронтенду так, чтобы было "незаметно". Часто мне даже не нужен функционал плагина целиком, поэтому беру лишь часть от него, меняя или отключая ненужное так, чтобы более не мешало. Либо выдергиваю из плагина понравившиеся части и собираю в виде своего отдельного решения.
По статистике из чуть более 100 плагинов изменениям разной степени сложности были подвергнуты около 40, но лишь 15 из них были переработаны достаточно сильно и там был значительно изменен код во многих местах либо добавлены новые нужные мне функции. Из этого общего кол-ва плагинов примерно 2/3 это исключительно бекенд. Плагинов фронта не так много. К ним подход даже строже. Если можно что-то реализовать без плагина на уровне более простого и быстрого кода, то делаю это именно так.
Непосредственных изменений в движке на сегодняшний день сделано около 30+. Годом ранее было больше раза в два, но от ряда вещей отказался, сделав им замену в другом виде или же пересмотрев подход со временем.
Следить за этим всем не сложно даже при обновлениях, т.к. есть система и всё задокументировано.
Однако следует понимать, что этот путь не для всех пользователей. Пилить код и вытачивать всё так, что это с трудом можно применить 1 к 1 на другом проекте - это исключительно доработка под себя. Но такой подход тоже имеет право на жизнь, хоть и требует некоторых навыков. Если бы всё было как в идеальном мире и летало со скоростью света, то не возникала бы потребность в оптимизации и наведении порядка на том или ином проекте время от времени.
Но при прочих равных иметь дело с какими-то другими, выражаясь по-простому, "движками" уже совсем не хочу.
Пожалуйста поясните, что вы имели ввиду под оптимизацией роутинга. Мне в общем важна любая информация, которая может хоть на миллисекунды улучшить обработку. Потому что сильно горит один проект который хочет прийти к 500 тысячам товаров и хотя бы 10 характеристик в категориях, со всеми возможными оптимизациями.
Сейчас пока рассматривается возможность, с уже внесенными мною улучшениями, касательно ускорения БД. Перенос ее на отдельный NVMe, сейчас на SSD 960Gb Micron M500, он не самый быстрый, но брался с учетом максимального TBW.
И соответственно и сайт и БД лежат на нем одном, а планируется перенос базы на kingston kc3000, причем там будет их всего 2, одна 1С, другая Шопскрипт.
А так пока 1С и Шопскрипт на разных Микронах 960Гб, сама виртуализация Esxi еще на другом диске, тоже SSD но попроще, но так нужно было чтобы получить минимальную задержку в виртуализации, она сейчас 0ms, редко подскакивает до 3ms.
Также был осуществлен переход на более быстрые процы, были 2.4Ггц / Турбо 2.8, сейчас 3.0Ггц / Турбо 3.6, также было 6 ядер / 12 потоков, стало 10 ядер 20 потоков, разница не более 20%, в среднем по больнице.
Если вы имеете ввиду сетевые маршруты, то Билайн 200Мбит -> Cisco 1Gb -> Роутер с фаерволом -> сервер. Отдача любого файла, к примеру картинки 100-150Кб примерно 10-14ms, как Яндексом, так и замерами Москва-Москва, Москва-Питер, Москва-Тверь.
И извините, для внесения ясности, я лично не пишу на PHP, поправить чужой код, переписать его на новую версию PHP, не вопрос, читать код и понимать его миграции не сложно. Но часто влезаешь в чужой код, видишь костыли, и с комментариями от разработчиков, меня лично берет страх, как такое можно было выставлять на продажу. И часто при правке кода видишь костыль и начинаешь не понимать, а что за входные и выходные данные, вообще автор имел ввиду, специально не буду перечислять плагины, потому что за прошлые перечисления, получил кучу минусов. Часто видя, чужой код, я очень редко видел код, написанный, теми кто когда то участвовал в коллективной разработке, кстати код Креативити, по нему видно, что когда то работал в совместной разработке.
P.s. Зато я хорошо разбираюсь в серверной части, самом Линуксе, его обслуживанию и развертыванию. Хорошо разбираюсь в движках БД. Потому что я сам когда то в Росатоме работал программистом, но писал на Дельфи программные комплексы связанные с БПФ, сбором и обработкой больших объемов данных, преподавал Дельфи студентам, также преподавал практику локальных сетей. Сам в свое время протянул 5км кабеля. Винду серверную любую начиная с NT 4.0, заканчивая 2016, знаю по максимуму. Просто каждый специалист в чем то своём, но общий уровень знаний, очень большой.
Под роутингом движка имеется ввиду вот это https://developers.webasyst.ru/docs/cookbook/basics/routing/
Чем? Первый вопрос который возникает - что оно тут делает? Обращаться к разработчикам надо на форуме разработчиков. По сути: вроде бы и правильно, но без учета специфики, "коробочности" продукта, его истории и рекомендаций "производителя". Обсуждать смысла не вижу. Перенес бы тему на форум разработчиков, а там желающие уже пусть упражняются в острословии и деталях.
К создателям плагинов результативнее обращаться на форуме для разработчиков.
В этой теме ноль конструктива, но куча мракобесия и хамства. Так что последнее слово лучше пусть останется за Александром Анатольевичем.