Если для решения проблемы "Got error 139 from storage engine" вы воспользоваться советов приведенным в посте Инфоблоки+ и "Got error 139 from storage engine" у вас может возникнуть следующая проблема:
При работе в базе разваливается одна из таблиц при этом в логи сервера БД валяться ошибки с сообщением 'нет доступа к странице xxx возможно она повреждена или удалена' (нет оригинала сообщения поэтому вольная интерпритация).
При этом база в общем то работает и даже из поврежденной таблици можно вытащить всю информацию кроме конкретной записи и того что после нее.
Данная ошибка возникает из за того что после увеличения страницы памяти при пересборке мускуля видимо отключается или перестает корректно работать проверка на максимальную длину строки таблицы. Таким образом если у вас теоретически при заполнение все полей эта вставка будет больше 32 кБ произойдет описанная выше ошибка.
Чтобы избежать ее небходимо:
1. для инфоблоков с большим количеством свойств проверить не превышает ли теоретически они этот предел (в таблицах b_iblock_element_prop_xxs).
2. ну и делать чаще дамп
Если же произошла ошибка то помогает только удаление целиком таблици и восстановление ее из дампа либо того что удалось вытащить, но лучше при возникновении этой ошибки удалить и восстановить целиком базу так как иногда наблюдался "пост эффект" (аналогичная ошибка на других таблицах на которых она теоретически не должна была появляться).
В целом же если учесть это и в проверить то других ошибок не возникает, база работает стабильно.
Чаще лучше подойти к задаче с другой стороны. Например, а нужны ли все эти много много свойств?
А черт его знает... Сейчас на одном проекте эти свойства плодятся и плодятся. С одной стороны 80% этих данных никак в фильтре не участвуют, с другой стороны так удобнее редактору (да и порядок как ни как есть).
Простой отрешенный пример - каталог авто. Мне интересно в фильтре объем двигателя, цвет, расход топлива. И есть куча данных, по которым фильтр никак не идет (например, размер колес, разгон, затраты на ремонт).
А в отдельные свойства их загоняют по той причине чтобы стандартизировать ввод информации разными редакторами (да и вывод разных блоков свойств часто зависит от дизайна).
Надеюсь поняли мысль - когда для фильтрации нужны всего 10-20%% свойств, а остальные забиты в свойства "просто так".
Может подойти к проблеме с другого ракурса? В отдельную таблицу складировать только те свойства, по которым реально есть фильтр? Ввести ИБ++, которые бы совмещали и те и те свойства. Что скажете?
Чаще лучше подойти к задаче с другой стороны. Например, а нужны ли все эти много много свойств?
Полностью согласен. Что касается конкретного случая там в реальности большинство свойств не нужно/нуждаеться в смене типа/переносе в отдельный инфоблок но:
1. проект очень большой и делался не одной командой разработчиков, соответственно сразу в лоб все переделывать дорого и долго. 2. сроки поджимали, выходила новая версия сайта
сейчас постепенно ведется работа по оптимизации свойств. да и без свойств там много чего еще надо оптимизировать.
Коллеги, понимаю, что мы в отличие от интеграторов живём в идеализированном мире.
А что если, например, сделать одно множественное свойство для текстовых характеристик? Редактор сам пишет имя характеристики в описание значения и собственно значение. Тогда он сможет писать только те свойства, на которые есть информация. Ну и вывод можно стандартизировать.
Николай, ну ты снова о наболевшем Есть бесплатный Oracle для тех, кому MySQL "жмёт". Правда, придётся сделать апгрейд нашей лицензии. Но даже если бы у нас была поддержка PostgreSQL, сильно сомневаюсь, что лицензия стоила бы как на MySQL.
А что если, например, сделать одно множественное свойство для текстовых характеристик?
Так-то да. Но: - там ограничение на 255 символов - есть ряд свойств, обладающие списочными значениями (например,, тот же размер колес из примера выше редактору проще выбирать из списка)
В общем с одной стороны да, можно закастомизировать свой тип свойств со всякими рюшечками, но очень сильно будет жать ограничение символов.
В PostgreSQL кластеризация работает из коробки. Недавно была задачка на VPS с весьма low-end характеристиками установить Битрикс и Zabbix в одном флаконе. Для Битрикса использовалась Percona XtraDB. После старта сервера Zabbix, сервер перконы ложился напочь. Ok. Пусть Битрикс живёт со своей Percona, а Zabbix мы отправим в SQLite. Заработало. Но (ессно) медленно. Ok. Поставим рядом PostgreSQL и пусть Zabbix работает с PostgreSQL, а Битрикс со своей перконой. И вот тут всё сложилось: все работают, никто не тормозит. Возникает вопрос: почему бесплатный Zabbix можно поставить и на SQLite, и на MySQL, и на PostgreSQL, и на Oracle, и на IBM DB2, а в Битрикс надо выбирать между MySQL и Oracle? При том что PostgreSQL оказывается явно производительней хвалёных форков MySQL "из коробки" и всё это происходит на фоне воплей об импортозамещении? Вопрос риторический, ответов не жду..
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».