Кому можно рекомендовать ББ - в текущем состоянии!

[ilovb]

2 Илья
Вы кстати сами себе противоречите. Обычно защищаете формальное построение системы, а тут конкретная технология.

В реляционных СУБД главное слово "реляционные". Т.е. конкретная математическая концепция.

А NoSQL - это технология. И более того эта технология для других задач предназначена.

[Илья Ермаков]

Ну, по поводу проблемы "нерегулярной изменчивой структуры данных" моё мнение можно узнать в двух моих статьях:
http://objectsystems.ru/files/Object_Systems_2011_Proceedings.pdf
Ермаков И.Е. XML-СУБД как возможная основа для объектных технологий ИС. Технология MULTYF

http://objectsystems.ru/files/2011WS/Object_Systems_2011_Winter_Session_Proceedings.pdf
Ермаков И. Е. Применение XML-СУБД в задачах автоматизации бизнеса.

Я не горячий сторонник XML-СУБД, но использовал их из реальной необходимости поиска альтернативы традиционным реляционкам. В статьях как раз рассмотрен сей тернистый путь... "поиска альтернативы"

По поводу масштабируемости - ну, я не знаю, Вы в теме hi-load, следите за этой темой? Сейчас материалов море.

Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.

[Илья Ермаков]

2 Илья
Вы кстати сами себе противоречите. Обычно защищаете формальное построение системы, а тут конкретная технология.

Грешен, не раз уже в данной дискуссии употребляю термины в "интуитивном", а не в точном смысле

В реляционных СУБД главное слово "реляционные". Т.е. конкретная математическая концепция.
А NoSQL - это технология. И более того эта технология для других задач предназначена.

Но эта математическая концепция воплощена в конкретных технологиях. И все реализации обладают неким общим подмножеством свойств и недостатков.
Я же не говорил про реляционную МОДЕЛЬ ДАННЫХ. А именно про РСУБД. Что есть класс технологий, а не математическая концепция.

[Илья Ермаков]

Расскажите IBM, о том что DB/2 не масштабируется, не адаптируется к высокой нагрузке и т.п.

Угу, ещё давайте рассмотрим DB/2 на базе As/400... Это не мейнстрим, друзья мои Это как раз интересное альтернативное решение. Правда, очень дорогое.

И нагрузка в Enterprise и нагрузка в онлайн-сервисах - это две большие разницы.
Я не уверен, что оно выдержит то, что держат BigTable, Tarantool и проч.

[Илья Ермаков]

Короче: ключевая моя мысль в том, что 1) у меня всегда было ощущение, имеющиеся на рынке "обычные" СУБД (независимо от их частных отличий) спроектированы без учёта "принципа Калашникова", содержат много "мусора", посему целесообразно выбирать какие-то альтернативные им варианты и 2) что ход развития событий подтверждает это моё ощущение из п. 1.

[ilovb]

По поводу масштабируемости - ну, я не знаю, Вы в теме hi-load, следите за этой темой? Сейчас материалов море.

Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.

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

[valexey_u]

При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)

По объективным причинам (усложнять дальше некуда) анти-мейнстрим становится мейнстримом
Сейчас любить NoSQL модно, но года 4 назад расскажи я кому-нибудь тут, что так оно и будет, меня бы закидали чем-нибудь

Да это все суета сует. Все же просто. 10 лет назад начался бум веб-сайтов как всяких интернет-магазинов, так и просто хомячков да форумов. Появились хостинги для подобные проектов. Вопрос - где хранить данные и как с ними работать? (настройки там, сообщения форумов, прочий контент) В файлах? Сложно, не надежно. И вообще писать медленно. SQL тут самое оно, ибо просто и гибко. А SQL-субд отлично окучивала за раз сотни таких сайтов одновременно. Там выбор оправдан был.

А потом что? Потом таких товарищей, которые имеют опыт создания сайтов, стало очень много. И не все они продолжали сидеть и клепать исключительно веб, то есть это стало проникать и на десктоп и даже мобилки. Вот такой товарищ написал 10 сайтов, и хочет например написать теперь десктопную игрушку "крестики-нолики". В ней ему нужно хранить где-то настройки и top 10 игроков. Думаешь он будет заморачиваться с файликами? Конечно нет. Он возьмет SQL (sqlite в лучшем случае, но может и MySql поднять) и будет работать как привык. Ему эти буковки уже знакомы и не требуется ломать голову над чем-то новым. Просто сел, написал.

Дело дошло до того, что СУБД стали встраивать с телефоны (скажем в симбиане оно есть).

Вот и все причины популярности SQL-DBMS. Причем кто писал десктоп приложения без sql, те так и пишут. Для хранения данных обычно своя балалайка не выделенная в СУБД. Это как бы даже не NoSQL, это NoDBMS. Да и некоторые серверные приложения тоже.

[valexey_u]

Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.

Эмм.. Не факт :-) Во-первых основная фича SQL-DBMS'ов в том, что оно крайне гибкое. Если изменилась структура данных, нужно как-то иначе их вытаскивать и обрабатывать, то это сделать можно достаточно быстро. То есть прежде всего SQL дает удобстно. Скорость там всегда была вторичной.

Для скорости есть OLAP.

А вот проблемы с масштабированием лежит в самой реляционной модели данных - реляционка нормально в принципе не масштабируется. И вот поэтому NoSQL.

И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).

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

[Madzi]

Чтобы не быть голословным, скажу только из личного опыта. В одной автоматизированной системе межрегионального масштаба, "нутро" которой я знаю (это платформа из серии "электронная школа", муниципальные услуги и проч., которая используется в неск. регионах) проверка прав пользователей на выполнение той или другой операции, выполняемая на базе PostgreSQL, стала основным стопором производительности. Пришлось всё, что касается пользователей, сессий, аутентификации, ролей, проверки прав на операцию, перенести на MongoDB.
Язык - Java, Play! Framework.

Play вообще не фонтан. Очень медленная технология. Spring будет на порядок производительнее (если не на два порядка). К тому же, для повышения производительности, можно было использовать iBatis.
Кстати, тоже знаю систему регионального масштаба из серии "электронная школа", но она ещё не внедрена. И тоже на Play

[valexey_u]

Я, может быть, отбрасываю ряд нюансов, деталей, выражая своё ощущение главной тенденции...
Когда никто даже помыслить не может "жить без СУБД", а ты делаешь "No-СУБД"-решения, просто потому, что не хочешь вляпываться в избыточную сложность чужих СУБД, а потом тройку лет спустя все носятся с воплями "No-SQL, No-SQL", то, наверное, ощущение моё не совсем беспочвенное, а?

NoDBMS != NoSQL же. NoSQL всегда (во всех контекстах упоминаемых) подразумевает наличие СУБД.

NoDBMS это банально, избито и применяется дофига где. Это мейнстрим :-)

PS. Даже БЛОКНОТ использует NoDBMS! Да что там, даже мой hello world :-)

[valexey_u]

И нагрузка в Enterprise и нагрузка в онлайн-сервисах - это две большие разницы.

Да нет. Это примерно одна и та же разница :-) Ынтырпрайз он знаешь ли тоже большой и энергичный бывает, не менее энергичный чем скажем пользователи вконтактика.

Например потому, что ни SQL ни NoSQL которые лепятся для онлайн сервисом не справлялись с ынтырпрайз нагрузкой, была буквально в этом году допилена новая СУБД - HANA. Вот она как раз ынтырпрайзные нагрузки держит и правильно обрабатывает.

[DIzer]

Для скорости есть OLAP.

ну мля - OLAP.а только здесь для скорости не хватало.....

[Илья Ермаков]

А лекции про БД на lectorium.tv от мужичка из Яндекса посмотреть стоит
Как раз стержневая нить в том, что к каждому занятию обучающимся предлагается сделать какой-либо механизм - и в итоге они убеждаются (и лектор подчёркивает и убеждает) в том, что всё это реально сделать своими руками, при этом в "боевом" варианте - все современные штуки из мира СУБД. Реально послать нах Ораклы и проч., и сделать просто и эффективно.

P.S. Только прошу не думать, что я сужу по конкретной лекции. Они просто подтвердили все мои убеждения... А уж темой СУБД я интересуюсь с 2004-го года.
У меня даже интерес к Оберонам появился именно под соусом "а какой простой язык можно легко встроить в свою СУБД"

[valexey_u]

А лекции про БД на lectorium.tv от мужичка из Яндекса посмотреть стоит
Как раз стержневая нить в том, что к каждому занятию обучающимся предлагается сделать какой-либо механизм - и в итоге они убеждаются (и лектор подчёркивает и убеждает) в том, что всё это реально сделать своими руками, при этом в "боевом" варианте - все современные штуки из мира СУБД. Реально послать нах Ораклы и проч., и сделать просто и эффективно.

При условии что на это время есть и ресурсы (квалифицированные работники). А не как обычно - вот тебе два phpшника и один jsQueriст, и нужно сделать мегауберштуку. Срок - вчера. Финансирование - на две недели максимум.

[Илья Ермаков]

Возвращаясь к теме "зачем ББ".

Вот сейчас запустил Скайп, которым пользуюсь не очень часто, и опять полчаса искал в дебильном пиктограммном интерфейсе пункт, добавляющий новый контакт.
И сразу представляется документ с командерами и параметрами....
AddContact.... Connect.... Call...
Мячта.