Вышла MongoDB 2.0

> А с тем убогим подходом, что данные храняться безобразно и неэкономично, монга ляжет брюхом на обращении к дискам.

Сенсация! Профсоюз паровозов разоблачил автомобили! Оказывается они могут ездить непредсказуемо! Автомобили - это надувательство! Только рельсы! Только вперед!

> > А с тем убогим подходом, что данные храняться безобразно и неэкономично, монга ляжет брюхом на обращении к дискам.

Сенсация! Профсоюз паровозов разоблачил автомобили! Оказывается они могут ездить непредсказуемо! Автомобили - это надувательство! Только рельсы! Только вперед!

Нечего возразить по-существу? Марш назад в палату.

>Это типа круто?

это типа единственно возможный безопасный вариант доступа к данным.

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

И нет, монго тут тоже не будет блистать. На этой поляне она будет отнюдь не лучше смотреться

ну как сказать. Тут она шерстит только в путь.

> Нечего возразить по-существу? Марш назад в палату.

Вы опять забываете, что монгу можно поставить на несколько серверов. и соответственно нагрузка IO будет снижена. и нагрузка на одиночный сервер уж точно не будет выше нагрузки sql базы с ее бесконечными join'ами.

>Ага. Например на дневничке типа lleo.me, как вы уже подсказали. :)

дневничок lleo, это простое ддосабельное приложеное. Тоже пойдет.

Мне проблемы сектантов, у которых мозг только табличками работает - до лампочки :)

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

>>И нет, монго тут тоже не будет блистать. На этой поляне она будет отнюдь не лучше смотреться

ну как сказать. Тут она шерстит только в путь.

И как она это делает? :)

> > Нечего возразить по-существу? Марш назад в палату.

Вы опять забываете, что монгу можно поставить на несколько серверов. и

1. Мой пост был не Вам.

2. Не забываю. А Вам не следует забывать, что реляционка тоже может работать более чем на одном сервере.

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

Конечно, дорогой товарищ.

Уже есть возможность воткнуть в сервер несколько терабайт оперативы? :) А сколько это будет стоить? Разумно ли использовать монго, что неэффективно данные хранит?

что ж у вас за базы-то такие с терабайтами данных?

>>Это типа круто?

это типа единственно возможный безопасный вариант доступа к данным.

Да ну?

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

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

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

>что ж у вас за базы-то такие с терабайтами данных?

Уже не у меня. Но там где было, были транзакции и прочие подобные штуки.

> Уже не у меня. Но там где было, были транзакции и прочие подобные штуки.

И все данные актуальные и нужны в любой момент? или 95% это архивная фигня, которая никому не понадобится и лежит просто потому, что так надо?

> > Уже не у меня. Но там где было, были транзакции и прочие подобные штуки.

И все данные актуальные и нужны в любой момент? или 95% это архивная фигня, которая никому не понадобится и лежит просто потому, что так надо?

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

> А Вам не следует забывать, что реляционка тоже может работать более

чем на одном сервере

Очень смешно. Неужели ГовноSQL серверы научились брать и откусывать часть базы и поднимать её на соседнем сервере? Я знаю, почему ты так бесишься и желчь течёт у тебя изо рта. Потому, что никогда ГовноSQL не сможет линейно масштабироваться. НИ-КО-ГДА. И ты готов зубами сейчас стены грызть, чтобы перебить этот недостаток мифическими проблемами NoГовноSQL ;)

Ключевое слово _биобаза_. Прикинь, в биологии (генетике, биохимии) огромная куча разнородных сущностей и все связано практически со всем. Комбинаторику ты знаешь, добавление N+1 таблицы дает N таблиц связей. Плюс еще немного на денормализацию, потому что в нормализованном виде тормозит даже оракл. Но, таки, да, Ад и Израиль.

Кто-то однажды рассказывал про _сто двадцать тысяч_ таблиц в SAP на питерском Филипп-Моррисе. Насколько это может быть правдой, хз.

Понимаешь, анон, если оно вправду все ажно такое сложное, то в 100 коллекций оно нередуцируемо принципиально. Я все-таки подозреваю переинженеринг.

> Ключевое слово _биобаза_. Прикинь, в биологии (генетике, биохимии) огромная куча разнородных сущностей и все связано практически со всем.

Я в принципе не биохимик и не генетик, но мне все же кажется, что, допустим, создавать по таблице на каждый протеин или полимер — это все-таки треш. Треш не потому, что уровень сущностей, скорее всего, выбран неправильно (в принципе, в постгресе частично проблему можно за счет наследования порешать), а потому, что у вас там, скорее всего, динамическое изменение схемы (в жисть не представлю, как один DBA генерирует из головы 8000 таблиц или 120000) — читай, источник труднонаходимых багов.

(Я из лагеря тех, кто считает, что схема БД в 99% должна меняться только по праздникам и по нотариально заверенной заявке, подписанной кровью в трех экземплярах. Меня трудно убедить, что ваш случай именно из того заветного 1%.)

> Очень смешно. Неужели ГовноSQL серверы научились брать и откусывать часть базы и поднимать её на соседнем сервере?

Вообще-то сервер это делать не обязан. Это вполне может делать и приложение.

И кстати, если всякие монги делают не так, а шлют запрос на один из серверов «от балды» то это вообще уже верх деградации.

Я знаю, почему ты так бесишься и желчь течёт у тебя изо рта.

Вообще-то я спокоен как удав. :)

Потому, что никогда ГовноSQL не сможет линейно масштабироваться. НИ-КО-ГДА.

Строго говоря, линейно не может масштабироваться вообще ничего. В том числе монго.

А «как-бы линейно» может и шард из реляционок. Фундаментальной проблемы тут нет. И не надо скулить про локи. :) Я уже писал, как на эту проблему не напарываться.

Но ни один один NoSQL-дрочер до сих пор не смог пояснить, как на NoГовноSQL (существующих, а не мифических) писать тучи транзакций в базу и при этом собирать разные totals в реальном времени и гарантированно без ошибок.

И ты готов зубами сейчас стены грызть, чтобы перебить этот недостаток мифическими проблемами NoГовноSQL ;)

Расслабься, детка. Недостаток есть только один - усохший мозг адептов NoГовноSQL.

А я утверждаю, что на тех задачах, которые ложатся на NoSQL, можно использовать и реляционку. Причем маштабируемость будет идентична. А гибкость - больше.

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

> Кто-то однажды рассказывал про _сто двадцать тысяч_ таблиц в SAP на питерском Филипп-Моррисе. Насколько это может быть правдой, хз.

Товарищи, расстрел за такое должен быть законодательно закреплен в каждой стране. :)

> А я утверждаю, что на тех задачах, которые ложатся на NoSQL, можно использовать и реляционку. Причем маштабируемость будет идентична. А гибкость - больше.

LOL. Мы наконец-то увидим адекватную схему для каталога разнородных товаров? Или как обычно, завтра объявят по радио, что из дурки сбежал пациент с особой приметой - предлагает «всегда делать базы только на sql»?

> LOL. Мы наконец-то увидим адекватную схему для каталога разнородных товаров? Или как обычно, завтра объявят по радио, что из дурки сбежал пациент с особой приметой - предлагает «всегда делать базы только на sql»?

Я могу предложить два равнозначно геморных варианта 1. Хранить все поля всех объектов в таблице, это будет занимать очень дохрена места зато запросы будут не слишком сложными. А при добавлении колонок в таблицу с парой-другой миллионов записей освободится время, чтобы пойти чайку попить пару раз)

2. Повернуть таблицу на 90 градусов. в результате гибко, как и говорил товарищ. Только выборки будут адовыми). Размер таблиц будет огромным и работать это будет не слишком торопливо

В случае слоника можно прикрутить наследование, но это не уменьшит размер таблиц, а только лишь немного упростит работу.

Сам с такой задачей сталкивался, правда не в разрезе каталога товаров, а в разрезе приборов с различным набором параметров. и могу сказать, что на sql это делать не слишком приятно

> Я могу предложить два равнозначно геморных варианта

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

Предлагаю еще более простой вариант - серилизовать все объекты, и затолкать в 1 строчку блобом.

> > А я утверждаю, что на тех задачах, которые ложатся на NoSQL, можно использовать и реляционку. Причем маштабируемость будет идентична. А гибкость - больше.

LOL. Мы наконец-то увидим адекватную схему для каталога разнородных товаров? Или как обычно, завтра объявят по радио, что из дурки сбежал пациент с особой приметой - предлагает «всегда делать базы только на sql»?

Троекратное LOL. Ты не знаешь ни NoSQL ни SQL, а пытаешься комментировать. :) Брысь назад в палату, а то санитаров позову.

П.С. Я не имею в виду, что имеет смысл использовать только SQL. Даже для убогого монго и прочих дивнов с кассандрами есть место. Но оно слишком маленькое. И если тебе кажется, что это как раз твой случай - скорее всего тебе надо осенить себя крестным знамением и читать Отче Наш. И нет, реляционки не страдают от локов по поводу и без. Просто вы не умеете ими пользоваться. А в тех немногих случаях, где локи действительно досаждают, данные просто не лягут на модель «коллекция документов, транзакции отсутствуют».

> Предлагаю еще более простой вариант - серилизовать все объекты, и затолкать в 1 строчку блобом.

Похоже, ты еще тупее, чем кажешься.

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

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

Ты, похоже, еще и читать не умеешь. :)

Наконец-то! Толстый тролль, напукавший не по теме 5 страниц, меня разоблачил!

Оставь этого кащенита в покое. Никогда не спорь с дураком, потом трудно будет отличить, кто где.

> Кто ее использует? Как впечатление? Особенно по сравнению CouchDB.

Использовали MongoDB пару месяцев в продакшене. После хорошего начала на одной машине - потом полное разочарование. Настройка и управление кластером - шаманство до головной боли. Памяти жрёт много и кашляет если её мало.

Репликация данных или расчёт индекса блокируют не только один коллекшен, но и всю базу целиком ( https://jira.mongodb.org/browse/SERVER-1240 ). Блокировки частые и нереальные для продакшена.

После работы с CouchDB или ElasticSearch теперь каждый намёк на поделку MongoDB приводит сотрудников в дрожь. 10gen хороший маркетинг для MongoDB провела и ещё бабок получили - молодцы предприниматели.

CouchDB: долгосрочная Master-Master репликация и MapReduce (в продакшене).

ElasticSearch: отличный кластер и супер поиск на основе Apache Lucene, может работать в связке с CouchDB или как независимая база (в продакшене).

> Couch дико медленный

5000 записей новых документов в секунду на SATA - это не медленно. Чтение тоже быстро работает. MapReduce при простой функции считает сотни или тысячи документов в секунду. Использует все ядра процессора.

MongoDB использует при записи или MapReduce только одно ядро процессора.

Какие еще форки?

Почему?

Хэш-таблицы - не труЪ, т.к. не могут гарантировать быстроты (в худшем случае поиск за O(N)). ТруЪ - бинарные и B-деревья, и в СУБД только они и используются, т.к. могут гарантировать O(logN).