Меня зовут Александр Сербул. В компании "1С-Битрикс" я курирую направление контроля качества интеграции и внедрений.
Вступление
Успешно выполненный Проект - это всегда победа: удалось решить задачи Клиента, Клиент доволен, позитив и хочется жить дальше! Не всегда удается победить, и тогда нужно мужественно вынести поражение, сделав ПРАВИЛЬНЫЕ выводы. Правильные выводы - это когда дописываешь методики, чеклисты, руководства, чтобы не наступить на грабли ПОВТОРНО. Качественный процесс разработки Проекта - это процесс, использующий весь наработанный, нередко кровью, опыт. Это процесс, который не наступает на грабли.
Кратко о себе
Начинал свое погружение в мир IT разработчиком-любителем на ... известном в СССР компьютере БК-0010-01
. Написав несколько ... игр, вышел за пределы ресурсов в 16кБ ОЗУ и переключился на ZX-Spectrum, затем на PC и началось.Профессионально разработкой стал заниматься на PHP/Linux в одном из региональных подразделений Сбербанка России. Написал с нуля и до успешного внедрения интранет/интернет решение, настроив мимоходом сервера и ... заскучал
К счастью, встретил отличную команду, партнера 1С-Битрикс, вместе с которой почти 3 года трудился в проектировании и разработке нескольких крупных проектов рунета на платформе 1С-Битрикс.
Следующие два года возглавлял крупный распределенный отдел веб-разработки в Softline. Благодаря системному подходу и успешному внедрению в производство платформы 1С-Битрикс был построен отличный технологический процесс в стиле RUP+Scrum. Цели достигались, Клиенты были довольны, хотелось жить дальше
Почти год был IT-директором известного интернет-магазина программного обеспечения - allsoft.ru.
Неплохо разбираюсь в современных методологиях разработки, управления командами, проектами и качеством, ООП, паттернах проектирования, юниксах и высоких нагрузках.
Обожаю эффективность во всех ее ипостасях. Исповедую исключительно системный подход - ведь наступать на грабли во второй раз - расточительно.
Краткий итог
Чем больше я работал с платформой 1С-Битрикс, тем больше она мне нравилась за лаконичность, глубокую продуманность, эффективность и технологичность, направленную на РЕШЕНИЕ ЗАДАЧ ПОЛЬЗОВАТЕЛЕЙ. Я практически всегда получал работающее решение, а не "иллюзию решения"! Почти все возникающие задачи я находил... уже решенными в платформе - что давало возможность проявить свой талант и выложиться в разработке нестандартного крутого функционала.
А разве есть большая награда для Разработчика (пишу с большой буквы), чем удовлетворенный решением Пользователь. Который не только активно с удовольствием пользуется решением, но и строит планы по его развитию. И выстраиваются честные, доверительные и профессиональные отношения Разработчика и Пользователя - а решение становится живым!
В общем, я серьезно влюбился в концепцию эффективного решения задач на платформе 1С-Битрикс, и несколько лет работал над обобщением и систематизацией успешных рецептов, методологий, приемов и подходов - ведущих к победе.
К сожалению, иногда наблюдаю, как задачи по разработке проектов на платформе 1С-Битрикс сторонними командами разработки решаются не очень эффективно: "недожатое" проектирование, небрежная интеграция, поверхностное тестирование, "недокрученные" сервера под нагрузку. И я ВИЖУ, почему это случается и хочется помочь, подсказать, УБЕРЕЧЬ от ошибок! Честно.
А еще я видел, как иногда целые команды увлекаются процессом, саморазвитием и последними технологиями, забывая о цели "решить задачу Клиента" - это ужасно
Задачи в компании
Моя задача в компании - помочь нашим Партнерам и командам разработки Клиентов решать задачи на платформе 1С-Битрикс эффективно = ПРАВИЛЬНО и КАЧЕСТВЕННО. Т.е. - научить всегда побеждать.
Буду делиться опытом через рекомендации, методики, форум, вебинары, этот блог и очные встречи.
Расскажу, как задействовать платформу 1С-Битрикс на "полную катушку". Как открыть в первую очередь для себя, а затем и для Клиента технологическую мощь и надежность, стройность архитектуры и удивительную продуманность и полезность каждой детали продукта. И использовать эту мощь для победы.
Проконсультирую по системному анализу, проектированию, выбору и построению архитектуры, подготовке под высокие нагрузки и дальнейшей поддержке решений на базе 1С-Битрикс.
В этом блоге постараюсь рассказывать обо всем самом интересном и эффективном - инструментах платформы 1С-Битрикс, полезных практических кейсах, успешных архитектурах, высоких нагрузках и многом другом.
Мой твиттер: @AlexSerbul
Е-мейл: serbul@1c-bitrix.ru
Анонсирую следующие посты в блог - они будут посвящены технологиям кластеризации, появившимся в 10 версии продуктов 1С-Битрикс.
Всех обнимаю и надеюсь на интенсивный, открытый и профессиональный диалог.
Давайте только без утопии
Что следовало бы изменить и как в текущей архитектуре системы?
Я же его не просто так задавал.
У меня за несколько лет работы с системой накопилось немало задач.
Меня беспокоит то, что API работы с записями БД сильно отличается.
В 21 веке звучит смешно, но метод СIBlockSection::GetList не позволяет ограничить выборку, аналогично тому как это делается в СIBlockElement. Проблема реальная. На проекте интернет-магазина с большим деревом каталога это создавало реальные тормоза.
Но проблема, как вы понимаете не единична. Где-то сортировку можно задать просто указав параметром массив, а где-то нужно передавать переменную как ссылку.
Наверняка вы тоже сталкивались с чем-то подобным.
Есть еще система багтрекинга и пожеланий клиентов и партнеров - но это не недостатки, а нормальное развитие продукта. наша система как раз и отличается тем, что с одной стороны имеет стабильную грамотную архитектуру, проверенную в бою десятками тысяч проектов, с другой - постоянно эту архитектуру улучшает
Я честное слово хотел услышать от Александра ответ по этому вопросу, а Вы отправляете меня в техподдержку, чтобы я там прочитал "поставлено в план, к сожалению о сроках сообщить не можем".
Спасибо Артем!
Кажется Александр что-то ответил, пойду почитаю.
АПИ работы с реляционными данными - инфоблоки, реализующие фаулеровский шаблон проектирования - постоянно развивается.
Из важных улучшений хотел бы отметить:
- Имеется возможность соединять выборки из нескольких инфоблоков, используя возможности СУБД, по стандартным полям. В настоящее время ведется улучшение этого важного функционала для поддержки нестандартных полей.
- Инфоблоки 2.0 - отличный инструмент для организации сложных каталогов и необходимостью быстрой фильтрации и сортировки.
Сомневаюсь, что для решения задачи работы с данными на платформе более эффективными были бы инструменты типа Propel или Doctrine. Концепция ORM еще, имхо, сыра и попахивает теоретическими изысканиями для саморазвития, а не для решения практических бизнес-задач. Поэтому инфоблоки - люблю и рекомендую к использованию на больших объемах данных.Тем не менее, если у вас огромные массивы данных, вы всегда можете использовать сторонние инструменты для работы с ними, такие как Zend_DB, AdoDB, или хоть NoSQL (например SimpleDB и т.п.). Задачу всегда можно решить.
TableModule, куда больше пахнет теоретическими изысканиями, чем концепция ORM, т.к. на практике это приводит к приличным к тормозам. Поэтому инфоблоки 2.0, которые как Вы верно заметили "отличный инструмент для организации сложных каталогов и необходимостью быстрой фильтрации", и пришли на смену своей первой версии, позволив переносить значения свойств в отдельные таблицы.
Использование Zend_Db и т.п. думаю здесь неприемлемо, т.к. разделы инфоблоков неотъемлемая часть интернет-магазина, и отказываться от них или перекладывать работу на другие программные интерфейсы в данном случае, значит терять часть функциональности и тратить уйму времени.
Ужесточение параметров фильтрации подойдет в редких случаях.
Простейшая задача - показать один последний созданный радел, остается нерешенной.
Ладненько, не буду больше отнимать время.
На очереди новые интересные задачи
вот как задача решается на API
if(CModule::IncludeModule('iblock')) { $rsLastSection = CIBlockSection::GetList( array("CREATED"=>"ASC"), array( "IBLOCK_ID" => 2, ), false, array("ID", "NAME") ); if($arLastSection = $rsLastSection->GetNext()) echo "<pre>",htmlspecialchars(print_r($arLastSection, 1)),"</pre>"; }Переписываем запрос руками и выполням в /bitrix/admin/sql.php?lang=ru
Всё в пределах погрешности. Это архитектурная особенность MySQL.
Сначала результат полностью формируется на сервере, а потом уже передается клиенту.
Рекомендую выполнить аналогичные замеры на вашем проекте и представить здесь результаты. Если мы будем наблюдать значительный прирост производительности добавим соответствующее расширение в API.
Почему nTopCount не поможет?
Разве он не устанавливает тот самый limit?
По поводу замеров я сейчас уже не скажу т.к. проект более не поддерживаю, но в былое время limit дал ощутимый прирост в несколько секунд.
1) 3-й параметр не был установлен в false.
2) 4-й параметр не был задан и/или включал пользовательские свойства.
3) Использовался NavStart(1)
4) MySQL "падал" в дисковую сортировку из-за размера выборки или буферов сортировки.
nTopCount не поможет по той же самой причине по которой не поможет и limit.
Мне кажется мы друг друга не понимаем.
Во-вторых, за исключением очень особенных случаев, разницы нет.
Я именно по этой причине и предлагаю вместо обсуждения теорий выполнить код без лимита и запрос с лимитом. Сравните время исполнения.
Порядок сортировки на результат не влияет.
Я даже могу обосновать данный результат.
Сортировка идет по ID, в данном случае это поле является первичным ключем, по которому есть индекс. Соответственно для mysql не составит труда найти последний ID, оставновить на этом просмотр таблицы и вернуть результат. Я бы не сказал, что это очень особенный случай.
Вероятно на Вашем примере разницы нет, т.к. смею предположить что по полю
DATE_CREATE не создан индекс и поэтому mysql вынужден сортировать всю таблицу каждый раз.
В любом случае, я показал что разница есть.
Качественный продукт должен решать задачи качественно - быстро, просто и эффективно. Какая у вас конкретно стоит задача?
Вы расскажите конкретную задачу, тогда можно сказать решить ее на БУСе или нет, а если решать то как с максимальной эффективность.
Александр консультирует нас по одному проекту - получаем дельные советы, возможно сами выработали менее удачное решение. Очень хорошо, что можно получить консалтинг от более опытных специалистов.
Бывает, контролируешь работу исполнителя (неважно, внешнего или внутреннего), находишь кучу ляпов/ошибок. Но я не специалист по Битриксу и не все ляпы могу обнаружить, некоторые выплывают потом случайно, некоторые просто приходится терпеть, т.к. не знаешь как исправить. Причем даже не всегда понятно - это ошибка разработчика или ошибка в Битриксе.
Там основной упор на производительность. Тогда как меня больше волнует качество реализации функционала.
Еще пример. Я говорю исполнителю: "вот здесь нужна вот такая сортировка". Исполнитель мне отвечает: "это в Битриксе невозможно, задавайте сортировку сами через специальное поле". И я никак не могу проверить его, действительно ли это так (и тогда мне нужно дописывать еще страницу в инструкцию для конечных пользователей) или просто исполнитель не достаточно квалифицирован (и тогда нужно дать ему ссылку на нужную страницу в документации).
Вообще для проектирования систем на платформе и постановки задач разработчикам я рекомендую хорошо изучить логику работы системы на уровне пользователя и администратора, понять, какие у объектов есть свойства и связи. Либо поручить разобраться в системе аналитику, который будет ставить задачи разработчикам.
Изучить мне Битрикс на серьезном уровне не представляется возможным в обозримом будущем, отчасти из-за нехватки времени, отчасти из-за отсутствия серьезных знаний смежных технологий, например, PHP и JavaScript.
Предыстория:
У нас есть один вялотекущий проект, который то замораживается, то начинает разрабатываться в авральном режиме, но суть не в этом. Предполагается большой каталог электроники, по своему функционалу этот каталог похож на яндекс.маркет или товары.мэйл.ру, но более узкий в плане товарных позиций (только электроника). Характеристики товаров тоже аналогичны яндекс.маркету, там, прошу учесть, только у мобильных телефонов около 180 свойств, большинство из них доступны для поиска! Естественно у каждой товарной группы много совершенно разных характеристик, причем у них есть отношения родитель -> дочка. Например: ноутбуки -> портативные ноутбуки или телевизоры -> плазменные. Более общие наборы свойств должны наследоваться от родителя.
Решение:
Четкого решения этой задачи на данный момент нет, было несколько предполагаемых путей реализации:
1) Каталог битрикс, инфоблоки+ . Недостатки - при большом количестве полей у таблицы начинаются проблемы вроде error 139, тормоза с поиском, если искать сразу по 20-30 полям (+ сортировка), при WHERE с >50 условиями у mysql вообще начинает сносить башню (. Учитываем, что хоть и инфоблоки+, все равно join с b_iblock_element и b_iblock (кажется так). Кешить все жестко тоже не получиться, т.к вариантов в фильтре будет очень много.
2) Каталог битрикс, инфоблоки, свойства в одной таблице. С хранением данных проблем нет, с поиском и сортировкой очень большие проблемы.
3) Не реляционная СУБД, например mongoDB. Все бы хорошо, но на практике еще не опробована. Наиболее приемлемый вариант - писать в инфоблоки и вещать обработчики, которые будут писать в mongo, в публично части получать данные исключительно из mongo. Вариант 50 на 50.
4) Аналогичен п.3 но вместо mongo использовать sphinx, на практике это решение у нас уже обкатано, сфинкс неплохо справляется с поиском по множеству атрибутов + хороший полнотекстовый поиск.
5) Свой каталог, своя структура БД, в качестве фраймворка - Zend. В структуре БД много тех же граблей, что и в битрикс. Реляционная теория с подобными задачами справляется не очень хорошо.
В пунктах 1 и 2 еще есть проблема с наследованием набора свойств от родителя.
Если ты дочитал до этих строк, то собственно вопрос: что лучше выбрать для реализации того, что описано выше, с учетом того, что проекты с каталогами товаров ты на битриксе делал?
P.S: еще меня тут жутко минусуют, за то что я не очень люблю битрикс, поэтому помоги мне полюбить его
Актуальная интересная задача - Яндекс.Маркет, Товары.Мейл.Ру ... можно добавить каталоги Magento сюда. Много рубрик, в каждой рубрике свой набор свойств, фильтрация по многим полям (хочется, чтобы фильтры сами создавались на базе множества элементов) и т.п.
Как ты правильно заметил, делать с нуля подобную систему на PHP (можно не нуля, а с ZF, или поиграть мускулами и на базе Doctrine
Чтобы не рисковать и получить быстрый результат, я бы попробовал хорошо разобраться с тем, что есть готового и отлаженного в этой области. Возьмем 1С-Битрикс - большая инфраструктура с множеством готового проверенного в сотнях реальных проектов функционала. Поддерживает каталоги через инфоблоки.
Инфоблоки. Эффективно работают с иерархией, работают быстро, т.к. архитектура простая и логичная (представь, если бы инфоблоки были на ORM
Ограничения по кол-ву свойств в таблице MySQL - неужели так критично все свойства хранить? Если не получается договориться с аналитиком - убрать можно хоть в NoSQL хранилище и дергать оттуда. Мы же понимаем, что в жизни есть ограничения всегда
Наследование свойств от родителя ... - я бы не стал такое делать, сложнее поддерживать. Думаю, можно без этого обойтись.
Одно ограничение - если данных в каталоге много, десятки миллионов записей, я бы порекомендовал в инфоблоках оставить единицы миллионов для фильтрации и сортировки, а остальные данные убрал либо в реляционную таблицу, либо в NoSQL.
Т.е. постарался бы воспользоваться для решения задачи максимумом возможностей инфоблоков, убирая возможные ограничения через корректировку требований. А в оставшееся время, когда иерархия и ОСНОВНЫЕ сортировки и фильтрации летают, навалился на вкусные и меганестандартные вещи, экспериментировал с ними. Для фильтрации и сортировки по большому набору полей рекомендую еще обратить внимание на Solr - работает быстро и индексирует большие списки атрибутов.
В результате должен получиться тщательно оптимизированный под нагрузку каталог, в своей основе работающий на инфоблоках+, использующих в качестве дополнительного хранилища внешнюю таблицу/БД/NoSQL/Solr.
Инфоблок "Рубрика и карточка товара" - иерархия и карточки товаров. Для телевизоров - один инфооблок+, для телефонов - второй инфоблок+.
Инфоблок "Ценовые предложения" - конкретные предложения, связанные с карточкой товара. Можно либо общий, либо отдельный для каждой рубрики.
Инфоблоки - справочники, на которые ссылаются объекты каталога.
Таблицы с большими массивами дополнительных данных, возможно связанные через обработчики/триггеры с инфоблоками каталога. Какие-то данные есть и там и там. Зависит от задач.
Все это внутри платформы 1С-Битрикс: авторизация, статистика, поиск. Поиск можно в 10 версии вертикально шардить на отдельный сервер базы данных.
>а инфоблоки+ дополнительно прямо-таки созданы для Яндекс.Маркетов.
Хотя эта фраза наводит на мысль, что упоротый тут не я
Вот, скажем, есть ли пример решения типичнейшей задачи -- разделения длинного текста на страницы?
(да, я знаю про кастомизацию, но какбэ хотелось бы видеть-то 8)