Представлен (http://blog.mongodb.org/post/134796516338/announcing-mongodb...) стабильный выпуск высокопроизводительной и высокомасштабируемой документо-ориентированной СУБД MongoDB 3.2, которая занимает нишу между быстрыми и масштабируемыми системами, оперирующими данными в формате ключ/значение, и реляционными СУБД, функциональными и удобными в формировании запросов. Код MongoDB написан на языке C++ и распространяется в рамках лицензии AGPLv3. Сборки MongoDB 3.2.0 сформированы (https://www.mongodb.org/downloads) для Linux, Solaris, Windows и OS X.
MongoDB поддерживает хранение документов в JSON-подобном формате, имеет достаточно гибкий язык для формирования запросов, может создавать индексы для различных хранимых атрибутов, эффективно обеспечивает хранение больших бинарных объектов, поддерживает журналирование операций по изменению и добавлению данных в БД, может работать в соответствии с парадигмой Map/Reduce, поддерживает репликацию и построение отказоустойчивых конфигураций.В MongoDB имеются встроенные средства по обеспечению шардинга (распределение набора данных по серверам на основе определенного ключа), комбинируя который репликацией данных можно построить горизонтально масштабируемый кластер хранения, в котором отсутствует единая точка отказа (сбой любого узла не сказывается на работе БД), поддерживается автоматическое восстановление после сбоя и перенос нагрузки с вышедшего из строя узла. Расширение кластера или преобразование одного сервера в кластер производится без остановки работы БД простым добавлением новых машин.
Особенности (http://docs.mongodb.org/manual/release-notes/3.2/) нового выпуска (https://www.mongodb.com/mongodb-3.2):
- Средства проверки корректности структуры и содержимого документов, реализованные через привязку к документам специального валидатора, определяющего правила для проверки типов, полей и значений;
- Новый движок хранения с шифрованием данных (только для MongoDB Enterprise);
- Новый движок хранения для систем реального времени, размещающий все данные в оперативной памяти;
- Использование SpiderMonkey в качестве JavaScript-движка для mongo shell и сервера mongod;
- Новый модуль для сопряжения с системами бизнес-аналитики, такими как Tableau и Qlikview;
- Compass - графический интерфейс для управления MongoDB, визуализации, изучения данных и формирования выборок без необходимости применения языка запросов MongoDB;
<center><a href="https://www.mongodb.com/assets/mongodb_3_2/cloud-manager-ae8... src="https://www.opennet.me/opennews/pics_base/0_1446757109.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border="0"></a></center>- Новая система визуального профилирования выполнения запросов, позволяющая оценить возникающие задержки и выделить медленные запросы к БД;
<center><a href="https://www.mongodb.com/assets/mongodb_3_2/visual-query-prof... src="https://www.opennet.me/opennews/pics_base/0_1446756757.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border="0"></a></center>
- Поддержка частичных индексов, включающих только выборочные документы на основании заданного при создании индекса фильтра;
- Использование по умолчанию движка хранения WiredTiger (http://wiredtiger.com/) вместо ранее используемого движка MMAPv1. WiredTiger отличается высоким уровнем масштабуемости на многоядерных системах, предсказуемым временем обработки запроса, не зависящим от числа записей в базе, возможностью блокировки записей на уровне документов и поддержкой хранения данных в сжатом виде;
- Возможность комбинировать данные из нескольких коллекций документов при помощи оператора $lookup, реализующего слияния типа "left outer join".
URL: http://blog.mongodb.org/post/134796516338/announcing-mongodb...
Новость: http://www.opennet.me/opennews/art.shtml?num=43483
Внятное управление потребляемой памяти сделали?
compass только для шиндошс 7 и осх
Это потому что в виндовс нормальный GUI SDK есть.
По скриншотам на веб-морду похоже. Если не веб, то оооочень странно.
очередная ненужная технология( сколько уже было касандр, коучдб и всяких монго, только почему тогда если это такие прорывные технологии их используют 2,5 анонимуса? если хочется мощности бери SQL, если хочется простоты бери LDAP, а эту приблуду не бери во век не отмоешься)
Ну используем в продакшене, миллионы записей в минуту на обычном сервере может обеспечить только монга. С чего ты взял, что оно никому не нужно?
я не сказал что никому, я сказал нужно очень ограниченному числу(2,5)) но то как подается MongoDB как лекарство от всех болезней, все эти крики "NoSQL-круто, SQL-рип" и прочие бредни просто вымыкают( кстати на счет миллиона записей в минуту на обычном сервере, попробуют OpenLDAP последних версий, потянет только так)
Когда openldap научиться не тормозить при просмотре прав? Десяток тысяч записей стягивает по пол часа. Всю его производительность убивает то, что он не кэширует права, а для каждой записи определяет заново.
в последних версиях тормозов не наблюдал
Mysql легко дает десятки тысяч записей в секунду на таблицах в памяти.
Не знаю как в 5.7, но в 5.6 аналог set, реализованный на sql, у меня сжирал проц на 100% этапе парсинга.
MySQL единым живы? что больше нет SQL? Firebird, PostgreSQL, форки MySQL это только из свободного
Форки не далеко ушли от MySQL. Если конкретнее, то Percona сама заявила что уходить не собирается. MariaDB только подкручивает внешние бирюльки.
хочешь энтерпрайза из мира opensourse бери Firebird(Interbase в девичестве), а если ты будешь в кровавом MySQL юзать, добра не жди.
Никто ничего не хочет. Не надо искать везде скрытый смысл.
Единственная ниша FB - студенческие поделки на Delphi с переносимой БД (для тех кому влом СУБД инсталить) через FBPLus и EhLib. И то с учётом того что компоненты платные, всё сводится к тому что даже студентам проще юзать SQLite под эти нужды.
Да? А у нас как раз-таки тормозила по сравнению с PostgreSQL.
> Ну используем в продакшене, миллионы записей в минуту на обычном сервере может
> обеспечить только монга. С чего ты взял, что оно никому не
> нужно?Миллион записей в минуту это проблема? На MSSQL работал и что-то не помню с этим проблем.
> Миллион записей в минуту это проблема? На MSSQL работал и что-то не помню с этим проблем.а теперь расскажи сколько 8-core nodes в твоём кластере :)
> Ну используем в продакшене, миллионы записей в минуту на обычном сервере может
> обеспечить только монга. С чего ты взял, что оно никому не
> нужно?В Tarantool (http://tarantool.org) можно делать миллионы в СЕКУНДУ на одном ядре обычного ноутбука.
SQL на множестве простых запросов загибается, вот и всё.
Оракель что-то не загибается, так что SQL SQLлю рознь...
Здесь обсуждаются свободные базы?
здесь обсуждаются технологии)
Оракель фуфло. Смысл его использовать только если с тобой откатами делятся. В Яндексе вон планомерно с Оракла на Постгри уходят.
только не надо рассказывать... будет как всегда, СПО базам дадут какой нибудь нетребовательный к производительности и надежности класс задач, а вот все самое вкусное будет крутится все на той же проприоритарщине( еле выговорил, фух!
Не - ну раз ты сказал то конечно ... расходимся пацаны! :)
Тут как с железом, например мощную и надежную санку меняют на кластер дешевых x86. То же самое и с софтом. Вместо дорогих энтерпрайзных баз делают кластера на бесплатном софте. Обеспечивая мощность и стабильность.
пруф в студию
> пруф в студиюКластер по определению не надежнее. В нем частей больше.
Ну и всяко не производительней, а всего лишь лучше масштабируется.
О да, они писали об этом. И к слову графики выкладывали где сравнивали Oracle, PostgreSQL И MySQL на своей нагрузке. И чё то не в пользу последних.
> О да, они писали об этом. И к слову графики выкладывали где
> сравнивали Oracle, PostgreSQL И MySQL на своей нагрузке. И чё то
> не в пользу последних.Ну, по сравнению с Монгой любая из них быстрее.
Сайт всё еще называется OpenNET, причем здесь ваш Оракель? Если бы у всех были средства на него, тут бы наверно не обсуждали MySQL.
я не призываю к покупку Oracle DB я просто утверждаю тот факт что SQL может нагнуть любой NoSQL
И любой NoSQL может нагнуть любой SQL.В зависимости от требований, обстоятельств, и главное - кто, как и в какой руке их держит.
NoSQL может нагнуть SQL я согласен, только какой ценой? ценой нулевой функциональности? завязуй
Разговор в сторону уходит. Не всегда нужна функциональность SQL. Другое дело что если захотеть, можно было бы сделать SQL базу не медленнее любого NoSql. Но этого не произошло и поэтому NoSql базы начали расти как грибы.
> если захотеть, можно было бы сделать SQL базу не медленнее любого NoSqlНельзя. Скорость - цена универсальности.
В общем случае да, в частном - нет.
Для описания частных случаев не используют слово "любой".
SQL, неSQL... Objectivity/DB - базка для объектных данных (что очень удобно для современного, объектного ПО). И что характерно, ещё 10 лет назад петабайтные базы гоняло.
Например с данными стэнфордского линейного ускорителя.Одна проблема - не опенсорс :)
> И любой NoSQL может нагнуть любой SQL.
> В зависимости от требований, обстоятельств, и главное - кто, как и в
> какой руке их держит.Лол.
Нет, по многим фичам. Join-ы, например, ACID.
ACID перпендикулярен SQLности.От джойнов и в реляционных БД часто уходят (и часто это оправданно) с помощью денормализации. В результате получается тот же NoSQL, только кривой.
NoSQL в любом случае кривой, такова его природа)
> SQL на множестве простых запросов загибается, вот и всё.Запросы кривые
> SQL на множестве простых запросов загибается, вот и всё.Тут дело не в том, что SQL или NoSQL. SQL, конечно, дает огромный overhead на парсинг запроса, оптимизатор и т.п., но основные проблемы тут дают устаревшие технологии хранения, основанные на B-деревьях. Любой WiredTiger (или чего там этот webscale теперь юзает) или прочая там София в тарантуле порвет классическое блочное дерево на запись.
> если хочется простоты бери LDAP
> простоты
> LDAPнастало время ох*ительных историй...
поправил "Если хочешь легковесности бери LDAP"... прааативый
Объясните мне, пожалуйста, при чём здесь LDAP и NoSQL ?
они обе используются не по назначению)
> Объясните мне, пожалуйста, при чём здесь LDAP и NoSQL ?LDAP это SQL?
NoSQL имеет такое же отношение к SQL как LDAP)
не поверишь, но в некоторых интерпрайз продуктах (ПАК) та же касандра используется.
http://www.databasesoup.com/2015/12/meet-newest-member-of-po...
оно уже научилось запускаться в контейнере?
> Новый модуль для сопряжения с системами бизнес-аналитики, такими как Tableau и Qlikview
> MongoDB will be shipping PostgreSQL as its "legacy BI connector" in version 3.2, using PostgreSQL+Multicorn FDW as a wrapper to connect SQL-based BI systems to Mongo.
>> Новый модуль для сопряжения с системами бизнес-аналитики, такими как Tableau и Qlikview
>> MongoDB will be shipping PostgreSQL as its "legacy BI connector" in version 3.2, using PostgreSQL+Multicorn FDW as a wrapper to connect SQL-based BI systems to Mongo.Постгря - хорошая база и далеко не везде надо пихать NoSQL.
firebird наше все!!!
> firebird наше все!!!firebird ваше FDW, мы поняли. Не кричите, пациент.
блинг на нем шикраный написали как-то )
еще эмбеддовка была в другой компании(телефонная хреновина развесистая(причем не только VoIP, 5-в-1 аж)).
Постгря - хорошая база и далеко не везде надо пихать NoSQL.Memcached отлично помогает Postgre. Nginx еще и больше ничего не надо практически.
> Постгря - хорошая база и далеко не везде надо пихать NoSQL.
> Memcached отлично помогает Postgre. Nginx еще и больше ничего не надо практически.NoSQL надо, когда:
1. когда надо РАСПРЕДЕЛЕННОЕ. без точек отказа. и масштабирующее нагрузку.
SQL - не может. максимум - репликация и тпю
2. когда надо низкий оверхэд.
3. когда просто логика банальна, исчезающе мала(но это в основном эмбеддовка. и то, только стартовый конфиг)и соотв нужда в SQL - равна 0.во всех Остальных случаях - SQL - заруливает Все и вся.
отдельный случай - Гибридные системы. вроде распределенных SQL-серваков. но это очень "отдельный зверь" и на эту тему книгу надо писать(имеющиеся - довольно поверхностно тему описывают).
>2. когда надо низкий оверхэд.Такой? Лол.
> Постгря - хорошая база и далеко не везде надо пихать NoSQL.Я на последней работе так и сделал после мытарств с этой ;%*$ монгой -- положил всё в PostgreSQL тупо в один столбец типа jsonb.
Проверил скорость -- в 2-3 раза быстрее стало :) Я сначала не поверил даже.
