Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Руки чешутся попробовать, MongoDB с каждым обзором всё привлекательнее кажется.
Раз пошла такая пьянка, писать посты про объектные базы, то я скоро напишу про db4o. Уверен она тоже Вам понравится.
Идеология совершенно другая, db4o ведь встраиваемая, как например BDB. Так что целевые аудитории этих продуктов сильно разнятся.
Каковы минусы вешать индексы на все подряд? Насколько это замедлит процесс вставки?
Какова производительность операции group?
Какова производительность операции group?
Не сильно замедляет, но не измерял. Производительность довольно высокая, хотя злоупотреблять конечно не стоит, надо эту операцию над куском лога делать один раз и запоминать готовые данные, но я ради простоты примера не стал этого делать, иначе бы сложно было для понимания. Производительность зависит от всего — от reduce-функции, от индексов, от железа… посмотрите сами на своем железе и задаче.
img src root.loopback.su/habralogger/ в шапке
ждите нового графика…
ждите нового графика…
Насколько быстро бд работает по сравнению с другими?
Впечатляет, кстати, Ваш труд.
Впечатляет, кстати, Ваш труд.
Затормозить или разогнать можно что угодно, вопрос лишь в приспособленности архитектуры к шардингу и работе без затыков. На мой взгляд, у MongoDB хорошая гибкая архитектура, которая в то же делает прозрачной работу с СУБД, и не позволяет программисту особо сильно накосячить. С другой стороны, в ней отсутствует транзакционная модель, даже не знаю хорошо это или плохо.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.
Конкретно узнать насколько можно лишь на реальном железе и реальных тестах, попробуйте если интересно, это вовсе несложно.
Спасибо, я рад.
Даёшь GridFS в след. статье :)
Намёк понял :-) Будет.
Что ещё? Достаточно ли сказано о масштабировании?
Что ещё? Достаточно ли сказано о масштабировании?
Статья немного плохо структурирована, что опасно для Веба. Про мастабирование лучше отдельную статью написать с How To и графиками :).
раскажите подробнее о репликациях и вообще подходе их к этому.
Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)
Также у 10gen есть еще пара проектов, например, свой сервер приложений (с которого компания и начинала пока не переключилась на базу)
про масштабирование сказано мало.
Нужен реальный пример и workaround'ы
Нужен реальный пример и workaround'ы
По поводу _id: как указано, его можно формировать самому. По полю _id индекс есть всегда. Если системное значение _id для вас некритично и есть потребность в индексе по какому-либо одному или нескольким полям (комбинация которых будет уникальна) — можете формировать id сами по нужным правилам. На этом можно сэкономить один индекс на отдельно взятом поле или группе полей, а также быстро адресоваться к конкретной записи по заранее известному значени.
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).
Например для получения объекта { _id: «1234_4456»; a: 1234; b: 4456 }, мы используем $collection->find( array( "_id" => «1234_4456» ) ), что, теоретически, должно быть быстрее, чем $collection->find( array( «a» => 1234, «b» => 4456 ) ).
Manual — на английском.
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?
Что имеется в виду под интеллектуальным поиском? Что такое сетевая БД?
А где-нибудь есть сравнение другими KV-хранилищами? Меня в частности интересуют Java-проекты Cassandra(Facebook) & Voldemort(LinkedIn), Hadoop(Apache).
Идея.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.
У меня давно есть идея распределенной отказоустойчивой платформу как у Google или круче, на которой и поисковик можно написать, и армию ботов поднять не проблема.
Скажите, была бы вам интересна статья об этом? HOWTO повторить Google, с некоторой долей теории, исследований и рассуждений.
Отлично пишите!
Многое есть в оф. документации.
НО ваш личный опыт работы с MONGO ниоткуда не почерпнешь!
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
Многое есть в оф. документации.
НО ваш личный опыт работы с MONGO ниоткуда не почерпнешь!
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
Спасибо.
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
С удовольствием напишу.
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
Вы видно перепутали сервер и шард. Если шард полностью упал, то данные уже не спасти (только если из резервных копий), если упал сервер в шарде (их рекомендуется 3 на шард), то всё работает как работало, как только добавляется новый сервер, он без проблем синхронизируется и вступает в бой с клиентами.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
С MySQL бывало и похуже, это нормально. Во-первых сервер не может просто так перезагрузиться — по крайней мере за год работы этого продакшена ни разу не было, во-вторых, два или три сервера уж точно одновременно не навернуться, но если это произошло — восстанавливать и вперед.
— С удовольствием бы прочитал про масштабируемость и отказоустойчивость в формате «как мы это поднимали у себя».
С удовольствием напишу.
— Интересно узнать про то, сталкивались ли вы с падением шарда, перераспределением данных между шардами (например решили убрать один шард и надо данные распределить по оставшимся), добавление нового шарда.
Вы видно перепутали сервер и шард. Если шард полностью упал, то данные уже не спасти (только если из резервных копий), если упал сервер в шарде (их рекомендуется 3 на шард), то всё работает как работало, как только добавляется новый сервер, он без проблем синхронизируется и вступает в бой с клиентами.
— Где-то прочитал, что при записи в Mongo комп перегрузился и база упала. На восстановление ушло 30 минут. Как от таких случаев вы защищаетесь на своем продакшене?
С MySQL бывало и похуже, это нормально. Во-первых сервер не может просто так перезагрузиться — по крайней мере за год работы этого продакшена ни разу не было, во-вторых, два или три сервера уж точно одновременно не навернуться, но если это произошло — восстанавливать и вперед.
Интересно.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5
то есть выводить 5 случайных документов, но вероятность показа будет больше у тех, у кого hosts больше.
А сортировку он поддерживает?
Возможно ли на нем сделать подобное:
ORDER BY RAND()*hosts DESC LIMIT 5
то есть выводить 5 случайных документов, но вероятность показа будет больше у тех, у кого hosts больше.
Сортировку поддерживает замечательно.
> ORDER BY RAND()*hosts DESC LIMIT 5
Нет. И это огромный плюс… MySQL любит делать фишки удобные для использования, но которые при этом кладут на производительность. Данная конструкция в MySQL вызовет фулскан всей таблицы и положит сервер на немаленькой табличке. Ведь чтобы отсортировать результат и взять сверху 5 элементов, необходимо каждый ряд в таблице проверить и положить в память результат, потом сделать сортировку пузырьком в памяти, а затем уже отпилить маленький кусочек и послать ответ клиенту.
Но есть и правильные пути. Например, задайте индекс по свойству hosts и делайте запросы hosts > min && hosts < max. Где min и max там ограничители выбираемой группы, которые задаются псевдослучайно с задаваемой вероятностью. Еще можно задать какое-то числовое свойство группы (в ней скажем 20 объектов), и выбирать запросом (k IN list) 5 таких групп, а затем выбирать для каждой группы случайный элемент (уже на клиенте). Согласен, может быть не очень красиво, за то это будет хорошо работать и на миллиарде рядов, а вот RAND() загнется куда раньше.
Да, придётся думать, но без этого никуда.
> ORDER BY RAND()*hosts DESC LIMIT 5
Нет. И это огромный плюс… MySQL любит делать фишки удобные для использования, но которые при этом кладут на производительность. Данная конструкция в MySQL вызовет фулскан всей таблицы и положит сервер на немаленькой табличке. Ведь чтобы отсортировать результат и взять сверху 5 элементов, необходимо каждый ряд в таблице проверить и положить в память результат, потом сделать сортировку пузырьком в памяти, а затем уже отпилить маленький кусочек и послать ответ клиенту.
Но есть и правильные пути. Например, задайте индекс по свойству hosts и делайте запросы hosts > min && hosts < max. Где min и max там ограничители выбираемой группы, которые задаются псевдослучайно с задаваемой вероятностью. Еще можно задать какое-то числовое свойство группы (в ней скажем 20 объектов), и выбирать запросом (k IN list) 5 таких групп, а затем выбирать для каждой группы случайный элемент (уже на клиенте). Согласен, может быть не очень красиво, за то это будет хорошо работать и на миллиарде рядов, а вот RAND() загнется куда раньше.
Да, придётся думать, но без этого никуда.
>А сортировку он поддерживает? Возможно ли на нем сделать подобное: ORDER BY RAND()*hosts DESC LIMIT 5
А этот пистолет стреляет? А ногу у меня получится себе отстрелить?
А этот пистолет стреляет? А ногу у меня получится себе отстрелить?
Не стоит так все воспринимать.
Представьте, например, баннерную систему.
Миллионы запросов в сутки к скрипту, который отдает баннеры сайтам-партнерам.
Перед выдачей баннера, скрипт должен выбрать баннер из всех. Учесть кол-во кликов которые нужно отдать и т.д. и взависимости от этого вывести баннер.
Для таких задач что нужно использовать?
Поэтому я и поинтересовался насчет Mongo, вдруг она подойдет.
Представьте, например, баннерную систему.
Миллионы запросов в сутки к скрипту, который отдает баннеры сайтам-партнерам.
Перед выдачей баннера, скрипт должен выбрать баннер из всех. Учесть кол-во кликов которые нужно отдать и т.д. и взависимости от этого вывести баннер.
Для таких задач что нужно использовать?
Поэтому я и поинтересовался насчет Mongo, вдруг она подойдет.
Думаю, для таких как и для любых других нужно использовать в первую очередь разум, Mongo конечно подойдет.
Кстати, в первой задаче (про функцию RAND): индекс на hosts, и find().sort(«hosts»:1).limit(rnd(),1) нужное количество раз. rnd() — Ваша хитрая схема с вероятностями.
Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.
Кстати, в первой задаче (про функцию RAND): индекс на hosts, и find().sort(«hosts»:1).limit(rnd(),1) нужное количество раз. rnd() — Ваша хитрая схема с вероятностями.
Вторая задача (про баннерную систему): думаю я бы инкрементил клики в Memcached, и скидывал бы изменения в MongoDB раз в минуту, например. А выборку баннера сделал бы по индексу само собой.
А с Cassandra Вы не сравнивали?
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)
Тема очень интересная, особенно практические комментарии и примеры.
Буду рад видеть продолжение :-)
А почему не CouchDB? Скорость?
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Мне кажется с каучуком по-удобнее — готовый rest-сервис и прозрачность работы из JS кода с клиента… Плюс есть подозрение что при больших базах каучук будет много надежнее.
Не подскажете по вопросу ссылок:
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).
Спасибо!
Как я понял, ссылок на объекты в MongoDB нет. Как нам поступать на примере тех же комментариев, когда надо вытащить логин каждого автора коммента (разумеется, логин может изменяться, а привязка идет по id).
Спасибо!
расскажите про файловую систему на монго
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB — варим хороший кофе