Релиз MongoDB 2.2.0

The Third Manifesto

А он разве где-то реализован?

Мне понравилось как разработчики Postgres сказали про NoSQL: если использовать postgres как используют NoSQL то он будет выдавать ту же скорость. Удобство? В Postgres есть массивы данных и прочее.

Потом из-за отсутсвия подержания целостности и всякого рода связей по сути мы упрощаем чтение но усложняем запись (после записи надо подержать целостность). А тупо одна большая таблица она и в обычных СУБД быстро считается, только вот где это нужно?

mmap всех бесит в тот момент, когда монге надо сброситься на накопитель

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

отношение производительности и потребления намного хуже, чем у ARM

Ничего подобного. Если про ультранизкое потребление - посмотрите на атомы, которые на равне с АРМами с недавних пор. А с десктопами мерять бессмысленно - армам тут как до луны.

потребления намного хуже, чем у ARM.

Кстати, PowerPC войну производительность/потребеление intel-у проиграл.

А зачем ты тогда оставил ссылку на чувака который порет чушь?

Чтоб ты прочитал, например. Ты зачем читать не стал?

И, если ты что-то не понял из сказанного, это не значит что сказанное — чушь.

Кстати, про конструктивность там вполне доходчиво написано, даже тупой анонимус понял, о чем речь, странно, что до тебя не дошло.

Особенно это странно в свете твоего же:

А SQL просто многого из реляционной модели не поддерживает

Сравни это с цитатой по ссылке:

Дейт лишь раскрыл в своих манифестах ту проблему, что большинство реальных СУБД (заявленных как реляционные) не соотвествуют самой реляционной теории.

Кстати, про конструктивность там вполне доходчиво написано

Да я ее в университетах проходил, мне википедия для этого не нужна.

И, если ты что-то не понял из сказанного, это не значит что сказанное — чушь.

А я не писал что я чего-то не понял. Я написал, что реляционная алгебра конструктивна.

Мне понравилось как разработчики Postgres сказали про NoSQL: если использовать postgres как используют NoSQL то он будет выдавать ту же скорость.

Отлично, теперь ты можешь дрочить на эту фразу в любое время.

Только вот «разработчики Postgres» забыли упомянуть, что «использовать postgres как используют NoSQL» — не получится.

А я не писал что я чего-то не понял

Разумеется. Ты даже не заметил, что чего-то не понял.

Да я ее в университетах проходил, мне википедия для этого не нужна.

Очевидно, мимо проходил. Иначе ты признал бы, что хреново прочитал, после такого-то:

ты что такое конструктивизм то знаешь?

и да, я знаю, что такое конструктивизм.

Я написал, что реляционная алгебра конструктивна.

Что-то даже википедия с тобой не согласна:

В теории множеств факт постоянного рождения и исчезновения конструктивных объектов не находит никакого выражения: с её точки зрения, подвижные реальные объекты являются лишь «тенями» вечно существующих в некотором фантастическом мире статичных «идеальных объектов»

//inb4 3654f03011f55e7279b0940ee333c026 -

В теории множеств факт постоянного рождения и исчезновения конструктивных объектов не находит никакого выражения: с её точки зрения, подвижные реальные объекты являются лишь «тенями» вечно существующих в некотором фантастическом мире статичных «идеальных объектов»

Внезапно, это соврешенно не противоречит конструктивности реляционной алгебры.

Смотрел. Вот прям запустил пузомерку на своем мобильнике, которую запускали на «пиридавом тилифоне с атамом». Атом слил в полтора раза, имея в полтора раза больше тактовую. Бида-пичаль. И умными заявлениями про поверписи этот факт не отменить.

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

The MongoDB server ( mongod ) must run on a little-endian CPU

Вот-вот. Только EL. До сих пор. я им писал где-то года два назад, ничего кроме «patches are welcome» не услышал. Да и особо не нужно.

BerkleyDB перешла к Oracle в 2006-ом году.

Внезапно, это соврешенно не противоречит конструктивности реляционной алгебры.

Ладно. И как же сконструировать множество?

SQL уже был тогда когда Oracle был только в проекте, а а основным генератором новых технологий был IBM

Согласен.

А можно озвучить список таких учебников?

Ладно. И как же сконструировать множество?

У тебя похоже проблемы с понимаем конструктивности. Если бы конструктивизм не позволял описывать даже такие примитивные понятия как множество, он был бы нахрен не нужен. Просто в конструктивизме мы должны задать способ построения )(например перечислить элементы), а не описанием свойств объектов, которые в него входят. Так вот, реляционная алгебра строит множества при помощи а) перечисления элементов (конструктивно) б) при помощи небольшого набора операторов (опятьже, конструктивно). Вот в реляционном _исчислении_ мы задаем множество некоторым свойством объектов и это уже не конструктивно.

Вот прям запустил пузомерку на своем мобильнике

А я видел обратные факты. Это слишком сильно зависит от той самой «пузомерки», которая внезапно, писалась под армы, а не х86 (возможно).

Кстати, интел тоже выпускал RISC и для мобильных - XScale был очень хорошо в свое время.

Меткое замечание. Пузомерка на жабе писалась под армы. Я разоблачен и опять слил. А если копнуть глубже, то я еще кипятил свой телефон в кастрюльке и мазал гуталином, чтобы накрутить результат.

Ничего подобного. Если про ультранизкое потребление - посмотрите на атомы, которые на равне с АРМами с недавних пор.

в чем наравне?

Если бы конструктивизм не позволял описывать даже такие примитивные понятия как множество, он был бы нахрен не нужен.

Если б у бабки... Видимо, в КМ нахрен не нужно понятие множества, как оно есть в ТМ.

Так вот, реляционная алгебра строит множества при помощи а) перечисления элементов (конструктивно) б) при помощи небольшого набора операторов (опятьже, конструктивно)

OMG, овсянка, сэр! Я даже к «перечислению» докапываться не стану, просто скажи, ты правда понимаешь разницу между а) и б)?

не нужно понятие множества, как оно есть в ТМ.

_как в ТМ_ не нужно, а _запрещено_. Но в конструктивной теории прекрасно работает чуть другое определение множества. Вот, читай:

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

http://djvu-student.narod.ru/02-matematicheskaya-logika/metodichka/metoda_mat...

Меткое замечание. Пузомерка на жабе писалась под армы.

Какой Atom ты сравнивал с каким армом?

Вопрос не по теме, но какое значение имеет слово «внезапно» в ваших комментариях? Очень часто используете там, где трудно предположить внезапность.

Интеловский телефон только один, какой там конкретно атом - не помню уже. У себя пускал antutu на Galaxy Nexus, в нем A9 двухядерный (не уверен, что попугаи учитывают оба, но я глубоко не копал).

С девбордами - я в курсе, если под армы собрать код под 6 ядро или с софтовой плавучкой, то все будет тупить. Поэтому в заявлениях, как сильно тормозит арм, предлагагаю ссылаться на конкретные результаты.

А если хочется «честного» сравнения технологий - предлагаю ориентироваться на бенчмарки Exinos4 с любым атомом на той же частоте или с тем же потреблением.

на той же частоте

Ну это то, учитывая разную архетектуру достаточно глупо.

с тем же потреблением.

Тут можно, я видел «интеловские» тесты, и они были вполне наравне, хотя конечно, возможно они не объективны. Но мне именно этот класс атомов не пощупать. да и в любом случае - интел вышла этот рынок с атомами совсем недавно, ей нужно время.

Основы основ:

«MySQL - Руководство по изучению языка», Ларри Ульман, 2004.

«SQL-запросы для простых смертных», Майкл Дж. Хернандес, Джон Л. Вьескас

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

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

GreedFS это обвеска над самой базой - протокол записи данных, нежели сторонний код самой бд. Работать будет все также как и с обычными коллекциями.

1. Он не управляем.

http://www.briancarpio.com/2012/05/03/mongodb-memory-management/

http://www.tldp.org/LDP/tlk/mm/memory.html

Итого: проблема только в том, что можно уйти в swap и не выйти от туда никогда.

http://www.briancarpio.com/2012/05/03/mongodb-memory-management/

И? где описывается возможность влиять на выделение памяти?

Нет, зато написано, что достаточно выделить 96гб и если и столько не хватит - перейти на шардинг.

Нет, зато написано, что достаточно выделить 96гб

Я даже не знаю, что тут сказать.

Я даже не знаю, что тут сказать.

Заливаете данные, смотрите сколько файлов насоздавала монго. Прикидывайте сколько из этих данных уйдут под чтение, если не все 100%, то можете не парится, если 100% и объем выше чем ОЗУ - добавляете ОЗУ, либо шардинг.

Я даже не знаю, что тут сказать.

По личному опыту mmap самое то, когда нужно быстро заливать данные и быстро читать. Был опыт заливки нескольких миллионов записей в ldap-bdb и таких же данных в mongo. bdb даже затюненгованный на использование нескольких гигов озу уходит в io wait по достижение mem-лимита - нужно постоянно синкать данные. Монго же, засчет скидывания данных раз в минуту или по требованию, скидывает те же данные влет без всяких wa. По времени: 10 минут у монго, 1.5-2 часа на ldap-bdb. Данные одни и теже, алгоритм тот же. Это все к тому, что если у вас архитектура имеет ограниченный набор данных - можете использовать bdb, oracle и т.п., где можно лимитировать максимальный объем. Если неизвестно сколько будет пухнуть бд, то mmap выигрывает хотя бы потому, что:

а) вместо изменения и расширения файлов (что в оракле допустим сложнее сделать, в bdb нужно добавлять новые файлы) что иногда сложнее, чем накинуть озу и сделать рестарт mongod или налету включить шардинг.

б) нет особой надобности вообще за этим процессом следить. Один раз закупился планками на 48гб и работаешь дальше.

Вобщем я за толстые сервера и против io wait. Т.к. последние губят систему даже хуже чем уход в свопинг. Свопинг лечится - io wait нет (ssd это круто, но так часто менять их я не готов).

Если сравнивать архитектуры, то именно на одинаковых частотах. И желательно одинаковых техпроцессах (хотя интел при более мелком сливает :) ).

В общем, у меня есть предложение, при последующих сравнениях использовать хоть какие-то ссылки на тесты, где описано как позорно ARM слил все что можно :)

А насчет того, как атом все наверстает - интел уже много лет нас телефоном пугает. Поэтому недавний релиз ничего кроме хихиканья уже не вызывает. Гора пукнула мышкой, ага.

Я прекрасно понимаю, что это обвязка. Но плохо понимаю, как поведет себя mmap в следующей ситуации:

- в грид кидается пара терабайт мелкий файлов (картинок), которые постоянно читают.
- в другие коллекции кидается база «форума», несколько гигабайт, точно влезет в память.

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

Я точно знаю, что по отдельности это работает (есть живые инсталляции, говорил с автором). Но не знаю, будет ли работать вместе. И более того, видел не подтвержденные высказывания, что вместе работает плохо.

Был бы признателен за реальный опыт в подобном вопросе.

итого: разработчики монги честно признались, что если данные никак не влазят в память - юзайте более подходящие для этого инструменты. они это говорили не раз и не два, а тупые хомячки все еще пытаются ее юзать как персистентное хранилище вместо обычной СУБД.

не нужно, а _запрещено_

не нужно придираться к слову «не нужно».

//А сегодня ты лучше соображаешь. Вечером откаменчу.

какое значение имеет слово «внезапно» в ваших комментариях?

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

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

но поскольку это mmap, то в этот момент монга лочится на запись

А какова цель ваших комментариев вообще? Распространить какое-то знание? Переубедить конкретного человека? Унизить собеседника на основе отсутствия у него каких-то знаний или определённого типа поведения? И как вы контролируете, достигли вы поставленной цели или нет?

1. Он не управляем.

http://www.briancarpio.com/2012/05/03/mongodb-memory-management/

«mongodb leaves memory management up to the operating system».

http://www.tldp.org/LDP/tlk/mm/memory.html

Средства управления здесь в лучшем случае скромные (если не сказать «рудиментарные») -

А какова цель ваших комментариев вообще?

Весело провести время.

по достижение mem-лимита - нужно постоянно синкать данные.

Ну так выставили бы в качестве объема памяти всю оперативку. Тогда бы было справедливое сравнение с монгой.

вместо изменения и расширения файлов

Не понял, в чем проблема. Тот-же MySQL умеет хранить файл-на-таблицу.

нет особой надобности вообще за этим процессом следить.

А почему в БД без mmap, где я могу ограничить использование памяти размером физической памяти с этим сложнее?

Вобщем я за толстые сервера и против io wait.

Так ктобы спорил. При чем тут только NoSQL?

Ну так выставили бы в качестве объема памяти всю оперативку. Тогда бы было справедливое сравнение с монгой.

Даже если и так, в случае когда объем данных на вставку превысит ОЗУ я получу всеравно io wait. Тут проблема в том, _когда_ делать синхронизацию с диском. Любаябаза ждет команды commit. В одну транзакцию можно записать далеко не гигабайты данных. Поэтому монго и берет на себя управление когда делать commit, забыл сказать, что монго коммитит через каждые 100 документов или 1 минуту.

Не понял, в чем проблема. Тот-же MySQL умеет хранить файл-на-таблицу.

В Oracle, например, задается размер tablespace при создании. После надо уже извращатся, когда данные не станут влезать в этот файл.

http://docs.oracle.com/cd/B19306_01/server.102/b14220/physical.htm

А почему в БД без mmap, где я могу ограничить использование памяти размером физической памяти с этим сложнее?

Потому что ограничение по памяти выливается в тормоза. Поэтому монго и жрет память так как считает нужным: основная цель это не допустить тормозов по записи и чтению почти любой ценной и при этом дав возможность работать другому ПО на той же машине.

http://docs.mongodb.org/manual/faq/fundamentals/#does-mongodb-require-a-lot-o...

Так ктобы спорил. При чем тут только NoSQL?

Потому что монго использует файлы для хранения данных, в отлие от RAM-based NoSQL, таких как Redis.

Но чаще вы нервничаете, а не веселитесь.

Даже если и так, в случае когда объем данных на вставку превысит ОЗУ я получу всеравно io wait.

А почему с монгой не получите? Память то кончилась?

что монго коммитит через каждые 100 документов или 1 минуту.

Тот же MySQL так тоже умеет. На счет оракла, правда, не знаю.

В Oracle, например, задается размер tablespace при создании.

Ясно, не занал.

Потому что ограничение по памяти выливается в тормоза

Не понимаю. Если дать базе с ограничением по памяти ограничение совпадающее с размером физической памяти, то почему это получается медленнее чем с mmap? Особенно учитывая что механизм вытеснения страниц в случае БД может быть значительно более интеллектуальный чем у ОС?