Комментарии 99
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, Вы правы, добавил ссылку в конце материала.
НЛО прилетело и опубликовало эту надпись здесь
и, желательно, с несколькими СУБД. Наиболее интересны PostgreSQL, Oracle, MS SQL Server.
Мускул это все же не самая скоростная БД…
Мускул это все же не самая скоростная БД…
«Мускул это все же не самая скоростная БД…»
Вы просто не умеете её готовить :) Просто все перечисленные субд хороши в своей стихии.
mysql > load data infile = 1млн строк за 4-10 секунд — как вам такая скорость?
Это конечно самый утрированный пример, но все жё — есть разные методы оптимизации и прежде всего лучше исходить из задачи и её ограничений (читать условий)
—
PS. если тц опубликует сорцы бенч'а (который возможно сделает) — то думаю найдутся добровольцы самостоятельно прогнать по другим субд и поделиться результатами. Так что — пусть покажет нам — скорость! ;)
Вы просто не умеете её готовить :) Просто все перечисленные субд хороши в своей стихии.
mysql > load data infile = 1млн строк за 4-10 секунд — как вам такая скорость?
Это конечно самый утрированный пример, но все жё — есть разные методы оптимизации и прежде всего лучше исходить из задачи и её ограничений (читать условий)
—
PS. если тц опубликует сорцы бенч'а (который возможно сделает) — то думаю найдутся добровольцы самостоятельно прогнать по другим субд и поделиться результатами. Так что — пусть покажет нам — скорость! ;)
А вот меня Firebird Интересует…
мой сегодняшний тест
stas-agarkov.livejournal.com/17659.html
stas-agarkov.livejournal.com/17659.html
Такие тесты ничего не покажут, так как подход в реализации задач слишком разный.
«типовые задачи» в скорости могут отличаться в сотни и тысячи раз, как с преимуществом у key-value баз данных, так и у реляционных.
«типовые задачи» в скорости могут отличаться в сотни и тысячи раз, как с преимуществом у key-value баз данных, так и у реляционных.
в этом случае нужно рассматривать задачи более высокого уровня, чем извлечение/помещение данных в БД. Например, реализовать несколько небольших проектов и поглядеть их сложность и скорость (потому что если и сложнее и медленней — то нафиг оно вообще нужно).
Ну вот есть у меня проект, который изначально был на mysql, а потом был переписан на couchdb, потому что mysql просто не справлялся с нагрузкой, а couchdb я даже в top не вижу. Как мне их сравнивать? :)
На маленьких проектах разница в скорости будет на уровне погрешности измерений (нереляционные базы долго запрягают, но быстро едут, а реляционные быстро запрягают, но туго ездят), а на больших сравнивать банально нечего — либо нереляционные нельзя применять, либо реляционные не тянут и 1% нагрузки от того, что дают нереляционные.
На маленьких проектах разница в скорости будет на уровне погрешности измерений (нереляционные базы долго запрягают, но быстро едут, а реляционные быстро запрягают, но туго ездят), а на больших сравнивать банально нечего — либо нереляционные нельзя применять, либо реляционные не тянут и 1% нагрузки от того, что дают нереляционные.
Плюсую. Так и есть. И с приходом Mongo, область применения не-реляционных значительно расширились :-)
НЛО прилетело и опубликовало эту надпись здесь
Подробности раскрывать не могу, опишу общими словами.
Есть несколько потоков, читающие и пишущие в базу.
Структура базы — две таблицы. Одна — список сущностей (около 200.000 на тот момент было). Вторая — история обработки сущностей (около миллиона).
Потоки брали сущности из базы (select from table1), блокировали их (update table1), какое-то время работали с ними, дописывали во вторую таблицу логи (insert into table2), потом обновляли состояние сущности (update table1) на основании истории (select from table2).
Пока использовался mysql, больше 6-8 запустить было невозможно, mysql отъедал одно ядро полностью и дальше не давал рости.
Был так же web-interface для просмотра статистики, запросы на котором (2-3 запроса по хорошим ключам) отрабатывали секунд по 20. С него так же генерилось небольшое количество insert/update (порядка 1-2 в минуту), которые так же отрабатывали с дикими тормозами.
В случае с couchdb, его не видно в top, процессов запущено около 30, они грузят полностью 4 ядра и больше потестировать не могу. При этом, база выросла в несколько раз (количество сущностей — около 1.700.000).
Организована couchdb так: один документ — одна сущность из table1, у каждой из них история в виде списка в одном из полей.
Веб-интерфейс теперь отрабатывает мгновенно.
Есть несколько потоков, читающие и пишущие в базу.
Структура базы — две таблицы. Одна — список сущностей (около 200.000 на тот момент было). Вторая — история обработки сущностей (около миллиона).
Потоки брали сущности из базы (select from table1), блокировали их (update table1), какое-то время работали с ними, дописывали во вторую таблицу логи (insert into table2), потом обновляли состояние сущности (update table1) на основании истории (select from table2).
Пока использовался mysql, больше 6-8 запустить было невозможно, mysql отъедал одно ядро полностью и дальше не давал рости.
Был так же web-interface для просмотра статистики, запросы на котором (2-3 запроса по хорошим ключам) отрабатывали секунд по 20. С него так же генерилось небольшое количество insert/update (порядка 1-2 в минуту), которые так же отрабатывали с дикими тормозами.
В случае с couchdb, его не видно в top, процессов запущено около 30, они грузят полностью 4 ядра и больше потестировать не могу. При этом, база выросла в несколько раз (количество сущностей — около 1.700.000).
Организована couchdb так: один документ — одна сущность из table1, у каждой из них история в виде списка в одном из полей.
Веб-интерфейс теперь отрабатывает мгновенно.
НЛО прилетело и опубликовало эту надпись здесь
о, живой опыт людей всегда интересен. Сейчас как раз присматриваюсь к подобным БД (Couch и Mongo), нет ли в планах статьи на тему?
И тогда по CouchDB сразу вопрос — а запросы в виде материализованных видов не напрягают? Каждый раз их определять на мой взгляд несколько муторно по сравнению с приснопамятным SQL или запросами к Mongo.
И тогда по CouchDB сразу вопрос — а запросы в виде материализованных видов не напрягают? Каждый раз их определять на мой взгляд несколько муторно по сравнению с приснопамятным SQL или запросами к Mongo.
а скорость работы по сравнению с sql подобными?
например тот же пример с " каталог товаров по типу Яндекс.Маркета".
например тот же пример с " каталог товаров по типу Яндекс.Маркета".
Ссылку на бенчмарк в конце добавил. На элементарных задачах скорость выше, поскольку нет парсинга запроса и абстракции над storage engine. Реализацию же Яндекс.Маркета даже сравнивать бессмысленно, разница будет на порядок, т.к. подходы разные.
а в каких задачах все же лучше использовать sql? или можно смело изучать и пересаживаться на MongoDB?
С ходу не могу придумать такую задачу. Думаю, если кажется что MongoDB не справится, а SQL справится, то значит это проблемы с проектированием. Как показала практика, сложные выборки нужны довольно редко, выборки сильно упрощаются при правильном проектировании.
Не знаю ваших задач, но думаю, можно смело пересаживаться.
Не знаю ваших задач, но думаю, можно смело пересаживаться.
Бенчмарк не понравился — автор использовал для хранилища MongoDB свою флешку, база была всего лишь на 2 млн записей и нет информации о том, насколько обе базы во время тестирования загрузили компьютер. Нет ли еще тестов? Впрочем у всех настолько разные цели использования БД, что лучше будет провести свой собственный тест.
НЛО прилетело и опубликовало эту надпись здесь
Ждем продолжения, интересно
Давненько хотел познакомиться с MongoDB, но никак руки не доходили. Теперь появилась надежда, но хотелось бы побольше информативного материала — схемы, диаграммы, сводные таблицы и т.д. Очень сложно читать новый для себя материал, представленный голым текстом.
Спасибо, жду продолжения.
Спасибо, жду продолжения.
Удобство — эт очень хорошо.
Но как дела со скоростью сложных выборок?
Но как дела со скоростью сложных выборок?
там где надо kv-системы, НЕТ сложных выборок или они заменяются логикой приложения + серия быстрых простых выборок. Тех приложений, где реально надо сложные выборки — они использую СУБД
Что Вы подразумеваете под СУБД? Реляционную СУБД? MySQL? :-)
Не могу придумать задачи, где хватит простой kv-базы. Обычно бывает так что нужны простые «by id» операции с коллекцией, ну и элементарный постраничный вывод с сортировкой по ключу. Вряд ли разумно ради этого использовать реляционную СУБД, со всей её беспощадностью.
Не могу придумать задачи, где хватит простой kv-базы. Обычно бывает так что нужны простые «by id» операции с коллекцией, ну и элементарный постраничный вывод с сортировкой по ключу. Вряд ли разумно ради этого использовать реляционную СУБД, со всей её беспощадностью.
что насчет couchdb?
это документ-ориентированая база, скорее даже хранилище. а не kv-storage
я знаю что это, интересно в сравнении с mongo, последняя вроде как взрослее, но кауч догоняет наверное
Разработчики этих продуктов знакомы между собой :-)
CouchDB vs. MongoDB Benchmark
CouchDB vs. MongoDB Benchmark
Можно упомянуть, что лимит размера объекта в коллекции в 4 мегабайта может создать проблемы при сильной вложенности…
"MongoDB + Memcached? Покруче чем Бонни и Клайд!". при таких утверждениях, всегда приходит на ум мысль о том, как эти ребята кончили… так что нужно по аккуратней в сравнениях )))
НЛО прилетело и опубликовало эту надпись здесь
То есть вы предлагаете разрезать MySQL'ю мозг скальпелем и вставить чип XML-парсера чтоб он индекс строил по XML-полям? Во-первых это будет тормознее чем MongoDB, во-вторых получатся те же яйца только сбоку. Кстати, в этой приблуде надо будет еще нагородить нечто для атомарных update'ов.
Не уловил мысль про изменчивые атрибуты и быстрый доступ к полю…
Не уловил мысль про изменчивые атрибуты и быстрый доступ к полю…
Автор забыл указать один существенный недостаток — ограничение размера базы на 32-битных машинах в 2 Гб. Для преодоления этого барьера, разработчики рекомендуют использовать 64-битные процессоры, однако умалчивают, каким будет ограничение размера базы в этом случае. Подозреваю, что не больше размера ОЗУ. А вы как думали, откуда берется такая скорость? Правильно, объекты хранятся в памяти. Как-то совсем нерационально получается с точки зрения хранения данных, особенно если использовать довольно интересную возможность хранения бинарных данных в MongoDB.
Автор написал об этом полчаса назад. Это действительно так, но ведь 32-битные сервера это редкость, тем более что на них можно использовать эмуляторы 64-битности.
> Подозреваю, что не больше размера ОЗУ.
Вы заблуждаетесь, я знаю людей, которые хранят свыше 200 гигабайт в одной коллекции, и всё замечательно и быстро работает. Посмотрите хотя бы бенчмарк по ссылке.
> Подозреваю, что не больше размера ОЗУ.
Вы заблуждаетесь, я знаю людей, которые хранят свыше 200 гигабайт в одной коллекции, и всё замечательно и быстро работает. Посмотрите хотя бы бенчмарк по ссылке.
Лимиты про 2Гб — это из-за использования mmap. К размеру ОЗУ отношения не имеет.
MongoDB может со временем заменить MySQL?
Что значит заменить? Это разные вещи, которые нужно применять для разныз задач. Реляционные БД никуда не денутся. А вот нереляционные документоориентированные и объекториентированные БД, надеюсь, найдут свое место в веб-приложениях. Я вообще считаю, что веб испорчен SQL'ем. Если бы изначально реляционные БД не применялись там, где их функционал явно избыточен, то современный веб выглядел бы совершенно иначе. Все эти френдленты и плоские комментарии — явное следствие использования реляционных БД. JSON куда более природен для восприятия человеком, чем линейные выборки из реляционных БД.
Так а где была альтернатива? Если бы объектные развились лет на 10 пораньше, то наверняка бы они заняли своё место в Вебе, но увы…
идея объектных баз данных не нова. была и есть такая страшная штука Zope, в ней объектная база данных и ей уже лет 10.
есть целый выводок xml баз данных и это тоже далеко не новость.
Все эти проекты заняли свое место но мейнстримом не стали да и не станут.
Вообще уход от реляционных бд это шаг назад на несколько десятков лет. И не все так хорошо в нереляционных базах как оно хотелось бы. Нужно 10 раз думать предже чем начать приманять подобные вещи на практике.
Ради спортивного интереса последнее время ковыряю CouchDB. В течении пары недель думаю выжму из себя несколько статей на эту тему с живыми примерами и может быть тестами.
есть целый выводок xml баз данных и это тоже далеко не новость.
Все эти проекты заняли свое место но мейнстримом не стали да и не станут.
Вообще уход от реляционных бд это шаг назад на несколько десятков лет. И не все так хорошо в нереляционных базах как оно хотелось бы. Нужно 10 раз думать предже чем начать приманять подобные вещи на практике.
Ради спортивного интереса последнее время ковыряю CouchDB. В течении пары недель думаю выжму из себя несколько статей на эту тему с живыми примерами и может быть тестами.
> есть такая страшная штука Zope
Воистину страшная!
После работы с этим чудом инженерной мысли я с большим предубеждением воспринимаю все «самопальные» (то есть не имеющие ~100К серьезных внедрений) базы данных. Как почитаешь про ZODB так все выглядит очень гладко, но на практике как обычно «забыли про овраги». При росте базе (всего ~10K записей) начались серьезные тормоза, кроме того база, заявленная как очень надежная, постоянно сыпалась почище myisam, хуже того — средств восстановления для нее нет.
После работы с этим зопом я понял почему его так назвали.
А «геморрой — это зопяная боль».
Воистину страшная!
После работы с этим чудом инженерной мысли я с большим предубеждением воспринимаю все «самопальные» (то есть не имеющие ~100К серьезных внедрений) базы данных. Как почитаешь про ZODB так все выглядит очень гладко, но на практике как обычно «забыли про овраги». При росте базе (всего ~10K записей) начались серьезные тормоза, кроме того база, заявленная как очень надежная, постоянно сыпалась почище myisam, хуже того — средств восстановления для нее нет.
После работы с этим зопом я понял почему его так назвали.
А «геморрой — это зопяная боль».
Были и есть более удачные реализации многомерных БД (и построенной поверх них объектности), к примеру www.cache.ru/
да она коммерческая — но уже десятки лет ( а точнее раньше самой каше ) были и есть M системы ( а каше ей и является )
и были умники которые говорили что реляционки теперь не нужны — сам был среди них.
а теперь оглянитесь и посмотрите на чем сделана большая часть проектов.
да она коммерческая — но уже десятки лет ( а точнее раньше самой каше ) были и есть M системы ( а каше ей и является )
и были умники которые говорили что реляционки теперь не нужны — сам был среди них.
а теперь оглянитесь и посмотрите на чем сделана большая часть проектов.
> Все эти френдленты и плоские комментарии — явное следствие использования реляционных БД.
Ага, какже. Каменты деревьями нереляционная база данных конечно построит сама ))) Гемороя будет в лучшем случае столько же.
> JSON куда более природен для восприятия человеком, чем линейные выборки из реляционных БД.
Как сказать, у меня в мозгу к сожалению не крутиться V8 или greaseMonkey чтоб json был понятней
Ага, какже. Каменты деревьями нереляционная база данных конечно построит сама ))) Гемороя будет в лучшем случае столько же.
> JSON куда более природен для восприятия человеком, чем линейные выборки из реляционных БД.
Как сказать, у меня в мозгу к сожалению не крутиться V8 или greaseMonkey чтоб json был понятней
В MongoDB деревья можно хранить прямо деревом ;-) То есть вкладывать объекты друг в друга.
ага а если дерево вдруг стало больше 4 метров мы увидим болт вместо каментов )))
Во-первых лимит можно повысить, во-вторых можно ID сообщений хранить в объекте, а тексты хранить в отдельной коллекции. Т.е. мы выдергиваем первым запросом нужную нам структуру, а затем уже выдергиваем одним запросом все нужные тексты, это даже быстрее будет работать, т.к. структура со ссылками на тексты будет совсем простая. Это нормальная практика — хранить дерево отдельно от данных.
V8 и greaseMonkey — это просто инструмент формирования нужной выборки. И он может быть любым, хоть Python, хоть Ruby, хоть даже Io language. Говоря человеческим языком, данные прогоняются через программу, которая отсеивает все лишнее и оставляет только нужное, которое потом складывается/добавляется в отдельную коллекцию, которая при последующем запросе отдается уже без протаскивания через «программный фильтр», а потому — достаточно быстро.
JS-движки в качестве бэкендов применяются по умолчанию видимо потому, что JSON — это родной формат JS (JavascriptObjectNotation).
JS-движки в качестве бэкендов применяются по умолчанию видимо потому, что JSON — это родной формат JS (JavascriptObjectNotation).
> Ага, какже. Каменты деревьями нереляционная база данных конечно построит сама )))
Вообще JSON он на то и JSON, чтоб позволять хранить документ поста вместе с деревом комментариев и строить вообще ничего не придется. Но с таким подходом возникают уже другие проблемы, например, «одновременное» добавление комментариев, что по сути будет означать «одновременное» редактирование документа поста.
Вообще JSON он на то и JSON, чтоб позволять хранить документ поста вместе с деревом комментариев и строить вообще ничего не придется. Но с таким подходом возникают уже другие проблемы, например, «одновременное» добавление комментариев, что по сути будет означать «одновременное» редактирование документа поста.
На высоких нагрузках, думаю очень заменит скоро. Однако, сообщество инертно, и вряд ли стоит ожидать массового перехода в скором времени… mainstream весьма ленивая вещь.
>> Для многих, «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами…
У меня она ассоциируется с Oracle и Microsoft SQL Server.
У меня она ассоциируется с Oracle и Microsoft SQL Server.
А вообще, статья уж больно похожа на рекламу.
вопросы автору:
1. почему именно MongoDB, а не Redis, например? ну, то есть ты (ничего, если на «ты»? заранее прошу прощения) смотрел сравнивал и выбрал в итоге mongo, или просто именно монго попалась под руку?
2. а какая примерно нагрузка на проект, и сколько приходится на mongo?
3. я так понял (код, правда, читал совсем бегло), что внутри phpdaemon :: appInstance кэшируются результаты из memcached, а сам memcached кэширует монгу. то есть слоёв кэширования два. зачем столько?
и есть ли профит между mongo+memcached и просто mongo?
1. почему именно MongoDB, а не Redis, например? ну, то есть ты (ничего, если на «ты»? заранее прошу прощения) смотрел сравнивал и выбрал в итоге mongo, или просто именно монго попалась под руку?
2. а какая примерно нагрузка на проект, и сколько приходится на mongo?
3. я так понял (код, правда, читал совсем бегло), что внутри phpdaemon :: appInstance кэшируются результаты из memcached, а сам memcached кэширует монгу. то есть слоёв кэширования два. зачем столько?
и есть ли профит между mongo+memcached и просто mongo?
1. В статье упоминается Redis. Ничего. Я его очень конкретно изучал и юзал, даже свой драйвер написал. Redis однотредовый и убогий.
2. Пока небольшая, однако тесты оптимистичные. Намного лучше чем на MySQL (с нее слезаю), хотя поверь, я далеко не новичок в MySQL.
3. phpDaemon::MongoNode читает в реальном времени бинарной лог Mongo и бросает в memcached объекты в которых есть _key.
Безусловно есть. Нельзя сравнивать производительность кластера memcached и любой другой базы данных, которая хранит данные на диске. Хотя я кеширование использую только для небольших горячих объектов которых в сумме метров на 10, их целесообразнее дергать из памяти.
2. Пока небольшая, однако тесты оптимистичные. Намного лучше чем на MySQL (с нее слезаю), хотя поверь, я далеко не новичок в MySQL.
3. phpDaemon::MongoNode читает в реальном времени бинарной лог Mongo и бросает в memcached объекты в которых есть _key.
Безусловно есть. Нельзя сравнивать производительность кластера memcached и любой другой базы данных, которая хранит данные на диске. Хотя я кеширование использую только для небольших горячих объектов которых в сумме метров на 10, их целесообразнее дергать из памяти.
> Redis однотредовый
И что с этого? Там используется асинхронный способ работы с данными
И что с этого? Там используется асинхронный способ работы с данными
Для того чтобы выжрать ресурсы Quad Xeon'а автор предлагает запустить 8 редисок и балансировать между ними по ключам:-)
Ради простоты внутренней архитектуры и быстродействия было решено сделать редис однопоточным. Он простой в понимании => простой в применении.
С другой стороны, непонятно, зачем нагружать редис так, что нужны все 8 ядер? Этоже kv- _store_. Т.е. основное предназначение сохранять данные, а обрабатывать их должно приложение, которое уже может работать на нескольких потоках.
С другой стороны, непонятно, зачем нагружать редис так, что нужны все 8 ядер? Этоже kv- _store_. Т.е. основное предназначение сохранять данные, а обрабатывать их должно приложение, которое уже может работать на нескольких потоках.
НЛО прилетело и опубликовало эту надпись здесь
Значит, я добился своей цели :))
НЛО прилетело и опубликовало эту надпись здесь
Но всё-таки основные преимущества в hi-load проектах и чисто по быстродействию в условиях масштабирования и множественных добавлений и изменений? Как насчёт простоты (особенно привыкшим к реляционным БД, не обязательно SQL ;) ) проектирования и реализации на уровне серверов приложений, что в «голом» SQL, что по сравнению с ORM «прокладками»? В общем «серебряная пуля» или нужно досконально знать все плюсы и минусы разных альтернатив, хотя бы на уровне ORM vs «объектно-документарная база данных» (не знаю как написать на инглише — гугл и рамблер дают ссылку только на этот топик — термин ваш лично? )
Для домашней странички можно использовать что угодно, однако я лично не вижу чем работа с Mongo сложнее написания SQL-запросов, в чем-то даже проще. Проектировать значительно проще, поскольку не надо думать о схеме и об изменениях в ней. В MySQL и иже с ним меня сильно демотивирует что каждый раз надо поле ручками добавлять или менять его тип.
Да, термин мой, просто на мой взгляд, она и не объектная (это все же немного другое) и не документарная (не BigTable). Кстати я планирую написать парсер SQL-запросов и конвертатор в Mongo-запросы на лету: то есть просто подключаете этот слой и делаете например SELECT * FROM collection WHERE x > 1 AND y < 5. По большому счету ничего сложного.
Да, термин мой, просто на мой взгляд, она и не объектная (это все же немного другое) и не документарная (не BigTable). Кстати я планирую написать парсер SQL-запросов и конвертатор в Mongo-запросы на лету: то есть просто подключаете этот слой и делаете например SELECT * FROM collection WHERE x > 1 AND y < 5. По большому счету ничего сложного.
ага) особенно после слов «резкая как понос» ))
а ещё MongoDB может работать как database backend для Django — bitbucket.org/kpot/django-mongodb/
Я тоже обратил на это внимание :)
Осталось понять насколько хорошо это будет работать. Все же делалось django с реляционными бэкендами, насколько хорошо оно будет работать с нераляционным? Конечно, делали его люди талантливые, и написано довольно абстрактно от хранилища. Но все же хотелось бы реальных тестов, насколько одно к другому подходит. Не вылезет ли там гигантский оверхед, который убьет затею на корню?
Осталось понять насколько хорошо это будет работать. Все же делалось django с реляционными бэкендами, насколько хорошо оно будет работать с нераляционным? Конечно, делали его люди талантливые, и написано довольно абстрактно от хранилища. Но все же хотелось бы реальных тестов, насколько одно к другому подходит. Не вылезет ли там гигантский оверхед, который убьет затею на корню?
> либо делать партишенинг таблиц, разбивая таблицу на несколько частей и храня их в разных местах, > согласно заданному закону (например по ID), однако это унесет в могилу прелести JOIN
А как эта проблема решена в монго? Он позволяет сделать некий JOIN данных между разными шардами?
Sharding Introduction
Это тема второй, более подробной статьи на эту тему. Там я рассмотрю все эти аспекты вполне детально.
Это тема второй, более подробной статьи на эту тему. Там я рассмотрю все эти аспекты вполне детально.
Сама БД клёвая, и я как-то тестировал ее, но, почему-то, получилось медленнее MySQL:
blog.knopkodav.ru/2009/10/mongodb-vs-mysql.html
Специально ни тот ни другой не настраивал, всё, можно сказать, из коробки.
Что тут не так?
blog.knopkodav.ru/2009/10/mongodb-vs-mysql.html
Специально ни тот ни другой не настраивал, всё, можно сказать, из коробки.
Что тут не так?
Коллекция в Mongo создается не при вызове mongo = mongo_db.collection(«beta»), а при первом вызове mongo.insert(doc). Ну и по умолчанию в Mongo большой pre-allocation места для коллекции, так что грубо говоря 4.999 создавался пустой файл размером порядка 2.5 гб (зависит от свободного места на разделе), а остальные 0.001 делались полезные операции.
Создайте пустую коллекцию изначально, а потом протестируйте ;-) В init достаточно делать «mongo.remove».
Создайте пустую коллекцию изначально, а потом протестируйте ;-) В init достаточно делать «mongo.remove».
Нереалиационные БД хороши и быстры,
однако реалицонность можно сделать нормально только с РСУБД.
Хорошо что есть и те, и те :)
А ещё лучше то, что есть такие как MySQL и TokyoCabinet
однако реалицонность можно сделать нормально только с РСУБД.
Хорошо что есть и те, и те :)
А ещё лучше то, что есть такие как MySQL и TokyoCabinet
>В качестве уникального идентификатора используется не auto-increment'ное поле, а 12-байтное уникальное число, генерируемое на клиенте.
А может 24-байтное?
А может 24-байтное?
Например, при использовании master-master, мы заплатим auto increment'ами.
Не заплатим. Схема стара как мир. Например, пусть у нас два мастера. На первом стартовое значение делаем 1, на втором — 2 и на обоих шаг делаем в два. Всё.
Интересно, а вот спустя 6 лет, автор статьи не разочаровался в mongoDB?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB или как разлюбить SQL