Вышла MongoDB 2.0

> а) скорость у монго не выше чем у всяких там mysql и postgres

Документами - выше. На запись тоже выше. В мускуле документов вообще толком нет.

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

Мне не нужно сложных выборок. А каталог разнотипных товаров на EAV - это прекрасный пример того, как мускуль умеет делать сложные выборки, которые не нужны.

в) масштабирование можно и на mysql и postgres сделать

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

Так что плюсы спорны, а минусы - бесспорны.

Так что понимание задач спорно, а троллинг бесспорен.

м придется вручную разруливать какой айдишник на каком шарде

А в либу засунуть, не?

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

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

>Печально. Похоже на кривоту mysql.

Ни разу. Это родовая болезнь SQL. Любой SQL сервер при увеличении нагрузки ловит локи и умирает.

> Терабайты?

У меня данных много пока не бывало. Скажем так.. Десяток-сто гигабайт всяких мелких записей слоник поднимает на недорогом железе и неплохо в этом копошится с сотнями активных подключений.

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

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

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

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

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

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

Пара серверов выйдет в итоге дешевле гемора с поднятием пролежавшего полдня мускула.

>Я просто гляну в глаза фактам. Там где для решения на слонике нужен старенький серверок, для аналогичного решения на монго нужен современный кластер (т.к. монго - жалкий тормоз). Меня не сильно удивляет, что задосить старую машинку сложнее чем компашку новых. :)

Это да. Правда мускул на старом железе заруливает постгрес во все щелки.

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

Угу. Осталось понять, насколько актуально решить задачу утилизации старых серверов. У хетцнера минимальный интеловский сервер - i7-920 с 8 гигабайтами памяти, за ~50 баксов.

Наверное, мускуль может гордится тем, что заработет на VDS за 5 баксов, и даже кого-то там обгонит. Наверное, есть «задачи», где экономия 45 баксов в месяц - это очень серьезно.

> Не терабайты, но и подключений поболее будет. мускул затыкался на что-то около 15к подключениях в секунду.

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

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

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

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

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

Вот только как не преподноси проститутку, леди она не станет. :)

>>Печально. Похоже на кривоту mysql.

Ни разу. Это родовая болезнь SQL. Любой SQL сервер при увеличении нагрузки ловит локи и умирает.

Вы с SQL вообще знакомы? На тех запросах, которые делаются на монге, в SQL базах локи будут разве что на уровне записей. Монга ваша делает то же самое (просто подставь вместо слова «запись» слово «документ»). Так что ничего умирать не будет. И масштабируется тоже без проблем.

>> б) простые выборки он умеет, а что-нибудь слегка сложнее - нет

Мне не нужно сложных выборок.

Сегодня не нужно. Завтра будет не нужно. А послезавтра - нужно. И причем так, что хоть вешайся. Что делать будешь? Биться головой об стену и перелазить с монго еще куда-нибудь?

> Ура убийце MySQL!

Ура убийце SQL!

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

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

Да, это нормально. Несколько сот серверов приложений, десятки тысяч клиентов. Это бывает, представь себе.

запись, это запись. А документ, это документ.

в SQL документ в самом простом случае формируется перемножением всех справочников и связующей таблицы.

В этом и проблема, то SQL размазывает документ по десяткам таблиц.

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

Да, это нормально. Несколько сот серверов приложений, десятки тысяч клиентов. Это бывает, представь себе.

Т.е. один сервер приложений держит порядка сотни подключений к базе? По одному на клиента что-ли? Зачем?

> запись, это запись. А документ, это документ.

в SQL документ в самом простом случае формируется перемножением всех справочников и связующей таблицы.

В этом и проблема, то SQL размазывает документ по десяткам таблиц.

Если хочешь - ничто не мешает сделать из SQL базы монгоподобие: просто одна запись будет содержать два значения: ключ и «документ». Не знаю как в myqsl, но в postgresql есть xmlvalue, которого должно более чем хватить. Но можешь действительно разнести данные по таблицам и сэкономить на объеме хранимых данных.

>Т.е. один сервер приложений держит порядка сотни подключений к базе? По одному на клиента что-ли? Зачем?

Да. Потому что так — просто. Один клиент - один поток (или процесс, я не разработчик), один коннект. Почему? Потому что это просто, и монга позволяет это делать и не изобретать чего-то более сложного.

Еще можно из буханки хлеба сделать троллейбус.

> Еще можно из буханки хлеба сделать троллейбус

это вряд-ли. из хеша ничего нельзя сделать, кроме хеша, как ни бейся и как его ни назови.

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

Вот есть молоток. Им можно при желании завернуть шуруп. При сноровке - можно завернуть шуруп быстро. А еще молоток дешевле шуруповерта. Давайте будем всем доказывать, что молоток - идеальный инструмент.

>и что, все поклонники монгодб пишут свои твиттеры? Ну я вот монго использую для биологической БД. Слез с оракла, доволен как слон. В оракле было под 8 _тысяч_ таблиц и JOIN'ы из нескольких сотен. В монго всего-то чуть больше сотни коллекций. Объем кода с десятка мегабайт сократился до одного. Производительность даже увеличилась.

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

Уверен. около 30 серверов, на каждом запущено с десяток воркеров.

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

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

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

>Т.е. один сервер приложений держит порядка сотни подключений к базе? По одному на клиента что-ли? Зачем?

Производительность же. В вебе один фронтед сервер держит пул, скажем в 100 коннекшенов. Таким образом запрос клиента начинает обрабатываться сразу, а не ждет пока база удостоит его аудиенции. Правда из моего опыт пул в сотню потребуется при 8-12 тысячах запросов к фронтенду в секунду. Обычно все же цифры на порядок меньше.

>>Т.е. один сервер приложений держит порядка сотни подключений к базе? По одному на клиента что-ли? Зачем?

Да. Потому что так — просто. Один клиент - один поток (или процесс, я не разработчик), один коннект. Почему? Потому что это просто, и монга позволяет это делать и не изобретать чего-то более сложного.

Просто? А по серверу на клиента - еще проще. Зачем изобретать что-то сложнее?

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

Уверен. около 30 серверов, на каждом запущено с десяток воркеров.

И в чем уверен? 30 серверов с десятком воркеров на каждом = 300 воркеров. Нахрена каждому воркеру по 50 соединений с базой?!

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

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

Для всех случаев, где можно использовать гогноДБ можно то же самое сделать на релационке. Причем так, что бы данные для каждого запроса _всегда_ лежали на одном и том же сервере. Но можно сделать и несколько иначе. Тогда данные будут на нескольких серверах но их будет меньше. Так что все путем. Выбираешь то, что нужно.

>>Т.е. один сервер приложений держит порядка сотни подключений к базе? По одному на клиента что-ли? Зачем?

Производительность же.

И я про то же.

В вебе один фронтед сервер держит пул, скажем в 100 коннекшенов. Таким образом запрос клиента начинает обрабатываться сразу, а не ждет пока база удостоит его аудиенции. Правда из моего опыт пул в сотню потребуется при 8-12 тысячах запросов к фронтенду в секунду. Обычно все же цифры на порядок меньше.

Во-первых, для обработки запроса сразу нужен не «пул из 100 коннектов» а просто хотя бы один свободный коннект.

Во-вторых, нормальный стиль работы с пулом это когда воркеры дергают из него соединения когда надо. Можно еще очередь запросов организовать. Создавать же «пул» лишь затем, чтобы потом каждому клиенту принадлежал свой коннекшт это писец, причем жирный. Ведь не постоянно же запросы от клиента будут идти в базу. Это может быть еще как-то оправдано лишь в одном случае: когда база настолько тормозна, что становится узким местом. Ну тогда следует выкинуть к чертям СУБД. Или смириться, и держать по сотне коннектов на клиент (ага, и можно будет сказать что это круто, ведь гогноДБ «это держит»).

> а если учесть еще, что запрос обрабатывается миллисекунд 20 в среднем, то и выходит 15к запросов в секунду.

Можно подробнее? Если это одна машина, то будет совсем не 15к запросов в секунду. А если кластер, то сколько машин в нем?

>Наверное, мускуль может гордится тем, что заработет на VDS за 5 баксов, и даже кого-то там обгонит.

Честно говоря, я возмущен до глубины души, так что извиняйте за резкость, но это психология вечных голодранцев - тратить 50 баксов (недешовенький VDS) в месяц там, где можно тратить один (тут недавно был спаммер, я смотрел его расценки на шаред хостинг с мусклем).

Я не знаю, где у вас существуют vds за 150 рублей, у меня минимальный за 500р и мускул на нем работает отлично. Джаббер, транспорты, почта, сайты и все такое тоже без проблем.

Наверное, есть «задачи», где экономия 45 баксов в месяц - это очень серьезно.

Будете смеяться, но для 99% задач экономия 45 баксов в месяц очень полезна.

А для доброй половины критически важна. На каждый банковский сервер придется 1000 дневничков, наподобие lleo.me.

>Во-первых, для обработки запроса сразу нужен не «пул из 100 коннектов» а просто хотя бы один свободный коннект.

Ну да, а если этих запросов одновременно сотня, то нужен пул из 100 коннектов, иначе часть будет ждать.

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

Постоянно, на то и веб. Нет запросов, нет и клиента. Стандартная ситуция: на одном фронтенде 2500 запросов в секунду. 95% обслуживаются из кэшей, остальные требуют БД. При среднем одного запроса в 1 секуду, получаем что нам нужно 100 одновременных соединений. Естественно никто не держит открытый коннекшен постоянно. Взяли из пула, дернули базу, вернули в пул.

>Если хочешь - ничто не мешает сделать из SQL базы монгоподобие: просто одна запись будет содержать два значения: ключ и «документ». Не знаю как в myqsl, но в postgresql есть xmlvalue, которого должно более чем хватить. Но можешь действительно разнести данные по таблицам и сэкономить на объеме хранимых данных.

Это итеративный процесс.

1. Создаем нормальную базу. Нагружаем ее, ловим локи.

2. Оптимизируем запросы. Нагрузка растет, ловим локи.

3. Частично денормализуем данные. Нагрузка растет, все равно ловим локи. + резко усложняется логика из за дублирующихся данных.

4. Переходим к системе храненя key,binarydocument,pole_sortirovki1-100,...,pole_poiska1-100,...

Получаем кучу гемора с актуализацией полей из документа в поля для поиска и сортировки.

5. Героически решаем все эти проблемы своей оберткой к sql БД, разрываем паутину связей между записями в таблицах. Получаем возможность репликации, шардинга и более-менее линейного роста производительности, пишем реализующий все это и еще чуть-чуть функционал.

6 Вуаля, мы написали монга-монга!

>>Наверное, есть «задачи», где экономия 45 баксов в месяц - это очень серьезно.

Будете смеяться, но для 99% задач экономия 45 баксов в месяц очень полезна.

Вот-вот. Так нахрена же использовать монго, что по сравнению с нормальными реляционками жрет прорву ресурсов на тех же данных?

А для доброй половины критически важна. На каждый банковский сервер придется 1000 дневничков, наподобие lleo.me.

И каждый из этой тысячи дневничков настолько много в себе хранит, что упирается в эти ваши мифические локи реляционки? :) Банковские сервера посрамлены. Надо было писать иначе: на каждый дневничок наподобие lleo.me приходится по тысяче банковских серверов, где мизерные объемы данных и масштабируемость не нужна.

> Это итеративный процесс.

1. Создаем нормальную базу. Нагружаем ее, ловим локи.

2. Оптимизируем запросы. Нагрузка растет, ловим локи.

3. Частично денормализуем данные. Нагрузка растет, все равно ловим локи. + резко усложняется логика из за дублирующихся данных.

4. Переходим к системе храненя key,binarydocument,pole_sortirovki1-100,...,pole_poiska1-100,...

Получаем кучу гемора с актуализацией полей из документа в поля для поиска и сортировки.

5. Героически решаем все эти проблемы своей оберткой к sql БД, разрываем паутину связей между записями в таблицах. Получаем возможность репликации, шардинга и более-менее линейного роста производительности, пишем реализующий все это и еще чуть-чуть функционал.

6 Вуаля, мы написали монга-монга!

Либо врешь, либо фантазируешь.

Если данные в итоге смогли лечь на гогноДБ, то их можно было изначально моделировать соответствующим образом и держать на шарде с репликацией. Причем не было бы никаких проблем с локами и актуализацией.

П.С. В пункте №4 на нормальных реляционках не нужны спец.поля для сортировки или поиска. Они умеют делать индексы по функциям от записи (в твоем случае, функции от первых двух полей). Причем индексы как правило чудесно работают и для сортировки и для поиска.

> Честно говоря, я возмущен до глубины души, так что извиняйте за резкость, но это психология вечных голодранцев - тратить 50 баксов (недешовенький VDS) в месяц там, где можно тратить один (тут недавно был спаммер, я смотрел его расценки на шаред хостинг с мусклем).

Я три месяца откладывал со школьных завтраков на дорогой сервер, и вправе гордиться результатом! Если хорошо сдам экзамены, родители обещали еще 50 долларов, и я смогу запустить монгу в реплике!!!111!"!11

Ну раз Вы фантазируете, то и я добавлю.

Тот же вариант в случае с монго:

1. Создаем нормальную базу. Ловим тормоза.

2. Увеличиваем число серверов. Платим бабки.

3. Надо сделать новую фичу. Упираемся в то, что нужно атомарно изменить два документа.

4. Применяем рецепт two-phase commit. Число запросов к базе увеличивается раз в пять.

5. Покупаем еще серверов. Было 20 стало 100. Чудно.

6. Замечаем, что two-phase commit не настолько атомарен как обещано, и приложения, что читают данные, иногда делают это неконсистентно.

7. Слить пары документов в отдельные документы невозможно. map/reduce может сделать что-то подобное, но лишь в batch mode а не интерактивно. Чешем башку.

8. Приходит новый руководитель. Увольняет всех. Собирает адекватную комманду и все переписывается с нуля, используя взрослую реляционку. Количество серверов сокращается до четырех: шард из двух активных серверов и пара бекапов.

Как-то так?

>Вот-вот. Так нахрена же использовать монго, что по сравнению с нормальными реляционками жрет прорву ресурсов на тех же данных?

Потому что есть свое множество задач, где реляционки сливают. Нет?

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

Нет, стандалон дневничок вполне живет до поры до времени на sql.

А вот сервис дневничков уже нет.

Банковские сервера посрамлены. Надо было писать иначе: на каждый дневничок наподобие lleo.me приходится по тысяче банковских серверов, где мизерные объемы данных и масштабируемость не нужна.

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

Что касается важности потребностей, то банк москвы со своим банк-клиентом целыми днями валяется и ничо...

>Если данные в итоге смогли лечь на гогноДБ, то их можно было изначально моделировать соответствующим образом и держать на шарде с репликацией

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

Для это нормалтзацию данных в sql и придумали.

П.С. В пункте №4 на нормальных реляционках не нужны спец.поля для сортировки или поиска. Они умеют делать индексы по функциям от записи (в твоем случае, функции от первых двух полей). Причем индексы как правило чудесно работают и для сортировки и для поиска.

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

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

> Банковские сервачки действительно перерабатывают относительно небольшие объемы информации и имеют хорошие возможности для экстенсивного роста за счет смены оборудования. Миллион параллельных запросов? Для _платной_ службы банка это фантастика, а для _бесплатной_ соц. сети - мертвый сезон.

Готов поверить, что у фейсбука миллион или более параллельных запросов. Но это фейсбук. И у них есть свой софт для таких вещей.

А остальные могут не волноваться. Едиственная для них причина думать о масштабируемости - неправильный масштаб кое-чего совсем из другой области. Но вынужден огорчить: монго это не исправляет и реляционки не виноваты. %)

>>Если данные в итоге смогли лечь на гогноДБ, то их можно было изначально моделировать соответствующим образом и держать на шарде с репликацией

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

Есть такие люди, которые этим страдают. Есть и другая болезнь: желание скинуть все в одну кучу.

Для это нормалтзацию данных в sql и придумали.

П.С. В пункте №4 на нормальных реляционках не нужны спец.поля для сортировки или поиска. Они умеют делать индексы по функциям от записи (в твоем случае, функции от первых двух полей). Причем индексы как правило чудесно работают и для сортировки и для поиска.

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

Ага, щас. Вы как-то монгоцентрично смотрите на мир.

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

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

>1. Создаем нормальную базу. Ловим тормоза.

или сразу или никогда. Ведь в nosql нет нелинейных тормозов.

2. Увеличиваем число серверов. Платим бабки.

Это лучше, чем иметь деньги и... увеличить кол-во сервреов нельзя. Бесполезно.

3. Надо сделать новую фичу. Упираемся в то, что нужно атомарно изменить два документа.

Формируем очередь.

4. Применяем рецепт two-phase commit. Число запросов к базе увеличивается раз в пять.

Тоже вариант. Но запросы легкие, не блокирующие.

6. Замечаем, что two-phase commit не настолько атомарен как обещано, и приложения, что читают данные, иногда делают это неконсистентно.

ерунда. лечите руки.

8. Приходит новый руководитель. Увольняет всех. Собирает адекватную комманду и все переписывается с нуля, используя взрослую реляционку. Количество серверов сокращается до четырех: шард из двух активных серверов и пара бекапов.

Клиенты уходят туда, куда ушла предыдущая команда, потому что им пофигу, что стало четыре сервера. Им надо, чтобы сервис работал. А он на десятке коннектов уже в вечном локе.

>>3. Надо сделать новую фичу. Упираемся в то, что нужно атомарно изменить два документа.

Формируем очередь.

Это такая странная шутка? :) Как именно при помощи очереди Вы намереваетесь атомарно менять пары (группы в общем случае) документов. И как Вы собираетесь это масштабировать?

4. Применяем рецепт two-phase commit. Число запросов к базе увеличивается раз в пять.

Тоже вариант. Но запросы легкие, не блокирующие.

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

6. Замечаем, что two-phase commit не настолько атомарен как обещано, и приложения, что читают данные, иногда делают это неконсистентно.

ерунда. лечите руки.

Правда, что ли? :)

8. Приходит новый руководитель. Увольняет всех. Собирает адекватную комманду и все переписывается с нуля, используя взрослую реляционку. Количество серверов сокращается до четырех: шард из двух активных серверов и пара бекапов.

Клиенты уходят туда, куда ушла предыдущая команда, потому что им пофигу, что стало четыре сервера. Им надо, чтобы сервис работал. А он на десятке коннектов уже в вечном локе.

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

> В оракле было под 8 _тысяч_ таблиц и JOIN'ы из нескольких сотен.

Мне кажется, что где-то там у вас живет настолько хреновый проектировщик, что даже смерть для него была бы слишком хороша. 8 тысяч таблиц, это же треш и адов угар.

>Есть такие люди, которые этим страдают. Есть и другая болезнь: желание скинуть все в одну кучу.

да это нормально. нормализовали данные при записи и собрали при чтении. Это теория реляционной БД. Как можно хвалить реляционки и отрицать их базис?

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

Ага, щас. Вы как-то монгоцентрично смотрите на мир.

Это факт. В чистых реляционных БД смотреть внутрь поля некошерно.

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

На здоровье. Но имхо ограничивать себя сферическими «нормальными» SQL в количестве один штук, это вообще чистой воды сектанство.

>Фантазируйте дальше. Локов нет, одновременных активных коннектов - тысячи на сервер.

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

>>Фантазируйте дальше. Локов нет, одновременных активных коннектов - тысячи на сервер.

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

Да ну? И сколько же вы ожидаене на нагруженной системе?

>>Есть такие люди, которые этим страдают. Есть и другая болезнь: желание скинуть все в одну кучу.

да это нормально. нормализовали данные при записи и собрали при чтении. Это теория реляционной БД. Как можно хвалить реляционки и отрицать их базис?

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

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

Ну как минимум, это одно из того, что я имею в виду. Слон более универсален чем монго и написан более адекватными людьми. А оракл еще более фичаст чем слон.

Ага, щас. Вы как-то монгоцентрично смотрите на мир.

Это факт. В чистых реляционных БД смотреть внутрь поля некошерно.

«Кошерный» значит «одобряемый с точки зрения Галахи». В Галахе утверждается что-либо про реляционные базы?

И вообще-то я не вижу причин нелюбить функции, в том числе в контексте индексов.

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

На здоровье. Но имхо ограничивать себя сферическими «нормальными» SQL в количестве один штук, это вообще чистой воды сектанство.

Может кто так и делает. Я - нет. Что до ограничения себя СУБД в количестве один штук (монго), то это вообще «Белое Братство» какое-то.

>Может кто так и делает. Я - нет. Что до ограничения себя СУБД в количестве один штук (монго), то это вообще «Белое Братство» какое-то.

Ни в коем случае. Монга не является заменой всем СУБД.

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

Никак не что-нибудь одно.

>Да ну? И сколько же вы ожидаене на нагруженной системе?

В заивисмости от тяжести запросов, десятки-сотни тысячЪ. Иначе вполне можно обойтись и sql.

Хотя sql можно положить и десятком. Была бы фантазия...

>>Да ну? И сколько же вы ожидаене на нагруженной системе?

В заивисмости от тяжести запросов, десятки-сотни тысячЪ. Иначе вполне можно обойтись и sql.

Десятки-сотни тысяч _активных_ коннектов к _одной_ базе? Это типа круто? Вы в курсе, что двигаясь по такому пути можно упереться просто в ограничения ОС? И что реально эти коннекты все равно разгребаются не одновременно (все же процессоров в одной машинке отнюдь не тысячи). И нет, монго тут тоже не будет блистать. На этой поляне она будет отнюдь не лучше смотреться. А с тем убогим подходом, что данные храняться безобразно и неэкономично, монга ляжет брюхом на обращении к дискам.

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

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