Началось всё с вопроса "а что было бы, если бы Битрикс работал на MongoDB вместо MySQL?". Можно долго рассуждать об SQL и NoSQL решениях, но все равно стоит признать - вопрос интересный. Ничего, толком, не зная про MongoDB за пару вечеров были изучены пара заметок, о том как это круто и небольшой мануал по использованию MongoDB. После небольших экспериментов было принято решение испытать MongoDB в действии, например переделать функцию CFile::GetFileArray(). Именно это решение и сделало эксперимент "неудачным" - оказалось, что функция кеширует результат и запрос в базу производится только раз, а значит, достоверно измерить результат на одной записи сложно. Отредактировав исходный код, удалось получить время работы скрипта с использованием кеша и без:
for($i=0; $i<10000; $i++) { $arFile = CFile::GetFileArray(1); }
// Выполнение с кешем 1,89 сек.
// Без кеша 5,88 сек.
Вот, что получилось с MongoDB таблицей:
for($i=0; $i<10000; $i++) {$arFile = CMDBFile::GetFileArray(1);}
// Выполнение с кешем 1,86 сек.
// Без кеша 5,09
Прирост скорости есть, но не тот, которого я ждал. Что показалось странным - результаты MongoDB с добавленным индексом по "ID" (поле по которому и производится выборка) делает данные несколько хуже и в итоге проигрывает SQL решению. Поставленная задача была слишком простой, что бы в ней мог ошибиться новичок вроде меня, поэтому вывод один: выбранная задача не раскрывает всех возможностей и преимуществ MongoDB.
Ну и самый интересный участок кода для любопытствующих:
UPDATE: Заполнил таблицы разными строками, таким образом, данные не будут зависеть от кеша и вот что получилось:
MySQL:
for($i=1; $i<10001; $i++) {$arFile = CFile::GetFileArray($i);}
3.69 сек.
MongoDB:
for($i=1; $i<10001; $i++) {$arFile = CMDBFile::GetFileArray($i);}
1.99 сек.
Так получается, что эксперимент не такой уж и неудачный
UPD2: Ведется разработка модуля, аналогичного инфоблокам, основанному на MongoDB. На данном этапе программируется API для работы с инфоблоками. В планах разместить отдельный пункт меню - наравне с инфоблоками и Highload инфоблоками.
Постоев Олег, именно) Я как-то смотрел выступление технического специалиста из Мамбы. Он рассказывал что у них данные в разных базах хранятся. Например в MySQL только сообщения. Всё остальное в NoSQL. Мол только так удалось достигнуть требуемой производительности и надёжности. И NodeJS сейчас комбинируют с PHP или с Ruby. Просто потому что так удобнее решать некоторые задачи. Как-то в работе встречал интеграцию 1С и Битриксом написанную на NodeJS, потому что предыдущему разработчику так захотелось)
UPD2: Ведется разработка модуля, аналогичного инфоблокам, основанному на MongoDB. На данном этапе программируется API для работы с инфоблоками. В планах разместить отдельный пункт меню - наравне с инфоблоками и Highload инфоблоками.
tarantool во всю используется на avito например. технология инфоблоков с сохранением совместимости api с тут на отлично бы положилась. а монго - это когда для стартапчиков - js-никам запилить по быстрому пртотип на ноде с монгой
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».