MongoDB

[AlexCooper]

Здравствуйте форумчане.
Обращаюсь к тем кто уже работал с данной базой данных. Интересует вопрос на который я не смог найти ответа прогуглив интернет.
Можно ли создавать коллекции внутри коллекций?
Востребованная структура данных:

PHP код:

  $uid = 1;
  $m = new Mongo();

  $db = $m->TestDataBase;

  $User = $db->User;

  $user = array( 'uid' => $uid, 'time' => time(), 'coord' => array("x"=>1,"y"=>2,"city"=>"Kiev"));
  
  $User->save($user); 


Задача состоит в выборке дочерних элементов.
На примере нужно получить название города пользователя с

PHP код:

$uid = 1; 


Самой простой реализацией будет выборка массива 'coord' с последующей выборкой значения 'city'. Но зачем выбирать весь массив если нам нужен всего-лишь 1 элемент.
Как добиться структуры хранения данных так, что бы можно было напрямую выбрать значение 'city' из массива 'coord'.

Размышление:
Предположительно думаю создавать не вложенные коллекции. То-есть имеется коллекция 'User' и 'coord'.
Тогда запись будет происходить так

PHP код:

$user = array( 'uid' => $uid, 'time' => time(), 'coord' => $MongoID; 


где

PHP код:

$MongoID 


индекс коллекции 'coord' с нашими данными, но отсюда напрашивается вопрос: на сколько это эффективно? Как быть с больший объемом данных (множество записей 'coord').

Буду признателен в оказанной помощи в любой доступной форме, ссылки, мысли, готовые решения.

[alexcon314]

Не очень понятно, почему вы храните в юзерской коллекции и координаты и город. т.е. все в одной коллекции. Зачем?
Напрашивается разделить:
Коллекция Users - объекты с полями id, city_id и тд.
Коллекция City- объекты с полями id, name, coord и тд., где coord - тоже объект вида {x,y}.
зная id юзера, узнаем id его города, легко находим нужный город в соответствующей коллекции.
Обычная реляционная модель, как бы. Коллекции в монго - аналог таблиц реляционных ДБ, "под-таблицу", т.е. подколлекцию создавать нельзя.

[AlexCooper]

Этот код я использовал для наглядности примера, на самом деле у нас есть пользователь, у которого есть н-блоков (объектов), у каждого объекта может быть н-объектов и так еще раз. Хотелось уйти от модели создания коллекции "Блоки" где хранить все блоки трех уровней так как их количество растет в геометрической прогрессии. При использовании запрашиваемой схемы выборка происходила б в разы быстрее, так как сортировка/выборка массивов происходила на уровне коллекции конкретного пользователя. Вместо того что бы производить поиск среди всех имеющихся блоков. Грубо говоря, если пользователь имеет шесть объектов, внутри которые содержат еще шесть объектов, которые в свою очередь имеют еще шесть объектов, то выборка перебором происходила по ключу родителя объекта, то-есть к примеру, Объект2->Объект1->перебрать все объекты. Но на сколько я понял это не возможно и выборка будет происходить по схеме Объекты->перебрать все объекты с ключами Объект2->Объект1

[kackbip]

Еще можно использовать нормальную БД Проиндексированную

[AlexCooper]

Было использовано MySQL но при 600 одновременных посетителях MySQL перегружался, потому решили перейти на более оптимальную базу данных, на сколько я знаю mongoDB индексированная база?? Покрайней мере индексы создать там можно + есть такая штука как шардинг которая позволяет группировать данные по шардам. Вопрос конечно еще до конца не изучен но на сколько мне известно mongoDB одна из лучших объектно-ориентированная база данных на сегодняшнее время. Больше всего нравиться поддержка BSON что позволяет соединять flash->amfphp->mongoDB без каких либо конвертаций, то-есть передавать целые объекты из flash прямо в mongoDB.

[Krusty]

Сообщение от AlexCooper

Было использовано MySQL но при 600 одновременных посетителях MySQL перегружался, потому решили перейти на более оптимальную базу данных, на сколько я знаю mongoDB индексированная база?? Покрайней мере индексы создать там можно + есть такая штука как шардинг которая позволяет группировать данные по шардам. Вопрос конечно еще до конца не изучен но на сколько мне известно mongoDB одна из лучших объектно-ориентированная база данных на сегодняшнее время. Больше всего нравиться поддержка JSON что позволяет соединять flash->amfphp->mongoDB без каких либо конвертаций, то-есть передавать целые объекты из flash прямо в mongoDB.

Странное поведение. Оптимизацию вы проводили?
шардинг есть и в mysql, начиная с 5.1, только называется не так
Но если вам важна именно заточенность mongoDB, и она подходит под вашу специфику, то она лучше в этом отношении mysql-я.
Хотя да и сравнивать их не стоит, разные все же БД. Индексы там есть, нету других вещей.

[AlexCooper]

Сообщение от Krusty

Странное поведение. Оптимизацию вы проводили?

Оптимизацию как раз и проводим. По совету некоторых специалистов пришли к mongoDB, нравиться то что нет шаблона для структуры данных. Из минусов конечно выборка очень страдает, нет всех этих %LIKE% и всего остального. Потому сейчас хочу изучить вопрос достаточно широко и определить курс по дальшей разработки.

Сообщение от Krusty

шардинг есть и в mysql, начиная с 5.1, только называется не так

можно поподробней

[terbooter]

%LIKE%

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

[Krusty]

Сообщение от AlexCooper

Оптимизацию как раз и проводим. По совету некоторых специалистов пришли к mongoDB, нравиться то что нет шаблона для структуры данных. Из минусов конечно выборка очень страдает, нет всех этих %LIKE% и всего остального. Потому сейчас хочу изучить вопрос достаточно широко и определить курс по дальшей разработки.


можно поподробней

партицирование это называется.
Вы не туда пошли. Если у вас поиск - %LIKE%, если что, индексы не может использовать просто по определению. Это просто из строения индекса следует. Вам обязательно нужно смотреть на Sphinx для текста, и смотреть, какие у вас запросы и задачи.
А percona тут вообще никаким боком не нужна, это только для транзакционных схем работы имеет смысл переходить, это не тот случай явно.

[AlexCooper]

Сообщение от Krusty

партицирование это называется.

Прокомментируйте пожалуйста это
Sphinx это следующий этап оптимизации, плюс я думаю будет реализована еще связка Node.js с long-poll, memcache и железом SSD-диски которые помогут дышать серверу но начало идет от архитектуры и самой БД.