ГлавнаяБитриксСубд битрикс

Чем поможет архитектору «NoSQL» и… поможет ли? Субд битрикс


Устройство и технические свойства платформы. Плюсы и минусы

Компания 1С-Битрикс и ее продукты (CMS и корпоративный портал) вызывают много вопросов и обсуждений как в интернете, так и в жизни. Выходят новые версии, идут семинары, компания занимается активной маркетинговой деятельностью, работает партнерская сеть, а вопросов со стороны профессионального сообщества меньше не становится. Эта статья – попытка разобраться в частых вопросах и проблемах и сформировать общее понимание ситуации.

Немного предыстории и авторской позиции. ИНТЕРВОЛГА работает на Битриксе уже несколько лет. До 2009 года мы развивали свою систему, пробовали другие коробочные системы. Больше 230 сайтов были сделаны нами НЕ на Битриксе. Так что опыт работы на других системах есть и солидный. Я понимаю и что такое свой код, и что такое разработка на опенсорсе, и что такое другие коробочные системы. Теперь работаем на Битриксе, и в целом – довольны. Не хочу сейчас о личных впечатлениях, скажу главное: я безусловно не являюсь объективным.

Цель статьи: подумать вслух. Хочу получить обратную связь и дополнить собственное понимание.

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

Обсуждая технологии, будем говорить не об абстрактной красоте кода и применении всех возможных нанотехнологий, а только о технических аспектах, создающих бизнес-преимущества. То есть: Довод «ОRM нужна, ибо это круто» мало что значит. Довод «убогая реализация мастеров установки (класс Wizard) мешает делать установщики для сложных тиражных продуктов» принимается, если это правда.

Я хочу построить по возможности полный перечень вопросов (скажем, основываясь на тех, которые можно найти в яндексе по словам «битрикс @#$%"») и разобраться. Отделить, так сказать.

Задача, на мой взгляд, грандиозная, так что решена в меру моих скромных возможностей. Часть 1. Устройство и технические свойства платформы 1С-Битрикс. Возможности, требования, производительность. Версия PHP, разделение логики и представления, шаблонизация, XSLT, «Инфоблоки: База в базе», запросы.

1.    Он сделан на древнем как помет мамонта PHP 4. Это не круто, пещерный код!

Ответ на каждый вопрос буду разбивать на три куска: суть («смысл и важность вопроса»), + (достоинства решения Битрикcом) и - (недостатки решения Битриксом)

Суть. Для бизнеса, для клиента, для внедрения версия php это один из последних технических вопросов. Думаю, менее важный, чем версия серверной ОС в офисе или тип принтеров: МФУ или классические лазерные работяги. Для программиста, натягивающего дизайн или делающего компоненты, это тоже в общем мелочь. Ну сохранено много чего для совместимости, и бог с этим. Для кого это важно? В чем вообще вопрос? В том, что обеспечение совместимости с версией 4, выпущенной (страшно сказать) в 2000 году, требует соблюдения морально устаревших и технически избыточных конструкций и запрещает использование многого важного, удобного и в целом – правильного. Коротко говоря: больше трудного в чтении глупого кода.

+ В 2010 году Битрикс прекратил практику поддержки совместимости кода системы с PHP4. Теперь все пишется без поддержки PHP4. Как я понимаю, есть планы по наведению порядка в старом коде. Вы спросите: а зачем его вообще так писали? Был ли смысл работать с поддержкой версии 4, ведь когда Битрикс всерьез выходил на рынок, уже была и набирала популярность версия 5. Это интересный вопрос. Думаю, что система так долго сохраняла эту совместимость потому, что хостинговые компании переходили на php5 относительно медленно и было важно не создавать препятствий для внедрений. Кроме того -- совместимость новых версий Битрикса со всем, что было написано ранее, поддерживается разработчиками постоянно. Для партнеров, поддерживающих разные проекты, уверенность в такой совместимости является на мой взгляд одной из самых важных положительных сторон.

- Конечно, все что делалось давно и с тех пор не переписано, изобилует кодом, совместимым с php4. Если надо с ним работать, кастомизировать и развивать, придется возиться. Если вас такой код бесит -- придется сжать зубы. 2.    Где разделение логики и представления (тут же каша из php, HTML, css, js и SQL!) Суть. Принято считать что в любом программном продукте нужно разделять логику и данные, представления и вычисления, код на разных языках и тому подобные сущности. Честно - звучит красиво, но как это делать -- неясно. Начнем с того, зачем это делается. Я вижу несколько причин: - Разделение системы на относительно небольшие и функционально определенные блоки облегчает их повторное использование - При развитии и поддержке системы удобно, когда разные люди каждый по-своему редактируют свои программные блоки.

Как это делать? Часто хотят разделить по критерию языка программирования. Давайте возьмем любой веб-продукт. Там 4 языка будет точно. HTML+css (посчитаем за 1 язык), серверные скрипты, клиентские скрипты и язык СУБД. Иногда -- больше. И переход между языками совершенно не означает смены роли соответствующего куска кода. Часто куски, на которые вы порежете, будут использоваться ровно 1 раз. Какую пользу принесет такое разделение? Никакой. Представьте себе полный список фрагментов HTML или SQL-кода, которые есть в проекте. Как их складировать, как именовать, как вызывать? Конечно, критерий разделения должен быть другим. Разделять логику, данные, языки, сущности на независимо и удобно редактируемые элементы нужно по критерию частоты правки. Нужно смотреть, кто и в каких обстоятельствах эту правку будет выполнять. Соответственно и сами средства редактирования нужно создавать именно с учетом этого критерия.

В вебе и программировании вообще есть популярный миф, что логику, данные и представления легко и очевидно можно отделить друг от друга. Что решение этой задачи однозначно, и кто делает не так, как кажется говорящему -- ленивый дурак. Если немного подумать, становится очевидно что логика, данные и представления легко переходят между собой в зависимости от того, с какого уровня абстракции вы смотрите на задачу. Например, html-код шаблона для разработчика сайта это безусловно представление, для браузера это код, а для ядра CMS это данные.

+ Основная претензия к Битриксу в этой части -- разработчики, впервые видящие код шаблона любого компонента, например списка новостей, ужасаются циклу, каше из php и HTML (и js изредка можно встретить) и сразу говорят что Битрикс написан на каше из спагетти-кода и они с ним работать отказываются. Попробуем разобраться. Когда задается вопрос про кашу, сразу понятно что смотрел человек. Человек открыл код шаблона, увидел цикл с HTML вперемешку с php и решил, что Битрикс плохо.

Так вот, про кашу в шаблоне. Это шаблон, он для вывода. Все данные уже собраны, запросы отработали, понятно что и куда мы выводим, даже отлов угроз уже прошел. Это последнее звено в пищевой цепочке кода и данных. Тут логика вывода действительно смешана с оформлением, и это правильно. Это не нравится фанатикам, фанатики в своих CMS делают иначе: там часто код вызывает шаблон, который опять вызывает код, в котором опять вызывается шаблон. Все это обрабатывается через eval и практически не поддается отладке Зато очень красиво. То, как сделано в Битриксе, поддается любой отладке и тратит минимум ресурсов. То, что видно в коде шаблона, является представлением. Код этого представления будет переписан на 90% при редизайне вместе с php и HTML. Это не бизнес-логика, это логика вывода и она в Битриксе выведена в отдельную сущность - код шаблона. Код, реализующий бизнес-логику, запрашивающий и обрабатывающий данные, находится в других местах -- компонентах и модулях. О них мы поговорим дальше. Я убежден, что логика, представления и данные в Битриксе разделены самым разумным для задач CMS образом.

- Действительно, где данные, где представления и где разные сорта кода -- разобраться часто очень непросто. Во многих случаях программисты и не хотят об этом думать, у них другой подход. Поскольку далеко не все видят разницу между обращением на языке php к извлеченным данным для целей вывода и тяжелыми запросами к бд или вызовам функций API, то в шаблоне можно писать любой php-код. Можно прямое, даже не API-шное обращение к базе написать. Можно написать десяток строк на API и решить задачу. Битрикс этим очень развращает разработчика. Не запрещено писать бизнес- логику в шаблонах и HTML в компонентах. Прекрасно помню как я сам, не разобравшись особо в компоненте и поленившись его кастомизировать, дописал прямо в index.php сайта пару неприятных GetList. Потом переделали, но впечатление яркое осталось. И очень часто это впечатление от сделанного с применением Битрикса безобразия переносится на сам Битрикс.

Вывод: В собственном коде и по идеологии Битрикса задача решена нормально, а вот привитием хороших манер и практик Битрикс почти не занимается. Дает слишком много свободы. Style guides, Code conventions, Code review - все на совести разработчика. Понятно, что обычно и разработчик этим не занимается.

3.    Где шаблонизатор?

Суть. Часто в веб-системах выделяют функционально независимую часть, которая должна  получить данные (вход) и сгенерировать представление (выход). Поскольку веб-представления бывают сложны не только по виду, не только по структуре текста, но и по логике вывода (скажем, колоночный вывод, различные шаблоны вывода в зависимости от уровня доступа пользователя), то язык шаблонизатора, особенно функционального, вполне сопоставим с языком разметки или даже программирования. При этом язык php уже сам является шаблонизатором, так как умеет оставлять без изменения те части текста, которые находятся вне его маркеров. Как правило, нет никакого прикладного смысла в том, что на языке-шаблонизаторе писать поверх еще 1 шаблонизатор. Польза от этого (сомнительная) только одна: ограничить возможность написания кода для редактора шаблонов. Отдельно поговорим про XML и xslt как альтернативу классическим “грязным php-шаблонам” чуть далее.

+ В Битриксе никакого отдельного шаблонизатора нет. Битрикс использует php. Хорошо это или плохо -- однозначно сказать сложно. Я вижу больше плюсов. Хотя бы то, что его не надо учить. В Битриксе есть что учить и без шаблонизатора. Разумеется, все что можно вообще сделать на языке программирования, можно сделать в шаблоне, ведь это просто php.

- То, что шаблоны пишутся прямо на php, предоставляет широчайшие возможности для г#$%кода. Ничто не мешает написать прямо в тексте шаблона вызов другого компонента, прямое или API-шное обращение к БД, или любую другую ерунду, не рекомендованную по идеологии в этом месте. Битрикс это не контролирует.

4.    XML/XSLT. Почему не применяется современный, технологичный, стандартизованный подход к шаблонизации на основе xslt-преобразований данных в представления? Суть. Суть идеи XSLT проста и красива. Код системы (бизнес-логика) реализует все функции и готовит данные в формате xml. В xml никакого оформления нет, одни данные и разметка, отражающая их структуру. Затем с помощью xslt-преобразований делается представление. В xslt-преобразованиях нет бизнес-логики. Там нельзя написать запрос к БД. Технологически идея xslt более красива, чем грязное, не поддающееся повторному использованию и развязывающее руки г@#$%кодерам применение php-шаблонов. В Битриксе XSLT нет.

+ PHP-шаблонизация известна всем, стандартна, производительна и гибка. XSLT надо учить, его производительность и гибкость не всеми подтверждаются. Есть мнение, что только с таким PHP- шаблонизатором можно быстро знакомиться с системой и начинать поддержку. Есть множество экспертных мнений, что PHP-шаблоны оправдывают себя экономически и производственно, в отличие от XSLT, Smarty и прочего. Независимо от того, родился плохой или хороший код шаблона, его все равно не будут редактировать. Его перепишут.

- PHP-шаблоны позволяют и даже поощряют написание плохого кода. Технология XSLT менее подвержена этому недостатку. Есть мнение, что только с XLST-шаблонизатором можно качественно и долго развивать проекты, повышая эффективность сотрудников и зарабатывая деньги. Есть множество экспертных мнений, что XSLT-шаблоны оправдывают себя экономически и производственно, в отличие от PHP, Smarty и прочего. Есть масса хороших специалистов, которые верят в мощь xslt. Почему бы Битриксу не включить его поддержку? Если бизнес Битрикса в создании новых возможностей для партнеров и есть те, кто скажет, что хочет развивать свои проекты на xslt – почему нет? Я не готов судить о том, насколько это сложно и революционно, но в минусы запишу.

Вопрос XSLT дискуссионный, но я не считаю его слишком важным.

5.    Инфоблоки или “База в базе”

Частенько при обсуждении Битрикса новичками рождается текст вроде такого "ужас, с этой структурой данных невозможно работать напрямую, посмотрите как они хранят свойства элементов". Действительно, на первый взгляд выглядит странно. Но только на первый. Точно так же поступают для хранения данных редактируемой структуры 1С, invision power board, wordpress и тысячи других веб- и не-веб-приложений. Не знаю как это называется по-умному, я привык называть это решение "база данных в базе данных". Подход заключается в том, что в физической структуре БД создаются 4 таблицы, не меняющиеся при изменении структуры данных: типы объектов, экземпляры объектов, свойства объектов и значения свойств объектов.

+ Плюсы лежат на поверхности: удобный контроль над данными такой структуры из своего приложения, универсальность методов, общая структура данных для любого проекта, возможность многократно менять типы данных для полей без уничтожения самих данных (попробуйте без этого механизма сменить тип поля в БД по кругу: текст-дата-число-текст и посмотрите что будет).

- Минусы тоже очевидны: тормоза и непрозрачность при прямом доступе к данным. Начнем с последнего. Честно, не понимаю что мешает получать доступ к данным с применением родного для них API. Что за кайф разбираться в хитросплетениях чужой структуры данных при наличии развитого API? Тормоза - вопрос важный, но далеко не однозначный. Действительно, при хранении всех свойств в одной таблице извлечение значений, например 20 свойств, приведет к 20 джоинам. Сортировки и поиски тоже не добавят красоты запросу. Если же есть сложная логика вроде: все товары (таблицей), поставщика А за прошлый год, брендов Electrolux и Bosch, с гарантией от 9 мес и имеющиеся в наличии на складах Московской области, то не слишком сложный по сути запрос (ну на вид джоинов 7 максимум, и даже без левых), оборачивается сотней джоинов. Штатно из них можно опять сделать 7 (ну 10 с учетом системных таблиц), но этим надо заниматься. Поговорим о запросах.

6.    Тяжелые длинные непонятные запросы к базе данных (примеров масса на различных форумах и в любых проектах) Суть Код Битрикса порождает очень большие запросы. Несколько экранов не очень понятного SQL традиционно пугают людей, которые редко пишут запросы сложнее sel ect * fr om ... where id=... и уверены что объединение таблиц по условиям делается через where так же производительно, как через on. Давайте попробуем разобраться в этой очень сложной теме, которая включает вопросы узкотехнологические, вроде производительности конкретных выборок, вопросы удобного применения технологий работы с БД в больших развиваемых проектах на растущей CMS, вопросы стоимости владения и поддержки.

Откуда это все вообще берется? Есть инфоблоки, где быстро и комфортно создается структура данных. Есть стандартные компоненты, реализующие наиболее распространенные вещи. Есть API, позволяющее отправлять достаточно произвольные запросы. Прямой доступ к БД неудобен и вообще говоря, противопоказан, так как физическая структура БД может измениться, а работа даже самого древнего API гарантирована. Вы применяете компоненты, пишете свои, активно пользуетесь API, в итоге ваша достаточно высокоуровневая логика выборки превращается в запрос. Генератор запроса, несмотря на свою сложность, по сути выполняет довольно тупую работу по переводу логики, изложенной на высоком уровне, в обращения к конкретным полям конкретных таблиц по условиям. Запрос получается совершенно неудробочитаемым. Со вставками и удалениями все в общем так же.

- Начнем с минусов Сложные запросы очень велики и вы почти не можете влиять на их структуру. Если есть желание заняться их профилировкой и отладкой, вы фактически ограничены теми не слишком богатыми средствами изменения запроса, которые предлагает Битрикс. Порядок объединений, специфические условия на выборки,  локальные кеширующие временные таблицы -- у вас всего этого нет. Запрос рождается системой. В мощных СУБД есть умные и очень эффективные оптимизаторы запросов, которые готовы из говна сделать конфетку (а совсем плохие запросы такие СУБД даже не дают исполнять). Подавляющее большинство установок Битрикса работают на MySQL, чей оптимизатор достаточно слаб и для таких задач подходит мало. Разумно было бы разработать свой или интегрировать внешний, но насколько я понимаю, технологически эта задача очень сложна и решать ее всерьез Битрикс не готов. В итоге мы имеем большие запросы, ограниченные средства их изменения с сохранением логики, и механизмы кеширования поверх всего этого.

+ Главный плюс. Запросы не надо писать руками. Создание сайта на Битриксе обычно предусматривает визуальную настройку готовых компонентов, создании структуры сайта и натягивание дизайна. Не в каждом проекте приходится кастомизировать компоненты, но даже эта работа не заставляет писать запросы. Есть API, до физической структур дела нет. Вернемся к запросам. Запросы велики, нелегко их менять, иногда все тупит. Но: - безопасность. Обертки над запросами решают задачу защиты от атак или глупостей. - есть инфоблоки 2.0. Это включаемый галочкой в админке режим работы инфоблока, когда его поля переносятся в отдельную таблицу. Как правило -- здорово помогает при большом числе записей и опасности блокировок. Джоины, появившиеся для извлечения отдельных свойств, сливаются в один. - большой запрос не всегда синоним долгого исполнения. Возьмите из вашего тяжелого проекта тяжелый запрос и сделайте explain в консоли. Вы удивитесь как хорошо он покрыт индексами и как мало там будет циклических переборов записей. - в большинстве проектов нагрузка на sql (время исполнения) несущественна по сравнению с нагрузкой на процессор и затратами на интерпретацию скриптов. Проще говоря: тормозит не mysql, а php - огромную роль играет правильность проектирования структуры данных, выбор связей и их реализация средствами системы инфоблоков или таблиц. Проще говоря: устранить тупняки гораздо правильнее грамотным проектированием, чем оптимизацией запроса, который Битрикс родил по вашим указаниям. - кеширование позволяет сэкономить на времени исполнения запросов, а грамотное распределение логики по компонентам позволяет вообще их не вызывать. Есть правило: главная страница сайта (обычно не самая простая) не должна отправлять запросы к БД при включенном кеше. Если вы это сделали, что вам горя с того, что иногда будут вызываться тяжелые (на десятые доли секунды) запросы? - выбор типа таблиц InnoDB/MyISAM с учетом специфики проекта и сервера тоже помогает. - наиболее критичные по производительности вещи можно и нужно реализовывать не инфоблоками. Инфоблоки (база в базе) дают гибкость в ущерб производительности. Нужна производительность -- делайте таблицами, API для этого есть. - недавно Битрикс сделал настраиваемую из админки кластеризацию БД на стандартных механизмах MySQL - любой отдельно взятый медленный запрос можно ускорить на счет всего стека возможностей: от архитектуры проекта и данных до прямого тюнинга БД и запроса - если проект тупит в целом, для нормального бизнеса обычно не проблема перейти на более серьезное железо. Купить хороший сервер стоит как 2-3 месяца работы хорошего специалиста. Арендовать – как 2 недели. И бизнесу это нравится. Есть мнение что другие свойства Битрикса экономят куда больше денег. - для действительно серьезных задач есть Oracle и MS SQL. Большому кораблю -- нормальную СУБД.

Вывод по первой части. Битрикс – специфическая система, удивительная на первый взгляд. Есть мнения что она ужасна и наполнена неправильными решениями, есть мнения что она проста и понятна, потому и работает. Мое мнение в том, что этот набор простых и гибких решений хорошо работает. Он работает на клиента, он работает на бизнес студии, он работает на перспективу. Несмотря на то что технические решения далеко не однозначны, я не вижу кому от них плохо. Возможно, вы привыкли к другому. Система реализует особую идеологию, возможно не самую красивую, зато исключительно эффективную. Если оно отличается от того, что вам близко и понятно, и вы недовольны, спросите себя, как эта система развивается 10 лет? Как сохранена полная обратная совместимость до самых ранних версий? Как удается запускать 2 релиза в год? Вы знаете другую такую компанию? Мне кажется, тут есть о чем подумать. Часть 2: Идеология и архитектура платформы 1с-Битрикс. ООП, ORM, Паттерны проектирования, MVC Часть 3: Битрикс для бизнеса. Взгляд сисадмина, разработчика, директора

Спасибо за внимание.

ИНТЕРВОЛГА — компетентный веб-интегратор. Наша специализация — сложная разработка на 1С-Битрикс

Веб-интеграция - это создание крупных информационных веб-систем , глубоко интегрированных в бизнес Заказчика. Это снижение затрат на работу с клиентами, рост продаж и автоматизация процессов.

ИНТЕРВОЛГА –  компетентный веб-интегратор . Мы можем решить все задачи веб-интеграции собственными силами. Большинство  наших проектов  – комплексные, интеграционные.

Наш принцип: приносить пользу бизнесу клиента за счет осмысленного применения веб-технологий. 

Оставьте заявку на обсуждение интеграционного проекта .

Оцените статью:

Спасибо, ваш голос успешно добавлен!

www.intervolga.ru

Чем поможет архитектору «NoSQL» и… поможет ли? / Блог компании 1С-Битрикс / Хабр

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"

Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.

А особенный трепет вызывают мелькающие в сети мозгораздирающие эскизы архитектур, типа кружочка из датацентров, работающих в «мастер-мастер репликации» на нескольких континентах:

Но… когда начинаешь серьезно использовать «новую» технологию в боевых проектах, понимаешь, откуда это все пошло, в чем причина тех или иных архитектурных решений: колечек датацентров и прочая мистика — формируется практическое и простое, «мурочное» понимание — которым хочется поделиться с коллегами, дабы не наделали архитектурных ошибок и не поплыли на плоту через океан. Об этом, в принципе, статья.

Чем же не устраивает старый, добрый ACID?
Ну вроде все предусмотрено — атомарность, согласованность, изоляция транзакций и надежность фиксации. Пробуй, строй, эксплуатируй. В ISO SQL прописали уровни изоляции транзакций — ну что еще не хватило для полного счастья, когда можно все детерминировать?

Что вызвало причину появления «CAP ереси» в стиле выбери только 2 из трех? :-)

Ответ очевиден — бизнесу нужны новые, «сверхзвуковые» возможности хранилищ данных:

Чем не устраивают «классические» кластера БД?
Из популярных:

А электронный бизнес требует и требует:

Понятно, что этот поток требований медленно, но верно вел к суициду… но
Ответ программистов — можно!
… Но если долго просить программистов сделать невозможное — они сделают!Не все знают, что для полноценного программирования достаточно языка C, а для людей с чувством прекрасного можно излить душу и на C++ — так нет, под давлением бизнеса: «как можно программировать быстрее и чтобы все могли?» — родились технологии, которые на мощном железе сейчас даже уже работают: C#, java, python, ruby ...

Так вот, прошло не так много времени, как в начале нынешнего столетия появились «NoSQL» продукты и стало возможным:

Причем, судя по всему, кашу заварил Amazon с DynamoDB:

DynamoDB is the result of 15 years of learning in the areas of large scale non-relational databases and cloud services. а затем идеи стали клонироваться в виде фейсбуковской Cassandra:Apache Cassandra was developed at Facebook to power their Inbox Search feature by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik. It was released as an open source project on Google code in July 2008. И конечно без Google BigTable тут не обошлось.

Что же это за «серебряная пуля» такая?

А семь шапок сошьешь? И семь сошью...
При углубленном изучении «NoSQL» продуктов, а последний продукт с которым я плотно работал был Amazon DynamoDB (очень похожий на Apache Cassandra) — стали проявляться «скрытые подводные камни и ограничения», которые никак кроме как «платой за вседозволенность» не назовешь:
Писать можно на любую ноду кластера, а читать ...
А читать, по умолчанию, устаревшую неконсистентную информацию :-) А как вы хотели — информация же распространяется с ограниченной скоростью. Ну конечно можно поставить флажок и прочитать только что записанную информацию — но придется подождать-с.
Можно разместить ноды кластера на разных материках, но...
Но опять-таки, нужно знать, что информации нужно время — чтобы она разошлась по континентам и приложение должно уметь это обработать (видим переключение ответственности, блин… снова на программиста :-) ).
Можно выключать любую ноду кластера, рубить топором сетевые кабели, но...
Устойчивость к разделению кластера реализована за счет технологий, похожих на версионность — но периодически нужно будет запускать поиск рассогласований типа «Anti-entropy using Merkle trees».
Добавлять ноды кластера когда душа пожелает
Можно, но конфигурировать остальные ноды все-таки придется, иногда с ломом и паяльником. А дальше — интереснее.
Ограничения Amazon DynamoDB
В наших проектах мы используем DynamoDB — передовое «NoSQL» решение от Amazon. Давайте рассмотрим его более подробно ниже.
Типов данных — откровенно мало
Число, строка, бинарные данные. Забудьте про DATETIME (их можно эмулировать таймстампом, но становится иногда не по себе).
Индексы добавлять можно, только… сразу
Индексы нужно указать сразу, их должно быть не более — 5 на таблицу. Причем добавлять их в существующую таблицу — нельзя, нужно ее удалять, пересоздавать и перезаливать туда данные. Спокойный сон архитектору — обеспечен.
Размер данных
Можно хранить любой объем данных, но… размер одной «строки таблицы» с именами и значениями «колонок» не должен превышать 64КБ. Правда число «колонок» не ограничивается. И на одной ноде кластера (c одним значением основного индекса hash key) при наличии дополнительных индексов нельзя хранить больше 10ГБ, так то. Видимо зря написал «колонок». В «NoSQL» нередко понятия схемы данных просто нет, поэтому в каждой «строке таблицы» могут быть разные «колонки» или «атрибуты».
Запросы...
Можно выбрать данные только по одному индексу (есть еще основной (hash key) индекс, но диапазонные выборки делать по нему нельзя — только константные). Отсортировать — только по одному индексу. Забудьте про сложные «WHERE, GROUP BY», не говоря о подзапросах — «NoSQL» движки их просто эмулируют и могут выполнять очень медленно. Можно выполнять более сложные выборки — но методом полного сканирования таблицы (пресловутый table scan) и затем поэлементной фильтрации результатов на серверной стороне, что и долго и дорого.
Транзакции — а что это?
Транзакции… иногда они нужны :-), а гарантируется лишь атомарное обновление отдельных сущностей (есть правда приятные плюшки с чтениями-инкрементами за одну операцию). Так что транзакции придется эмулировать — а то вы хотели, если данные «размазаны» по 20 серверам/датацентрам всего земного шарика?
Пляски с атрибутами
Нередко в «NoSQL», в т.ч. DynamoDB начинаю глумиться над основателями реляционной теории и создавать в строках ужасы типа: user=john blog_post_$ts1=12 blog_post_$ts2=33 blog_post_$ts3=69…

где $ts1-3 — таймстампы публикаций пользователя в блог.

Да, удобно получить список публикаций за один запрос. Но работа программиста — увеличивается.

Выводы
1) Прежде чем выбирать для проекта «NoSQL» хранилище, вспомните причины появления франкенштейна подобного класса продуктов, что часто это не что иное, как набор «memcached» подобных серверов с надстроенной довольно простой логикой и, соответственно — сохранение данных и простые выборки будут, действительно, летать, а что-то посложнее… придется шаманить на стороне приложения. 2) Еще раз перечитайте теорему Брюера и найдите подвохи :-) 3) Внимательно посмотрите документацию по используемому продукту — особенно ограничения. Скорее всего вы встретите множество сюрпризов — и к ним нужно будет аккуратно подготовиться. 4) И посмотрите напоследок в глаза Кодду

Да, вы получите очень надежное, высокодоступное, поддерживающее гибкие схемы репликации современное решение — но платить, увы, придется жесточайшей денормализацией и усложнением логики работы приложения (в т.ч. эмулировать транзакции, жонглирование тяжелыми данными внутри приложения и т.п.). Выбор — за вами!

Всем удачи!

habr.com

bitrix - Википедия

Материал из Википедии — свободной энциклопедии

(перенаправлено с «»)Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 2 февраля 2018; проверки требуют 13 правок. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 2 февраля 2018; проверки требуют 13 правок.

1С-Битрикс — система управления содержимым от российской компании 1С-Битрикс.

Имеет несколько «редакций» — лицензионных версий: Старт, Стандарт, Малый бизнес, Бизнес, которые отличаются включаемыми модулями системы. Существует также Enterprise-редакция, предназначенная для разработки нестандартных и высоконагруженных проектов.

Разработчик[ | ]

Компания «Битрикс» основана в 1998 году группой специалистов отдела интернет-технологий и финансовых телекоммуникаций АКБ «Инвестбанк» под руководством Сергея Рыжикова.

В 2007 году компании 1С и Битрикс объявили о создании совместного предприятия ООО «1С-Битрикс» (доли партнёров равны и составляют 50 %). Новая компания получила право распространения продуктов компании Битрикс на территории Российской Федерации. Финансовые подробности сделки не разглашаются. При этом условия работы партнеров Битрикс не изменились[1]. Западное направление (рынок англо- и немецко-язычных стран) компания Битрикс развивает самостоятельно, без компании 1С[2].

История разработки[ | ]

Система управления содержимым веб-сайтов Битрикс (с 2007 года используется название «1С-Битрикс») выпущена как отчуждаемый от разработчиков продукт в 2002 году.

30 мая 2018 года выпущена последняя на данный момент версия ядра под номером 18.0.0.

Технические характеристики[ | ]

Для хранения данных сайта используется файловая система сервера и реляционная СУБД. Продукт работает на UNIX- подобных платформах, включая Linux.

Поддерживаемые СУБД[ | ]

Поддерживаются следующие СУБД: MySQL.

Ноу-хау[ | ]

Запатентованы системы кеширования и композитного сайта.

Модульность[ | ]

Количество модулей в устанавливаемой системе зависит от редакции продукта[3].

Продукты компании[ | ]

Награды[ | ]

Позиции в рейтинге CMS на территории СНГ[ | ]

По состоянию на I полугодие 2013 года, «1C-Битрикс: Управление сайтом» занимает первое место в рейтинге платных тиражных CMS[7] России по версии iTrack. В общем рейтинге CMS, составленном этой компанией, «Битрикс» занимает четвёртое место.

По данным агентства iTrack, «1С-Битрикс: Управление сайтом» — самая популярная коммерческая CMS в России. Её используют 58% всех сайтов, созданных на платном движке[8].

Согласно Data Insight, «1С-Битрикс: Управление сайтом» — лидер среди коммерческих CMS в России для крупных интернет-магазинов. Её используют 28,7% крупнейших онлайн-ретейлеров[9].

Магазин расширений и готовых сайтов MarketPlace[ | ]

Официальный сайт магазина расширений и готовых сайтов 1С-Битрикс: Маркетплейс.

В магазине расширений предлагаются платные и бесплатные решения партнеров в виде модулей к 1С-Битрикс: Управление сайтом и 1С-Битрикс: Корпоративный портал. Установить решения из 1С-Битрикс: Маркетплейс возможно только при наличии активной лицензии 1С-Битрикс.

Партнёрская система компании 1С-Битрикс[ | ]

Компания «1С-Битрикс» сама не занимается разработкой проектов для конечных заказчиков и имеет обширную сеть студий-партнёров (более 15 000 на 2018 год).

Сертификация 1С-Битрикс от ФСТЭК России[ | ]

По итогам инспекционного контроля ПО «1С-Битрикс» проверены все функции безопасности. Зафиксировано отсутствие недекларированных возможностей по четвертому уровню (НДВ-4).

Обновленные сертификаты будут действовать до 2020 года[10].

Взломы системы[ | ]

Примечания[ | ]

  1. ↑ Новости «1С-Битрикс»
  2. ↑ Bitrix — About Bitrix, Content Management Systems, Intranet Portal Solutions
  3. ↑ 1С-Битрикс — Редакции продукта
  4. ↑ Номинанты и Лауреаты
  5. ↑ 1С-Битрикс: Корпоративный портал, Журнал «PC Magazine/RE», 20 ноября 2008
  6. ↑ 1С-Битрикс - Сертификаты и награды. www.1c-bitrix.ru. Проверено 20 октября 2016.
  7. ↑ iTrack → Исследования → Рейтинг CMS
  8. ↑ Рейтинг CMS – самые популярные движки для сайтов: графики, описания и данные, данное исследование подтверждает и наша компания iTrack (рус.). itrack.ru. Проверено 15 мая 2018.
  9. ↑ CMS для интернет-магазинов | Data Insight (рус.). datainsight.ru. Проверено 15 мая 2018.
  10. ↑ «1С-Битрикс» обновила сертификаты от ФСТЭК России, CNews.ru. Проверено 29 мая 2018.
  11. ↑ SecurityLab.ru переезжает на систему «Битрикс: Управление сайтом», Компьюлента, 27 мая 2005 г
  12. ↑ Взлом CAPTCHA: надёжный Битрикс, журнал «Хакер», 25 апреля 2006 г
  13. ↑ Множественные уязвимости в последних версиях CMS 1С-Битрикс.

Литература[ | ]

Ссылки[ | ]

encyclopaedia.bid

Prostoy-Site | Все права защищены © 2018 | Карта сайта