lnroma 22 мар 2016 в 14:22

MongoDB хранение деревьев

3 мин

MongoDB * PHP *

Из песочницы

-13

Комментарии 54

MetaDone 22 мар 2016 в 14:33

$arrData =  array(
            'page' => $_POST['page_id'], // id страницы в mongo
            'time' => $time, // время написания комментария
            'name' => $_POST['name'], // имя написавшего
            'comment' => $_POST['comment'] // сам комментрарий
        );
В примере представлен алгоритм и в нём есть допущения, а именно отсутствие сортировки комментариев и её персистетности.

А еще нефильтрованные данные из $_POST, и header прямо в коде.

lnroma 22 мар 2016 в 14:40

Это же не принципиально, во первых, если расписывать всё до мелочи алгоритм затеряеться в проверках и будет несовсем ясно человеку суть. А $_POST фильтрую при рендере, и не вижу в этом ничего страшного.

ProfBiss 22 мар 2016 в 18:38

Так же в какой то момент столкнетесь с тем что вы больше ничего в документ не можете добавить. Т.к. есть лимит на размер документа. Не есть конечно и GridFS. Мне кажется вам правильно не перезвонили.

lnroma 22 мар 2016 в 18:40

Так то храниться отдельно комент и е го потомки в одном документе. т.е. получаеться при выборке коллекция комментариев, в которых есть дочерние элементы.

ProfBiss 22 мар 2016 в 19:38

Погодите я что то не понял. А где у вас потомки хранятся?

lnroma 22 мар 2016 в 19:59

По сути есть коментарий_родитель-> (коментарий_потомок, коментарий_потомок) я привёл пример в посте.

ProfBiss 22 мар 2016 в 20:31

Ну тогда вы лукавите… Или в посте или в комментарии. В посте у вас вся ветка внутри одного документа и в определённый момент у вас новый коммент просто не поместится в документ. А в комментарии вы уже пишете что потомки не в том же документе что и коммент 0 уровня. Определитесь уж.

lnroma 22 мар 2016 в 21:06

да нет не вся ветка, я в посте не привёл все данные 'сопутствующие' что бы легче читать было, в посте приходит id страницы. Если нет в посте reply производиться insert в монго т.е. комментарий первого уровня, а вот уже реплики на комментарий привязываеться к родителю(т.е. тогда когда есть reply ), по коду к стати довольно хорошо это видно, видимо плохо видно, видимо мой касяк.

ProfBiss 23 мар 2016 в 06:42

Да нет я всё прекрасно понял. У вас документ в коллекции comments выглядит вот так http://joxi.ru/DrlDO6h4edbqrP. То есть у вас допустим к статье есть скажем 5 корневых комментариев у вас в этой коллекции будет 5 документов, и внутри этих документов будет вся ветка. И в какой то момент вы упрётесь в объём документа! Особенно с учётом того что вы не просто сам коммент там хранить будете. Вы в какой то момент захотите хранить всевозможную мета информацию.

gearbox 22 мар 2016 в 18:00

а зачем фильтровать данные при записи? Их фильтровать надо при отдаче, если они иcпользуются для построения верстки. В SPA которые сами строят на клиенте и строят строго через DOM — вообще ничего фильтровать не надо (ок, надо ескейпить кавычки если отдаем json-ом)

borodyadka 22 мар 2016 в 18:08

Фильтровать при записи нужно как раз для того, чтобы не тратить каждый раз ресурсы на фильтрацию при отдаче. А ещё это в какой-то мере поможет уберечься от NoSQL-иъекций.

gearbox 22 мар 2016 в 18:50

В большинстве случаев, с которыми я встречался — подобная логика ~~граничила с ересью~~ не применялась исходя из следующих соображений — логика фильтрации зависит от логики рендера — логика рендера поменялась — меняем логику фильтрации. Если мы храним модифицированные данные — попадаем на лишние телодвижения. Плюс это неправильно — модифицировать данные полученные от пользователя, они могут использоваться не только при рендере, в каждом контексте свои правила и ограничения. А если важны ресурсы — переносите рендер на клиента и все.

От инъекций так не защищаются. Для sql это хранимые процедуры + параметризованные запросы, для noSQL пример который вы привели — не СОХРАНЯЕТ пользовательские данные а использует их в запросе — немного не то что мы обсуждаем. И там нужна не фильтрация/экранизация а санитизация — чуть чуть другая процедура.

borodyadka 22 мар 2016 в 19:07

По поводу первого пункта мы можем долго спорить. Всё же я считаю, что если вы храните любые данные, пришедшие от юзера, сколько бы и какими бы они ни были, то это, мягко говоря, странно. Когда вы проектируете сервис, то с большой долей вероятности знаете чего хотите и примерно представляете, что будет дальше. Исходя из этого проектируете модель данных. Вообще у меня есть сомнения, что мы говорим об одном и том же, изначально мне показалось, что вы предлагаете сохранять любые данные от юзера (100-мегабайтный JSON, картинка с котятами и т.п.) как значение, а потом из него пытаться выбрать нужные поля.

По поводу "не сохраняет". Это не важно. Даже, если злоумышленник может получить список всех юзеров сервиса (включая их личные данные), то это уже плохо.

magamos 22 мар 2016 в 14:42

if(!is_null(self::$_connect)) {
if(isset(self::$_connect)) {
$write = new MongoDB\Driver\BulkWrite();
$writeConcern = new MongoDB\Driver\WriteConcern(MongoDB\Driver\WriteConcern::MAJORITY);
$write = new \MongoDB\Driver\BulkWrite();
$writeConcern = new \MongoDB\Driver\WriteConcern(MongoDB\Driver\WriteConcern::MAJORITY);
$path = '';
if(isset($_POST['path']) && !empty($_POST['path'])) {
$path = $_POST['path'];
} else {
$path = 'replies';
}
$path = (isset($_POST['path']) && !empty($_POST['path'])? $_POST['path']: 'replies';
array('_id' => new MongoDB\BSON\ObjectID($reply)), // загружаем комментарий
array('_id' => new \MongoDB\BSON\ObjectID($reply)), // загружаем комментарий

lnroma 22 мар 2016 в 14:43

Короткий синтаксис не использую, снижает читабельность кода. http://php.net/manual/ru/mongodb-driver-writeconcern.construct.php а слэшь перед namespace что вы этим хотели сказать?

magamos 22 мар 2016 в 14:46

В одном месте он у Вас стоит, в другом нет. Шатание стиля.

lnroma 22 мар 2016 в 14:48

Ok, спасибо, незаметил даже...

serginho 22 мар 2016 в 14:53

То же самое можно сделать в мускуле с помощью JSON Data type

franzose 23 мар 2016 в 12:33

Да и в Постгресе с ним же.

markoffko 22 мар 2016 в 15:03

>if(isset($_POST['reply']) && !empty($_POST['reply'])) {

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

nowm 22 мар 2016 в 17:56

И, на всякий случай, чтобы это замечание стало конструктивным, я добавлю, что можно просто написать if(!empty($_POST['reply'])) — по смыслу это будет то же самое, что и «isset && !empty». Выражение «empty» полностью покроет как ситуацию с несуществующим индексом «reply», так и ситуацию, когда значение пустое или равно нулю (или чему-то, что в приведении к boolean возвращает FALSE).

Для иллюстрации, выражение if(isset($_POST['reply']) && !empty($_POST['reply'])) по своей логике выглядит так:

if(isset($_POST['reply']) && isset($_POST['reply']) && $_POST['reply'] == false) {
    // Do something
}`

Связка «isset && !empty» в качестве связки — это, примерно, как всё время повторять по два раза, или, например, по два раза повторять одно и то же — всё время одно и то же по два раза в тексте или разговоре повторять (или в тексте повторять по два раза, например).

nowm 22 мар 2016 в 18:06

$_POST['reply'] == false

Сорри, вместо «==» нужно было поставить «!=» — опечатался.

lnroma 22 мар 2016 в 18:19

Мне стыдно (( замечание конструктивное.

nsinreal 22 мар 2016 в 15:03

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

lnroma 22 мар 2016 в 15:19

Какой по вашему мнению 'приличный язык програмиирования'? Пока я к сожалению незнал о графовых б.д. стыдно. Спасибо вам за наводку.

minisotm 22 мар 2016 в 15:14

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

lnroma 22 мар 2016 в 15:16

Просто пишем все коментарии пользвателя в sql и получаем, это частные задачи, не относящиеся к алгоритму(последовательности действий).

Staltec 22 мар 2016 в 16:21

С MongoDB в итоге всё и приходит к таким костылям.

lnroma 22 мар 2016 в 16:32

Согласен кастыль. Но на mysql кастыль построить дерево. На монго выбрать коментарии, подсчет коментариев. По этому и выбор падает на совместном использование. MySql хранение коментариев подсчеты и т.д. монго для хранения структуры.

webmoder 22 мар 2016 в 18:23

Но на mysql кастыль построить дерево
Дерево из однородных данных(комментарии в данном случае) в реляционных бд строится достаточно просто и без костылей.

table comments

id
parent_id
…

Что в дальнейшем позволяет сортировать как угодно, получать все комменты одного автора, считать количество и т.п
Не вижу в этом костылей ИМХО.

lnroma 22 мар 2016 в 18:34

ok. Вы имеете id | parent_id | comment | name минимальный набор полей как построить дерево. Сделать рекурсию и к каждому корневому коментарию, выбирать с базы parent'ы. Ок, всё выбираеться. Но есть одно но вы сделали кучу запросов и сервер упал на этапе, просто выборки. Алгоритм выполняет много запросов и обрабатывает кучу данных, что не так оптимально. И так вы модернизируете алгоритм вводите понятия level и right_id и left_id что бы одним запросом вытянуть все коментарии, в порядке комент level1-> комент level2 ->комент level1 всё вроде бы просто…
Но вам надо сформировать массив вида comment['parent']->array(comment[]) думаю ясно логика, вы делаете перебор линейного массива и строите, древовидную структуру. Так вот вы взяли данные, выполнили операции перебора этих данных и модификации в массив. В монгоДБ мы просто сохраняем этот массив и просто берём его, тут вы взяли данные и не произвели над ними операций. Какой алгоритм лучше по вашему мнению? Да и видно что вы не строили древовидные структуры?

ProfBiss 22 мар 2016 в 19:40

NestedSets в помощь! Любой уровень вложенности и любая глубина дерева выбирается одним запросом. Единственный минус. Дорогая вставка.

lnroma 22 мар 2016 в 21:00

именно этот алгоритм я вам и описал, недочитываете до конца или через строку?

ProfBiss 22 мар 2016 в 21:39

Хорошо извиняюсь. Не дочитал(разделять нужно комментарий на абзацы). В середине вы описали Nested Sets.

Однако дальше вы опять предлагаете то о чём я вам писал выше(пихать всю ветку комментариев в один документ). О том что в один прекрасный момент вы не сможете добавить очередной комментарий в ветку https://habrahabr.ru/post/279915/#comment_8815465

И да я не отрицаю для проекта с около нулевой посещаемостью и с десятком другим комментариев ваше решение подойдёт отлично.

P.S. Для продуктивной дискуссии всё же предлагаю вам для начала ознакомиться хоть немного с документацией MongoDB Limits and Thresholds

lnroma 22 мар 2016 в 22:02

Я тоже должен извиниться, я только начинаю изучать mongoDB, и нахожу всё больше и больше плюсов по сравнению с sql, может это просто первое впечатление. Ну да ладно, оффтоп, спс за ссылку.

webmoder 25 мар 2016 в 10:17

Хорошо, предлагаю решение проблемы дабы избежать рекурсивность.
Как правило в случае с комментариями необходимо иметь возможность получать полное дерево от корневого комментария или от дочернего зная его id.
проблему решить достаточно просто, вот пример таблицы:
id | parent_id | root_id | comment | name ...
В данном случае parent_id это всего лишь указатель структуры дерева не играющий роль при выборке полного дерева.
А root_id указатель на корневой комментарий позволяющий выбрать все дерево одним запросом.
Данный подход так же избавит от минуса NestedSets.

lnroma 25 мар 2016 в 10:24

Пример запроса привести сможете?

webmoder 25 мар 2016 в 10:40

//По id корня
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = {id} OR id = {id}
//По id дочернего элемента
SELECT
id, parent_id, root_id, comment
FROM comments
WHERE root_id = (SELECT root_id FROM comments WHERE id = {id}) OR id = (SELECT root_id FROM comments WHERE id = {id})
Если пугаетесь вложенных запросов во втором случае, то можно оформить в виде процедурки с 2 запросами.

lnroma 25 мар 2016 в 10:50

Хорошо, и как вы собираетесь без рекурсии обойтись, вам тот же массив надо будет перебирать по несколько раз выискивая parent_id а если вложеность в 5 уровней. Вы будете 5 раз перебирать масив с коментариями?

webmoder 25 мар 2016 в 11:17

Работоспособность не проверял, но думаю суть вы поймете.
$commentsTree = [];
$links = [];
foreach($comments as $comment){
if(array_key_exists($links, $comment['parent_id'])){
$parentComment = &$links[$comment['parent_id']];
$children = &$parentComment['children'][];
$children['comment'] = $comment;
$children['children'] = [];
}else{
$commentsTree[$comment['id']][];
$parentComment = &$commentsTree[$comment['id']];
$parentComment['comment'] = $comment;
$parentComment['children'] = [];
$links[$comment['id']] = &$parentComment;
}
}
всего в один проход мы можем собрать дерево, с учетом того что линейный набор данных отсортирован по parent_id или по дате.

lnroma 25 мар 2016 в 11:29

По вашему алгоритму вы построете только 2 уровня корень и один дочерний. Вот в этом то и суть проблемы. Вы видимо не сталкивалися с деревьями?

webmoder 25 мар 2016 в 11:30

внесу поправку:
перед }else{
забыл дописать:
$links[$comment['id']] = &$children;

lnroma 25 мар 2016 в 11:35

Тут тоже проблема вы выбрали данные. Но какой то парент выбрался первым в $links его нет а значит он запишиться как корень. А это означает что алгоритм ошибочно привяжет комент где то в root. А не как дочерний элемент.

webmoder 25 мар 2016 в 11:53

Если сортировать по parent_id такой проблемы не должно случиться.
Но я согласен это не совсем true way.
с другой стороны я не вижу проблемы в рекурсии на стороне приложения.

lnroma 25 мар 2016 в 11:32

michael_v89 25 мар 2016 в 12:23

Вам правильно написали, можно построить дерево комментариев к посту в один проход без рекурсии. Только лучше использовать объекты, они передаются по ссылке и можно дополнительные переменные объявить один раз в самом классе.

public function getCommentsTree($post_id)
{
    $comments = Comment::find()->where(['post_id' => $post_id])->indexBy('id')->all();

    $topLevelComments = [];
    foreach ($comments as $comment) {
        if ($comment->parent_id) {
            $parentComment = $comments[$comment->parent_id];

            $comment->parentComment = $parentComment;
            $parentComment->childComments[$comment->id] = $comment;
        } else {
            $topLevelComments[$comment->id] = $comment;
        }
    }

    return $topLevelComments;
}

class Comment
{
    public $id;
    public $parent_id;
    public $post_id;
    // ...

    // заполняется снаружи при загрузке из базы
    public $parentComment = null;
    public $childComments = [];
}

minisotm 22 мар 2016 в 18:43

Дерево теоретически можно хранить и в монго, таким образом, но писать дополнительные данные в сам документ с иерархией (напр общее кол-во, время последнего комментария и т.д.), а также обогащать данными другие сущности (напр. сущность пользователя- все его комментарии), но ИМХО- пока все лучше ложится на реляционную структуру.

НЛО прилетело и опубликовало эту надпись здесь

bromzh 22 мар 2016 в 16:37

http://www.postgresql.org/docs/current/static/ltree.html
http://www.postgresql.org/docs/current/static/functions-json.html

vasachi 22 мар 2016 в 18:24

ltree — ух ты, спасибо большое!

lnroma 22 мар 2016 в 18:37

Да postgresql умеет, но всё же пост не о postgre и не о проблеме построение деревьев а всё же о mongoDB.
P.S. Спасибо!

maximw 23 мар 2016 в 07:22

А почему mysql не любите?

lnroma 24 мар 2016 в 11:42

MySql хороша по всем параметрам. Но когда у проэкта возрастает посещаимость и нагрузки. Начинаються проблемы производительностью:

Код который делает перебор разбор данных, рендер и т.д.
Маштабируемость, невозможно на уровне о.с. сделать, так что бы, было несколько серверов с mysql, и какойто сервер балансер который распределял бы запросы по серверам(разграничение нагрузки)
Иногда приложению, не необходимо хранить структуру данных(допусти страницу в cms, понимаю грубый пример но всё же).

Я люблю разделение труда команды, т.е. php программист это один человек, mysql проэктироващик и программист это другой, и третьи лица фронтэнд разработчики. Такая команда добьёться большего результата. Работая в одном направление в месте.

ProfBiss 25 мар 2016 в 00:59

Вот черт. Вы ещё и mysql не знаете. О чём с вами разговаривать?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий