LINUX.ORG.RU

Зачем нужна Монга?

 , , ,


0

4

Есть ли вообще смысл её использовать? Многократно хранит ключи с данными (с 2010 года их просят это пофиксить), увеличивая обьём данных в 2-20 раз (в зависимости от данных), атомарность только на уровне одного документа. TokuMX, который форк (?) Монги и решает вышеобозначенные проблемы, выглядит сомнительно.

Из плюcов: деплоймент нехитрый, лёгкий старт разработки, масштабируемость.

Отбросим «для каждой задачи инструмент... бла-бла-бла». Что сейчас модно, молодёжно?

Ну у нее сильный профит - шардинг по серверам из коробки. Работает «само». Многие к этой магии относятся с осторожностью и недоверием.

Kesha_Molchanov
()

Зачем нужна Манга?

так правильнее :)

YLoS ★★★
()

Зачем нужна Монга?

Чтобы не трахаццо с этими вашими формами нормальности и нелогичными не похожими на таблицы таблицами.

serst
()

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

umren ★★★★★
()

я смысла не вижу.

ковыряю OrientDB

bismi
()

Как там, кстати, китайская Hypertable поживает, которая Байдой финансируется?

anonymous
()
Ответ на: комментарий от serst

Чтобы не трахаццо с этими вашими формами нормальности

Так уж и трахаться. С вики: «принципы нормализации — это формализованный здравый смысл». В точку прямо.

В монге же приходится выбирать: либо атомарные операции, либо нормализованный вид.

anonymous
()

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

А вообще монга - УГ с точки зрения реализация. Репликация там прикручена кое-как, кеширование там уровня ОС. Есть аналоги, которые пытаются это пофиксить - rethinkdb, arangodb, но они пока поделки.

dizza ★★★★★
()

Что сейчас модно, молодёжно?

Монга.
А вот правильно сейчас, и всегда, «для каждой задачи инструмент... бла-бла-бла» (:

На сколько я понимаю mongodb очень удобна пока справляется с твоими задачами, но если она перестаёт с ними справляться то сделать с ней что-то (подтюнить что-бы справлялась) довольно трудно.
А ещё слышал такую умную мысль: монга опасна, так-как внушает пользователю уверенность в том что не нужно разбираться в базах данных.

MrClon ★★★★★
()
Ответ на: комментарий от kolyakolyanikolay

Думаю пока сырая, но это просто мнение, на практике я ее не пробовал.

dizza ★★★★★
()

Монга 1) Самая простая БД, проще реляционок 2) Автошардинг 3) MapReduce/AF 4) Consistent

А теперь поищем базу с такими же показателями.

Riak - key-value

Cassandra - нельзя заставить быть консистентной (они лгут что можно с помощью R+W>=N+1)

CouchDB - вундервафля с адовой моделью данных

RDMBS - автошардинг в жопе

HBase - геморов много с деплойментом

vertexua ★★★★★
()
Ответ на: комментарий от dizza

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

vertexua ★★★★★
()
Ответ на: комментарий от dizza

кеширование там уровня ОС

Есть еще вариант: TokuMX
Там прикольная идея с Fractal tree

nerdogeek
()
Ответ на: комментарий от vertexua

Cassandra - нельзя заставить быть консистентной

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

зато Кассандра никогда не ляжет от типичной нагрузки и доса

HBase

вооот скаааажии.. Зачем они на любое слово делают (с)(тм)(r)? Захдишь на сайт Хадупа, а там «технологиями» вся глагне занята, и перед каждой (с)(тм)(r). И чем дальше - тем больше. Там даже методы и то бывают (с)(тм)(r)!

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Да не такаю уж и волшебная эта кассандра. Как-то у нас ее тестили на предмет быстрой записи. 5к инсертов она выдержала, но нужно было 20к. Не подошла. Еще я ходил как-то на собеседование в одноклассники, мне рассказывали, что там кассандру юзают, но пришлось сильно патчить, так как оригинальная не супер-быстрая, так среднячок.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Интересно было бы послушать реальную историю использования кассандры в качестве щита от ddos'а, хранением в ней картинок (меньше 64 мегабайтов). Но, наверное, это потребует что-то там менять в кишках самостоятельно :(

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Поверь, большие блобы туда пихать - совсем не айс. man sstables + log structured merge tree. Оно будет работать очень грустно

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Да я готов пользоваться ей в 90% сценариев всякой вебни. Но почему бы не дать людям заплатить небольшую цену в latency чтобы дать возможность работать с 10% сценариев на той же базе, ведь данные на column-family отлично ложатся.

Они уже сделали lightweight transactions на основе Paxos алгоритма, так вот почему бы не обьяснить по-человечески большими буквами приводит ли это к роллбекам при failed writes. Если да, то дело в шляпе - она может быть консистентна при R+W>=N+1. Если нет, то эти транзакции уж очень lightweight :)

Ну аргументы к HBase у тебя надуманые, ведь реально ее ругают за минимум 5 узлов в любом нормальном деплойменте и некую нериалтаймовость.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

а я HBase дальше чем на хэлловорлдах не пользовался :3 Как раз из-за того, что от их ынтерпрайзности лютый баттхерт. Был один нормальный жирный диплоймент, в котором «руками не трогать» и всё

и некую нериалтаймовость.

как ты красиво сказал слово «тормоза»

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается. Для говносайтиков конечно прийдется подымать жирный продакшн, но зачем HBase для говносайтиков

тормоза

Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет

Собственно когда бенчмаркали последний раз, то Riak и MySQL Cluster быстро копытца откинули. Только HBase и Cassandra линейно масштабировались. Не помню что там с лейтенси, собственно за что некоторые ругают HBase, но общий throughput был на высоте и не оставал от кассандры

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 4)
Ответ на: комментарий от vertexua

А что можете сказать о Tarantool? Костя Осипов на Highload++ очень доходчиво рассказывал про NoSQL.

undertaker ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.