Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Пример применения Couchbase в связке с PHP

Anna | 31.05.2014 | нет комментариев

Эта статья не призывает бросать все, к чему вы привыкли и переходить на применение Couchbase, без оглядки на каждый ваш прошлый навык и косяки, с которыми вы сталкивались, при разработке собственных планов. Эта статья имеет своей целью быть лишь коротким изложением спецтехнологии применения Couchbase Server в связке с PHP и только. Допустимо она будет увлекательна некоторым как изложение вероятностей, а допустимо и как оценочный взор на перспективы.

Что это такое и с чем его едят

Couchbase это очередное направление NoSQL баз данных, разрабатываемое компанией Couchbase, Inc, и является прямым преемником традиций и задач своего родителя CouchDB. Это документоориентированная база данных, что подразумевает под собой хранение всякой отдельной записи как документа, правда это не жесткое правило, и в качестве записи может выступать всякое значение (вплотную до BLOB строк), но прелесть этой (да и других баз тоже), это именно документоориентированный способ хранения данных.

Документоориентированный способ хранения данных подразумевает под собой то, что все данные будут храниться в виде так называемых документов, т.е. комплектов полей, объеденных в документ на тезисах здорового смысла и всеобщей логики, присутствующей в записи. Примером такой записи может выступать скажем профиль пользователя, со списком полей как: логин, пароль, email и прочие. Эталоном хранения документов в данном случае выступает формат документа в виде JSON строки. Данный формат был выбран создателями осмысленно, так как является довольно знаменитым, легко интерпретируемым и человеко-читаемым. Но не суть значимо. Значимо Дабы вы имели представление о том, что такое документ и как он выглядит внутри базы данных.

Требуемые компоненты для работы

Для работы с Couchbase при помощи PHP нам потребуется несколько пунктов программного обеспечения:

Позже удачной установки каждого этого добродушна и удачного запуска, у нас возникает вероятность применять класс, под наименованием Couchbase, изложение которого находится в официальном Git репозитории Couchbase. Для комфорта последующего применения советую вам добавить его к себе в план, чтобы в вашей любимой IDe удачно заработал автокомплит.

Помимо того, для комфортной работы, вам потребуется завести в самом couchbase обособленный Bucket (аналог базы данных) вследствие которому вам не придется гадить в всеобщий и типовой default. Делается это путем захода на адрес localhost:8091/index.html#sec=buckets и нажиманием на кнопочку «Create new bucket».

Начинаем кодить

Кодить кое-что абстактное не имеет смысла, потому возьмем абсолютно определенный пример, приведенный выше, а именно — профиль пользователя. Возможен у нашего пользователя имеются несколько полей: логин, пароль, email ну и из неявного — это его идентификатор типа integer. В JSON представлении, полученный документ у нас будет иметь вид:

{
  "login": "megausername",
  "password": "my secured password!",
  "email": "email@example.com"
}

Для начала нам нужно узнать, как это дело дозволено сберечь в базу данных и как его оттуда дозволено достать. Делается это довольно легко, и восхитительно видно в дальнейшем примере:

<?php

/**
 * В этой строке создаем подключение к базе данных Couchabse с указанием всех нужных параметров, с некоторыми 
 * оговорками. Скажем имя хоста к которому необходимо подключаться, гужно передавать в виде массива, потмоу что 
 * Couchbase Почаще каждого работает в виде кластера, и для удачной работы кластера типа master-master необходимо будет 
 * указывать оба хоста, на которых расположен Couchbase Server. Имя пользователя, пароль базы данных и имя Bucket в 
 * изложении не нуждается, а вот конечный параметр, говорит нам о том, что подключение к базе данных не необходимо 
 * устанemit(doc.login, parseInt(userid[1]));
    }
}

Вследствие вышеописанному JavaScript способу дозволено осознать, что в индекс (которые формируется при помощи способа emit) попадут только записи у которых присутствует поле login. Как видим, функция JavaScript исполнена в виде callback функции, которая будет применена к всякой записи, находящейся в данном Bucket. Следует учесть что view дозволено создавать в всякий момент существования жизненного цикла bucket. Т.е. если у вас появилась надобность добавить новейший функционал, вы без задач можете добавить новые view и жить дальше, как вам хочется.

И так. Разберемся как же мы можем узнать идентификатор пользователя, если мы знаем только его login. Для этого нам нужно сделать новейший индекс (мы его сделаем сразу из PHP кода) и вызовем его.

/**
 * Создаем изложение нашего view 
 */
$designedDocument = array(
    'language' => 'javascript',
    'views' =>array(
        'login' => array(
            'map' => 'function (doc, meta) {if (meta.type == "json" && doc.login) {var userid = meta.id.split("::"); emit(doc.login, parseInt(userid[1]));}}'
        )
    ),
);

/**
 * Вызываем сохранение данного дизайн документа в базу данных 
 */
$this->_db->setDesignDoc('userFields', json_encode($designedDocument));

Если сразу позже выполнения данного кода, мы зайдем в панель управления Couchbase то увидим (на крупных объема) справа вверху прогресс создания индекса. По заключении которого, дозволено проверить его работу, открыв его в панели управления и нажав на кнопку «Show Results». В результате мы увидим пары ключ/значение, которые были генерированны JavaScript callback способом.

Из PHP кода мы можем получить выборку по дальнейшему запросу:

// результат придет не в виде JSON строки, а в виде массива данных
$result = $this->_db->view('userFields', "login");

В результате будет массив из 2-х элементов: rows — где будет содержаться всеобщее число записей по данному индексу и поле rows — в котором будет массив массивов из нашей выборки в виде: array(‘_id’ => ‘profile::0′, ‘key’=>’megausername’, ‘value’=>0). В этом массиве поля: _id — это идентификатор документа, тот, что попал в выборку. Key — ключ тот, что был указан при образовании индекса, и value — значение которое мы сформировали.

Но следует учесть тот факт, что таким образом мы получим каждый индекс, что не вовсе подходит нам для поиска. А если нам потребуется обнаружить только идентификатор? Не перебирать же каждый индекс вручную. Безусловно нет. И для этого, при выполнении всякого запроса к view дозволено указать добавочные параметры. Скажем если мы хотим узнать только идентификатор заданного по login пользователя, то мы обязаны указать определенный ключ в запросе к view. Делается это так:

$result = $this->_db->view('userFields', "login", array('key'=>'megausername'));

И вот данный радостный момент, когда в итоге, у нас будет содержаться только запись, ключ у которой равен ‘megausername’. С которой мы можем трудиться и быть радостными. Вот только есть один подводный камень. Как говорилось выше, индекс перестраивается не в момент добавления либо метаморфозы записи в данный Bucket, а только лишь при достижении определенного процента фрагментации Bucket.

Возможен у нас есть надобность проверить на уникальность имени пользователя перед выполнением какой либо операции. Скажем при регистрации пользователя. Безусловно мы исполним запрос к этому view и будем исследовать результат базы данных. Впрочем существует вероятность того, что в данный же самый момент только что зарегистрировался пользователь с таким же именем, а индекс еще не поспел перестроиться. Безусловно нам придет информация что в индексе такой записи нет и мы получим некоторую коллизию. чтобы избежать такой обстановки, есть вероятность, при вызове view индекса, указать ему надобность перестроения индекса. Т.е. все операции, которые не были исполнены по данному индексу, вначале будут закончены, а позже чего теснее будет исполнен запрос и возвращен итог. Делается это путем добавления опции stale со значением FALSE. Делается это вот так:

$result = $this->_db->view('userFields', "login", array('key'=>'megausername', 'stale'=>FALSE));

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

Завершение

Как вы могли удостовериться, трудиться с Couchbase Server не так уж и трудно, значимо перед началом работы исчерпывающе исследовать документацию и не забывать думать и исследовать свои действия. Я не буду агитировать всех переходить на Couchbase, но хотелось бы сказать, что лично для меня, вероятность трудиться с базой данных без кардинального метаморфозы конструкции при добавлении новых полей, была крайне «аппетитным» фактором при разработке системы, описанной выше. Впрочем грозная действительность возвращает все на свои места. В моем определенном случае, встал вопрос о образовании статистики по отдельно взятым полям в настоящем времени, и взаимодействии с системой хранения/анализа статистики, запущенной на MSSQL движке. Данный факт привел к организации «костылей» для комфортной работы наших DBA разработчиков, что вылилось реально к дублированию системы управления полями в формате SQL. Если вы захотите применять NoSQL движки баз данных в своих планах, то советую начать со standalone планов, которые не завязаны на внутреннюю инфраструктуру, т.к. интегрироваться безболезненно у вас не получится.

Если у вас возникнут вопросы, советую исследовать документацию, которая находится по адресуwww.couchbase.com/documentation
Если у вас сохранится интерес к этой теме, то ее дозволено будет раскрыть на несколько больше трудном ярусе. Разглядеть методику миграции с SQL мышления на NoSQL документооринтированную в следующих статьях. Разглядеть как дозволено организовать GROUP BY, ORDER и прочие интересности при помощи Couchbase, а также разглядеть больше велико вопросы по оптимизации и проектированию документооориентированных баз данных.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB