А что именно тебе не понятно???

> Например какие?

Да многие, которые берет на себя БД.

Речь идет о способе хранения данных а не о БД-специфичных фичах, они то как раз останутся. Просто исчезнет еще одна прослойка.

Т.е. по-вашему СУБД — рудимент и нигде не используется?

> А что именно тебе не понятно???

Ага, три вопросительных знака. Спалился, старшеклассник.

Вообще уже пора использовать базы данных на основе файловой системы.

К. О. напоминает, что файловая система - это и есть самая настоящая база данных. Сама по себе, без надстроек.

Чучело, твиттер давно не на руби artima.com/scalazine/articles/twitter_on_scala.html

ДА, точно, ты меня поймал. ;) Так и что ж именно не понятно, я так и не увидел.

>> К. О. напоминает, что файловая система - это и есть самая настоящая база данных. Сама по себе, без надстроек.

Я это и пытаюсь объяснить некоторым людям, но они упорно не хотят понимать. :(

Ололо. Можно подумать клиент сразу обращается к БД минуя сервер.

Дбазе, скулите ? Не оно ?

Хотя мне очень понравилось сравнение про «масленицу»
но вот постановка задачи и выводы не такие :)

Типа нужно было так -
кто из нас быстрее на дерево залезет ?
А теперь пусть держит моего коня :))))

P.S. А вообще к примеру страус тот под 70км-ч бежит .... :)

В общем плане так и есть. ФС - иерархическая система, а «скуль» - линейная.

> ФС - иерархическая система, а «скуль» - линейная.

Реляционная.

Как я люблю читать аналитиков с лора. Каждый пост отдает глубоким интеллектом, профессиАНАЛизмом, многолетним опытом работы, перед которым все известные специалисты мирового класса меркнут, жалко что наши аналитики слишком круты и независимы, и не хотят изменить мир - пойдя работать в гугл, ms, ibm, intel, nvidia, amd, hp и проч. Или вот хотя бы в тот же твиттер, что бы наконец уже научить тамошнее быдло использовать правильные инструменты и писать правильные алгоритмы !!

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

Кто реляционная?

MySQL, PostgreSQL, Oracle, Firebird, mSQL и.т.д. - Реляционные.

Ганс - ты не прав!

На том уровне, на котором ФС - иерархическая, SQL - реляционная.

Мда? Может я чего-то не понимаю, с удовольствием послушаю объяснения каким образом 2D-таблица реляционная?

В дополнение.

И каким образом СУБД без базы (совокупности связанных таблиц) становится реляционной?

Ну так ещё положить ключи от квартиры в доступное место и рассказать о нём. Кто заставляет?)

Хм. А каим образом файловая система иерархическая? ;) Или вы думаете, что директории на физ. уровне - это такие карманы для файлов, нашитые на диск?

> И каким образом СУБД без базы (совокупности связанных таблиц) становится реляционной?

То есть, без базы она мистическим образом приобретает свойство «линейности»? Линейности чего тогда?

а кто-то не так давно пытался сделать обратное - засунуть файловую систему в базу :-)

Так, придется вспоминать то чему учили в универе.
В кратце, взято с википедии:

Реляционная база данных — база данных, основанная на реляционной модели данных.
Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, _управляющая реляционными базами_ данных.

Из этого видим что РСУБД это всего лишь механизм, Реляционная модель используется только в самой _базе данных_, прошу не путать с РСУБД.

Классическая файловая система имеет иерархическую структуру, в которой файл однозначно определяется полным путем к нему. Взято с www.intuit.ru.

Вопросы в студию :)

> Реляционная модель используется только в самой _базе данных_, прошу не путать с РСУБД.

Ну так и не путайте. Кто сравнил ФС с СУБД (как выясняется) по «линейности»? Я предположил, что вы подразумевали СУБД+ БД, а уже если у вас СУБД это только система, то ваш исходный тезис из серии «чем ворон похож на письменный стол».

>Классическая файловая система имеет иерархическую структуру

s/имеет/может иметь/, историю не забываем.

А ЧЕМ???

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

С СУБД никто не сравнивал, я просто продолжил стиль написания.

Думаю это не суть важно.

> БД появились когда ФС были не лучше всяких FATов, для компенсации недостатков тогдашних ФС.

Но сечас времена изменились и ФС существенно выигрывают у БД в производительности.

с фигали? сделай мне join 5-6 табличек или что там у вас в Файловой-БД? будет ли это быстрее того же Оракл на row партициях?

Понабежало... умников. БД и ФС выполняют очень разные задачи. Хотя частично и пересекающиеся.

>Но сечас времена изменились и ФС существенно выигрывают у БД в производительности.

Как только появятся доступные и работоспособные DBFS - так сразу! :)

> Это ничего не доказывает. Сам посчитай, какая схема быстрее: клиент-сервер-фс-база или клиент-база ?

сервер вы никуда не денете... а ФС это необязательный слой для бОльшинства СУБД. Только MS SQL не может жить без ФС... хотя давно с ним не работал - может опять вернули эту фичу.

> А почему не рассматривался кластер серверов под управлением какого-то там Оракла к примеру, он бы справился с нагрузкой бы.

Оракли очень сложно кластеризуются и очень дорого.

>напоминает, что файловая система - это и есть самая настоящая база данных

Ну да, и даже /etc/passwd - тоже база данных :)

...

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

> К. О. напоминает, что файловая система - это и есть самая настоящая база данных. Сама по себе, без надстроек.

КО наивно забывает про транзакции на изменение данных (а не только метаданных) и уровни изоляции, консистентность на чтение (MVCC) и репликацию. + SQL язык запросов + триггеры и хранимки.

>> К. О. напоминает, что файловая система - это и есть самая настоящая база данных. Сама по себе, без надстроек.

Я это и пытаюсь объяснить некоторым людям, но они упорно не хотят понимать. :(

жаль, что «стандартных» возможностей СУБД у ФС тупо нет. только если ZFS хитро хакать... но ХЗ насколько быстрые снапшоты у нее.

> Мда? Может я чего-то не понимаю, с удовольствием послушаю объяснения каким образом 2D-таблица реляционная?

что есть 2D таблица? КО в растерянности?

Есть РТ и РМ (реляционная теория и модель соответственно). Так вот СУБД это реализация реляционной теории с дополнительными костыликами для ускорения работы.

СУБД это совокупность «табличного» представления данных. Таблицы не обязательно связаны.

>> сервер вы никуда не денете...

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

>> что есть 2D таблица?

Имею ввиду обычную таблиц - двумерную матрицу.

>> СУБД это совокупность «табличного» представления данных.

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

Так вот СУБД это реализация реляционной теории с дополнительными костыликами для ускорения работы.

Об этом я знаю.

Таблицы не обязательно связаны.

Необязательно, но в практике связаны.

>> сервер вы никуда не денете...

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

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

>> СУБД это совокупность «табличного» представления данных.

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

в общем то да... только команды - это операции над множествами. а сами множества описаны РТ.

По сути СУБД - это движок для операций над множествами. А способ хранения - ФС или raw или кластерный движок MySQL (данные размазаны по многим нодам) дело десятое.

>> а клиенты как будут через ssh подключиться к вашему шеллу?

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

ВНИМАНИЕ! Илита в треде!

>> а клиенты как будут через ssh подключиться к вашему шеллу?

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

КО опять в недоумении ))) нафига на небольшом хостинге Кассандра или BigTable или Hadoop/HBase? Ставить любую СУБД уровня MySQL/PostrgeSQL и жить счастливо.

Основная задача Кассандры - линейно увеличивать объем БД и производительность при добавлении новых нод в кластер. + Отказоустойчивость кластера при внезапном отключении нод, понятно что данные не должны потеряться даже если отключилось несколько нод.

Типа развернули БД на 10 нод по 1Тб = 10 Тб для данных + обслуживает 1 000 000 запросов get (поскольку это нереляционка)

Добавили еще 10 нод, получили увеличение еще на 10Тб + обслуживает уже 2 000 000 запросов

А я не говорю что оно надо на не больших хостингах ))

После прочтения этого с вики Кассандры:

The CAP theorem (Brewer) states that you have to pick two of Consistency, Availability, Partition tolerance: You can't have the three at the same time and get an acceptable latency.

Cassandra values Availability and Partitioning tolerance (AP).

Становится понятно, что оно не консистентно... не понятно вообще Кассандра поддерживает ли транзакции? и каким образом?

есть ли в ней понятие близкое к таблицам? и как реализуется транзакция изменений в нескольких полях нескольких таблиц?

СУБД на файловую систему меняется только если в БД хранится иерархия и ничего больше.

Как получить из ФС результат вида «вывести всех пользователей, которые запостили на форум с 21 до 23 часов 25 февраля 2010 года от 2 до 3 сообщений»

На ФС придется циклом идти по всем пользователям. На СУБД - оптимизатор запросов может построить грамотный join с применением индексов по нужным полям. Даже перестроить запрос может. В итоге прочитываться с диска будет намного меньше данных чем при работе ФС.

Неделю назад натыкался на ссылку, спасибо что помог ее найти

http://softwaremaniacs.org/blog/2010/01/31/brewers-cap-theorem/

совсем не обязательно упираться в принципы дизайна ACID http://ru.wikipedia.org/wiki/ACID , который ставит во главу угла Consistency, жертвуя двумя другими свойствами. Теперь у нас есть такая альтернатива, как BASE http://queue.acm.org/detail.cfm?id=1394128 (известная также как «eventual consistency»), которую например очень любят и используют в Amazon. Там во главе угла стоит Availability.

> http://softwaremaniacs.org/blog/2010/01/31/brewers-cap-theorem/

интересно. а разве MySQL Cluster не все три сразу свойства имеет?

Там данные шарятся по группе, плюс каждая группа тянет полную реплику данных. Если падает нода, то ее данные вытягиваются с ноды другой группы. +PT

Поскольку применяется MySQL как обработчик данных то БД получает ACID. +C

Пока живы ноды данных + хотя бы одна из SQL-нод, то система работает +A

итого я насчитал все три сразу. Математики ошиблись?!?

> Теперь у нас есть такая альтернатива, как BASE http://queue.acm.org/detail.cfm?id=1394128 (известная также как «eventual consistency»), которую например очень любят и используют в Amazon.

статья написана eBay, но сам eBay деньги не проводит - этим занимается их подразделение PayPal. наверное не просто так сделаны *разные* системы.

если бид потеряли, то пофигу, а если деньги - то кто-то может сесть на Н-ый срок ;)

>Я это и пытаюсь объяснить некоторым людям, но они упорно не хотят понимать. :(

Ну тут тебе сейчас расскажут, что кроме реляционных других БД не бывает. Иерархические, сетевые это все вранье. Еще конечно FramerD вранье. А еще NoSQL это не база данных. Хотя в названии не сказано NoDatabase. Скорее не реляционная. А еще я плохо понимаю что такого страшного в нагрузке к фейсбуку. Неужели нельзя хранить данные Васи на одном сервере, а Пети на другом. Да есть кросслинки, но их тоже можно пересчитать, множество конечно.

Гораздо сложнее с документами Воллмарта. Если служба сервиса хочет узнать где куплена железка и что еще покупал этот человек и сколько железок этой партии вылетело и от этого поставщика. А то, что сервиса меньше, ну так кэш в фейсбуке не так важен, хоть на час ставь.