MongoDB в Битриксе. Небольшой отчет о «неудачном» эксперименте
Запись от 24.08.2014
Началось всё с вопроса "а что было бы, если бы Битрикс работал на MongoDB вместо MySQL?".
Можно долго рассуждать об SQL и NoSQL решениях, но все равно стоит признать - вопрос интересный.
Ничего, толком, не зная про MongoDB за пару вечеров были изучены пара заметок, о том как это круто и небольшой мануал по использованию MongoDB.
После небольших экспериментов было принято решение испытать MongoDB в действии, например переделать функцию CFile::GetFileArray(). Именно это решение и сделало эксперимент "неудачным" - оказалось, что функция кеширует результат и запрос в базу производится только раз, а значит, достоверно измерить результат на одной записи сложно.
Отредактировав исходный код, удалось получить время работы скрипта с использованием кеша и без:
Что показалось странным - результаты MongoDB с добавленным индексом по "ID" (поле по которому и производится выборка) делает данные несколько хуже и в итоге проигрывает SQL решению.
Поставленная задача была слишком простой, что бы в ней мог ошибиться новичок вроде меня, поэтому вывод один: выбранная задача не раскрывает всех возможностей и преимуществ MongoDB.
Ну и самый интересный участок кода для любопытствующих:
Заполнил таблицы разными строками, таким образом, данные не будут зависеть от кеша и вот что получилось:
UPD2: Ведется разработка модуля, аналогичного инфоблокам, основанному на MongoDB.
На данном этапе программируется API для работы с инфоблоками.
В планах разместить отдельный пункт меню - наравне с инфоблоками и Highload инфоблоками.
Можно долго рассуждать об 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.
Ну и самый интересный участок кода для любопытствующих:
function GetByID($FILE_ID) {
...
$mongo = new Mongo();
$cur = $mongo->base2->b_files->find(array( 'ID' => $FILE_ID ));
$newarr = iterator_to_array($cur, false);
$z = $newarr[0];
...
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 инфоблоками.