|
|
|||||
MongoDB
Здравствуйте форумчане.
Обращаюсь к тем кто уже работал с данной базой данных. Интересует вопрос на который я не смог найти ответа прогуглив интернет. Можно ли создавать коллекции внутри коллекций? Востребованная структура данных:
На примере нужно получить название города пользователя с Самой простой реализацией будет выборка массива 'coord' с последующей выборкой значения 'city'. Но зачем выбирать весь массив если нам нужен всего-лишь 1 элемент. Как добиться структуры хранения данных так, что бы можно было напрямую выбрать значение 'city' из массива 'coord'. Размышление: Предположительно думаю создавать не вложенные коллекции. То-есть имеется коллекция 'User' и 'coord'. Тогда запись будет происходить так где индекс коллекции 'coord' с нашими данными, но отсюда напрашивается вопрос: на сколько это эффективно? Как быть с больший объемом данных (множество записей 'coord'). Буду признателен в оказанной помощи в любой доступной форме, ссылки, мысли, готовые решения.
__________________
return this... |
|
|||||
listener
|
Не очень понятно, почему вы храните в юзерской коллекции и координаты и город. т.е. все в одной коллекции. Зачем?
Напрашивается разделить: Коллекция Users - объекты с полями id, city_id и тд. Коллекция City- объекты с полями id, name, coord и тд., где coord - тоже объект вида {x,y}. зная id юзера, узнаем id его города, легко находим нужный город в соответствующей коллекции. Обычная реляционная модель, как бы. Коллекции в монго - аналог таблиц реляционных ДБ, "под-таблицу", т.е. подколлекцию создавать нельзя. |
|
|||||
Этот код я использовал для наглядности примера, на самом деле у нас есть пользователь, у которого есть н-блоков (объектов), у каждого объекта может быть н-объектов и так еще раз. Хотелось уйти от модели создания коллекции "Блоки" где хранить все блоки трех уровней так как их количество растет в геометрической прогрессии. При использовании запрашиваемой схемы выборка происходила б в разы быстрее, так как сортировка/выборка массивов происходила на уровне коллекции конкретного пользователя. Вместо того что бы производить поиск среди всех имеющихся блоков. Грубо говоря, если пользователь имеет шесть объектов, внутри которые содержат еще шесть объектов, которые в свою очередь имеют еще шесть объектов, то выборка перебором происходила по ключу родителя объекта, то-есть к примеру, Объект2->Объект1->перебрать все объекты. Но на сколько я понял это не возможно и выборка будет происходить по схеме Объекты->перебрать все объекты с ключами Объект2->Объект1
__________________
return this... |
|
|||||
Еще можно использовать нормальную БД Проиндексированную
|
|
|||||
Было использовано MySQL но при 600 одновременных посетителях MySQL перегружался, потому решили перейти на более оптимальную базу данных, на сколько я знаю mongoDB индексированная база?? Покрайней мере индексы создать там можно + есть такая штука как шардинг которая позволяет группировать данные по шардам. Вопрос конечно еще до конца не изучен но на сколько мне известно mongoDB одна из лучших объектно-ориентированная база данных на сегодняшнее время. Больше всего нравиться поддержка BSON что позволяет соединять flash->amfphp->mongoDB без каких либо конвертаций, то-есть передавать целые объекты из flash прямо в mongoDB.
__________________
return this... Последний раз редактировалось AlexCooper; 02.11.2012 в 19:24. |
|
|||||
Регистрация: Jul 2007
Сообщений: 393
|
Цитата:
шардинг есть и в mysql, начиная с 5.1, только называется не так Но если вам важна именно заточенность mongoDB, и она подходит под вашу специфику, то она лучше в этом отношении mysql-я. Хотя да и сравнивать их не стоит, разные все же БД. Индексы там есть, нету других вещей. |
|
|||||
Оптимизацию как раз и проводим. По совету некоторых специалистов пришли к mongoDB, нравиться то что нет шаблона для структуры данных. Из минусов конечно выборка очень страдает, нет всех этих %LIKE% и всего остального. Потому сейчас хочу изучить вопрос достаточно широко и определить курс по дальшей разработки.
можно поподробней
__________________
return this... |
|
|||||
Цитата:
Не мудрено что у вас мускул закряхтел Три раза пытался перейти на монго, и снова возвращался на мускул. Посмотрите в сторону percona-server - это модифицированный мускул. Возможно, оптимизировать мускул будет проще, чем перейти на новую технологию.
__________________
Сам себе репортер |
|
|||||
Регистрация: Jul 2007
Сообщений: 393
|
Цитата:
Вы не туда пошли. Если у вас поиск - %LIKE%, если что, индексы не может использовать просто по определению. Это просто из строения индекса следует. Вам обязательно нужно смотреть на Sphinx для текста, и смотреть, какие у вас запросы и задачи. А percona тут вообще никаким боком не нужна, это только для транзакционных схем работы имеет смысл переходить, это не тот случай явно. |
|
|||||
Прокомментируйте пожалуйста это
Sphinx это следующий этап оптимизации, плюс я думаю будет реализована еще связка Node.js с long-poll, memcache и железом SSD-диски которые помогут дышать серверу но начало идет от архитектуры и самой БД.
__________________
return this... Последний раз редактировалось AlexCooper; 02.11.2012 в 19:37. |
Часовой пояс GMT +4, время: 10:34. |
|
« Предыдущая тема | Следующая тема » |
|
|