Весело тут у вас :)

По идее, должен быть отличный базовый движок для СУБД на основе EXPRESS-X типа EDM. К сожалению, слой абстракции EXPRESS (а это как раз графовое представление) без движка пока никто не соорудил.

Спасибо за советы, но они мимо кассы. Утверждать, что NoSQL необязательно должна быть без поддержки SQL - всё равно, что говорить, что у корабля необязательно не должно быть гусениц. А ведь и правда - можно приделать. И даже плавать оно хуже после этого станет не сильно...

Я думаю авторы имели ввиду нечто типа «Поддержка транзакций в полном соответствии с ACID.» Хотя не совсем ясно как требование согласованности уживается с NoSQL где согласованность как правило приносится в жертву.

Что такое NoSQL

NoSQL это сейчас всё же Not Only SQL.

Тема в том, что NoSQL сейчас быстро эволюционируют - это не просто хранилища ключ-значения. Это хранилища, специализированные под какой-то вид нагрузки и/или тип данных. SQL там если и есть, то не является основным способом работы с данными.

вы меня простите, я в сортах этих трендов слабо разбираюсь, но ваш пруфик ничего не потверждает. Есть NoSQL, его все понимают как базы без SQL, а попытка заявить что они стали Not Only SQL - это называется «сделать хорошую мину при плохой игре». Я не против, но давайте не будет спекулировать терминами.

его все понимают как базы без SQL

Не все. Сообщество заявляет, что они теперь понимают в смысле «не только SQL», хотя тема всё еще спорная.

Будет пруф на повсевместность такой трактовки

http://www.acronymfinder.com/Not-Only-Structured-Query-Language-(computer-pro...

http://newtech.about.com/od/databasemanagement/a/Nosql.htm

А где собственно он расшифорвывается по-другому?

его все понимают как базы без SQL

Все - это кто?

а попытка заявить что они стали Not Only SQL - это называется «сделать хорошую мину при плохой игре»

А что за плохая игра, не подскажете?

А где собственно он расшифорвывается по-другому?

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

Тут ведь еще вот какой вопрос встает: Не только SQL это што? Что там кроме SQL имеет место быть? Т.е. есть что либо такое в таких базах что выходит за рамки SQL и им не покрывается и остается ли оно нужным, если база поддерживает SQL?

что выходит за рамки SQL

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

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

И где там именно говорится что это аббривиатура расшифорвывается как «Not SQL»?

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

Дело не в том, что SQL что-то не позволяет делать. Просто не всегда он нужен, поэтому от него избавились как от класса. За счет чего укоротили путь данным. Я имею в виду K/V-хранилища.

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

Ну и наконец, кто-то предпочитает специализированные языки запросов. Типа субжа, который использует язык графовый язык Gremlin, или XML-хранилищ.

Все - это сообщество людей, работающих в этой области. Сужу по общению с ними.

Если вам такие слова как Percona, PostgreSQL, МТС, mail.ru чего-нибудь скажут - то в этих коммьюнити люди понимают NoSQL именно так (сужу по личному общению с ними).

Плохая игра называется «у нас нету денег на нормального DBA, потому мы напишем ещё одно NoSQL хранилище, чтобы трахаться с проблемами производительностями на своём любимом языке программирования». Баловство, другими словами.

Сабж (OrientDB) выглядит иначе, но он как бы и SQL поддерживает (в каком объёме - вопрос по-прежнему актуален). Ещё одно исключение - Handler Socket. Он позволяет напрямую с InnoDB работать.

Такого сорта NoSQL мне скорей нравятся, чем нет. Но вот ни один «чистых» NoSQL - не нравится совсем.

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

Только в реальности NoSQL берутся, когда людям хочется поиграть в «напиши своё хранилище и расскажи всем про это на конференциях» либо когда жмотят бабки на DBA.

Это 90% использований, если не больше. Исключения есть - превентивно соглашаюсь. Но на то они и исключения

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

Эти самые «некоторые» придумали себе MapReduce исходя совершенно из иных соображений и поимело это отношение к понятию из функциональщине почти случайно. К СУБД, кстати, это тоже не имеет никакого отношения.

Ребят, не ссорьтесь! Термин NoSQL придумал КРЕТИН! Это всё равно, что назвать девушку «сука» и краснея, оправдываться, что это аббревиатура «симпатичная, умная, красивая-ажжуть». :) Ну неудачно они приставили своё «No» - пусть сами и хлебают своё говно. Такие СУБД можно просто называть «хранилище документов».

Ну, факт в том, что мы сейчас имеем куда больше различных способов организации хранения и обработки данных, чем лет 5-7 назад. Это хорошо, я считаю.

А остальное - это тернистые пути эволюции технологий. :)

Такие СУБД можно просто называть «хранилище документов».

как показывает практика реализации таких хранилищ - авторы сами не понимают что за хранилище они пытаются сделать. Есть обычно только сопли, типа мы уберём X... Y и всё будет летать и рай настанет на земле.

Вы меня не совсем правильно поняли, хотя и в нужном направлении. Если бы у Redis например была поддержка SQL, то практически весь остальной API можно было бы выкинуть (я не говорю сейчас о служебных командах естественно), за исключением разве что команд работающих с волатильными ключами. Вы можете вспомнить подписки, но давайте говорить на прямоту - это не задача БД. Ее прикрутили поверх основного функционала Redis шобы было. Хотя получилось неплохо - кто же спорит. Да и те же волатильные ключи можно реализовать с помощью тригеров. Не?

Ну так и я о том же! Дело не в том, что NoSQL какие-то совсем другие - просто там выпилин и принесен в жертву производительности. Ничто не мешает написать прослойку реализующую SQL поверх того же Redis (раз уж его уже упомянули). Но зачем? И нужен ли тогда другой функционал если уже прикрутили SQL?

Не, есть вполне себе понимающие. Кто пытается создать структуры данных для внешней памяти, оптимизированные под специфическую нагрузку. У них, действительно, летает. Хоть и не всё, и не всегда. Пример - acunu.com.

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

И нужен ли тогда другой функционал если уже прикрутили SQL?

В той области, в которой используется Redis - нет. Там SQL не создает заметного оверхеда.

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

NoSQL в узком смысле именно, что совсем другие. Они очень сильно специализированы под узкий класс задач. И вне этого класса не эффективны, мягко говоря.

«у нас нету денег на нормального DBA, потому мы напишем ещё одно NoSQL хранилище, чтобы трахаться с проблемами производительностями на своём любимом языке программирования»

Это фраза звучит не лучше чем что С++ универсальный язык и нечего со всякими эрлангами и прочими не С-стайл языками соваться. Есть много разных файловых систем. Есть много разных языков программирования. Есть даже много разных операционных систем. И вот внезапно в БД нашли святую корову на которую молятся со словами «нет нормального DBA». Это у гугла нет денег на нормального DBA? Может у mail.ru нет денег на нормального DBA? Или у вконтактика нет денег на нормального DBA? Смешные вы.

Но вот ни один «чистых» NoSQL - не нравится совсем.

Может ваши задачи идеально ложаться на SQL решения. А у меня есть ряд в котором Redis - быстрее и проще. А есть в котором удобнее Mongo.

Если бы у Redis например была поддержка SQL

Если в редис добавить SQL то получится MySQL, а он уже есть. Ненене, мне удобно работать в терминах KV, и использовать атомарные INCR, MGET, MSET, EXPIRE

Да и те же волатильные ключи можно реализовать с помощью тригеров.

Какие-какие? Если вы про expiration, то теоретически можно, только это сложно будет и медленно - операция удаления в SQL базах относительно медленная.

Еще раз, можно реализовать интерфейс Redis поверх SQL (если в задаче нужен именно такой интерфейс), но Redis реализует при этом большую производительность. И выбираю Redis я в первую очередь из-за интерфейса - он мне удобен именно такой. Redis выполняет узкий круг задач и выполняет его хорошо, не трогайте его пожалуйста.

но давайте говорить на прямоту - это не задача БД

Тут можно спорить - подписки похожи на короткоживущие очереди :)

Я ратую за Not Only SQL как термин потому что No-SQL выглядит для многих как «альтернатива SQL», в то время как NoSQL решения зачастую используются именно как _дополнение_, что и подчеркивает данная расшифровка. Кстати, Мартин Фаулер таки за расшифровку No SQL, обидно :(

Вы специльно проигнорировали мою комментарий про исключения? Я её вам повторю

Это 90% использований, если не больше. Исключения есть - превентивно соглашаюсь. Но на то они и исключения

Теперь по вашим словам

Это у гугла нет денег на нормального DBA? Может у mail.ru нет денег на нормального DBA? Или у вконтактика нет денег на нормального DBA? Смешные вы.

Вы гугль? Вы вконтакте? Вы mail.ru?

Когда у вас парк серверов несколько тысяч машин - тогда нужно думать про оптимизацию. А сейчас я вас сильно огорчю. Facebook работает на MySQL (точнее, на сборной солянке из ваниллы, патчей из Percona, MariaDB и собственных). Такая компания как Right Now Technology - тоже.

В mail.ru достаточно широко используется Oracle и MySQL, по моей информации от инсайдеров. Yota игралась с NoSQL но в итоге работает на Oracle Timesten. МТС - это Oracle.

Google Big Data - хороший пример исключения. Хранить массу документов типа писем и поддерживать связи между ними - для такого SQL действительно мало подходит.

Может ваши задачи идеально ложаться на SQL решения. А у меня есть ряд в котором Redis - быстрее и проще. А есть в котором удобнее Mongo.

Я поверю про «проще написать». Я сомневаюсь в «проще поддерживать». Я сомневаюсь в «быстрее работает». Точнее, я не сомневаюсь что на небольшой нагрузке так оно может быть. Но тут point не «быстрее», тут point «компании дешевле обходится вашими силами, а вам проще redis» и «нагрузки нет, потому вообще всё равно что именно там работает».

Как только ваша нагрузка хотя бы приблизиться по порядку к нагрузкам гигантов вы будете сильно плакать, и, скорей всего, мигрировать на SQL. Потому что ВНЕЗАПНО он окажется дешевле.

Тот же Facebook играет в патчи на MySQL потому, что дешевле. А про fail с Кассандрой и dig.com нужно напоминать?

В общем, чего это я тут бисер мечу...

Если в редис добавить SQL то получится MySQL, а он уже есть. Ненене, мне удобно работать в терминах KV, и использовать атомарные INCR, MGET, MSET, EXPIRE

Скажите, а почему вы не взяли Handler Socket? Вот вам сразу и MySQL, и KV-storage (который, между прочим, по производительности заруливает не только MySQL/PostgreSQL в несколько раз/порядок, но и все NoSQL).

Почему вы отказались от очевидно лучшего, чем Redis, решения?

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

Ровно как я написал выше. Не надо разводить демагогию про производительно, не в ней дело.

Скажите, а почему вы не взяли Handler Socket? Вот вам сразу и MySQL, и KV-storage (который, между прочим, по производительности заруливает не только MySQL/PostgreSQL в несколько раз/порядок, но и все NoSQL).

Вы имеете в виду это? Нет, все не заруливает. По крайней мере как утверждают авторы.

Идея Handler Socket позволит расширить зону применения MySQL, но есть другая тенденция. Мы уже прошли миллисекундную латентность доступа к (персистентным, транзакционным, бла-бла-бла) данным. И даже уже преодолели микросекундный рубеж, успешно осваиваем наносекундный. Это требует новых, ультра-легковесных интерфейсов работы с данными и SQL здесь выглядит глобальным и надежным... динозавром.

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

И тут у традиционных монолитных SQL-серверов просто архитектура не подходящая. Пока команды будут разогреваться и соображать, ребята из NoSQL начнут выкатывать готовые решения. Это примерно как Clang против GCC. Gcc глобален и надежен, но CLang более пассионарен.

Не надо разводить демагогию про производительно, не в ней дело.

Тем не менее, она так же является фактором при выбре. Для меня лично не столько критичным, но для других товарищей (типа youporn ;) думаю решающий фактор.

Почему вы отказались от очевидно лучшего, чем Redis

Почему лучшего? Я очень активно полагаюсь на expiration - зачем мне его реализовывать поверх MySQL? Мне очень удобна семантика операции incr в Redis - зачем мне его реализовывать самому?

Если кто-то реализует интерфейс Redis поверх MySQL так, что он будет не менее производителен - да пожалуйста, я буду только за. Но по-факту такого вроде не предвитися.

Redis у меня идет как дополнение к MySQL, я не заменяю его.

они ее сперва на c++ писали, потом взяли яву

Не надо разводить демагогию про производительно, не в ней дело.

Кстати, внезапно, но я про не разводил про нее демагогию, это вы везде ищете происки госдепа. Про скорость я написал лишь «зачастую» и поставил ее на второе место.

Блин, а зачем?

Если кто-то реализует интерфейс Redis поверх MySQL

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

Может потому, что Redis дает очень удобный API и поддерживает волатильные ключи (мегоудобно для сессий)? А пользователи многих ЯП найдут там структуры данных очень похожие на структуры своих языков, что безусловно удобно для хранения таких данных.

И да - не дадите ссылку на Handler Socket клиент для Tcl, а то у мну ни одной строчки PHP в проекте?

этом случае проще реализовать SQL поверх Redis.

Вы так и не сказали, зачем вы так рветесь реализовать SQL поверх редиса.

Разве я рвусь? Я вообще им (SQL) толком пользоваться не умею и не люблю.

у него простой текстовый прокол. Делайте как хотите, что хотите. Как и memcache, тащем-то

я не понимаю как это отношение имеет к производительности и надёжности, что требуется от хранилища данных в первую очередь

вы можете объяснить зачем вебу нужны микросекундные отклики?

в пределах 10-100 миллисекунд пользователь вообще не заметит разницы. гонка за наносекундами напоминает гонку ради гонки.

вы можете объяснить зачем вебу нужны микросекундные отклики?

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

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

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

Никакого. Просто если от БД требуется только производителность и надежность, то самой крутой будет print на C. А че - быстро вернуть переденные данные оно может, надежно как ничто иное... Жалко бессмысленно совершенно. Надо помнить, что от БД требуется НЕ ТОЛЬКО производительность и надежность.

По идее, должен быть отличный базовый движок для СУБД

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

Надо помнить, что от БД требуется НЕ ТОЛЬКО производительность и надежность.

заинтриговал...

Некоторая часть пользователей еще ждет от БД например возможности хранения данных и их обработки. Маргиналы конечно, но их мнение тоже стоит учитывать.

многопоточность и масштабируемость на скок понял

Некоторая часть пользователей еще ждет от БД например возможности хранения данных

Внезапно. А как можно пользоваться базой данных, если в ней нельзя хранить данные?

и их обработки

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

Да - я вижу, что для многих это Внезапно...

Насчет обработки я имел ввиду лишь поиск да сортировку.