На протяжении всей многолетней истории ИТ внимание ученых уделялось чему угодно, но не таким ключевым понятиям, как информация и данные, причем последние особенно пострадали. По умолчанию считался достаточным сам факт их существования, и почти никто не задумывался о таких принципиально важных вопросах, как соотношение между данными и информацией. В итоге сейчас, когда человечество столкнулось с проблемой Больших Данных, обнаружилась чудовищная избыточность хранения — одна и та же информация хранится в сотнях мест, плодятся паразитные данные, а единственным способом борьбы с нерациональным использованием пространства остаются ограниченные по своим возможностям методы дедупликации. Вне зоны внимания осталось то, какими собственными качествами обладают данные, как следует реагировать на изменения их потоков и многое другое. Такое положение сохранялось, пока область приложения компьютеров в бизнесе ограничивалась учетными задачами, а в других отраслях при расчетах с приемлемыми по объемам исходными данными ни у теоретиков, ни у практиков сложившаяся ситуация забот не вызывала. Но когда заговорили о Больших Данных, неожиданно обнаружилась неподготовленность ИТ к работе с невиданными прежде объемами. Выяснилось, что «священная корова» — господствовавшая идея сведения всего разнообразия данных к таблицам реляционных СУБД — морально устарела.

Любая неподготовленность обычно вызывает смуту в общественной жизни, а в случае с СУБД спешно стали появляться альтернативные реляционным решения для работы с неструктурированными данными, и их зачем-то тоже стали называть базами данных, хотя для этих новых форм хранения данных следовало бы придумать что-то иное, например data store. Если бы не произошло распространения понятия «базы данных» за реляционные границы, то и не было бы сравнений и противопоставления старого и нового. А если бы еще не привилось в данном контексте крайне неудачное новообразование «NoSQL», которое позже смягчили до «Not only SQL», то, возможно, градус дискуссии вокруг СУБД был бы заметно ниже.
На русском языке хроника баталий, развернувшихся в экспертном сообществе, с максимально возможной полнотой представлена в работах Сергея Кузнецова и его коллег, в которых отражены позиции всех ведущих специалистов по СУБД, поэтому их можно считать обязательными для всех, кто хочет разобраться в истории возникновения кризиса СУБД. В первую очередь стоит порекомендовать статью «Год эпохи перемен в технологии баз данных», в отношении которой, однако, можно предположить, что глубокая профессиональная заинтересованность авторов в реляционных СУБД отразилась на их оценке альтернативных взглядов специалистов-прагматиков. Дело, конечно же, не в самих СУБД — табличные данные были, есть и будут, но не все представление о мире можно уложить в прокрустово ложе табличных форм. Проблемы данных разнообразнее и шире, чем то, что укладывается в рамки реляционных моделей, и нет ничего удивительного в возникновении альтернативных подходов, уступающих по строгости академическим работам, но имеющих практический выход. Кстати, ситуацию в СУБД можно сравнить и с происходящим в общественно-политической жизни, когда политики — авторы многолетнего застоя — начинают предлагать пути выхода, исключающие все альтернативные варианты.

...дальше - тут http://www.osp.ru/os/2012/02/13014107/

Как бы не пришлось специалистам по скулю идти работать на стройки

Пора все переписать!

Ещё Лев Толстой говаривал: "Я не верю тому писателю, который хотя бы 20 раз не переписал своё произведение."

А по поводу импортозамещения: гнать в три шеи нужно все эти Ораклы, брать опен-сорс - и вперед делать свой и нужное а не то что продают с наваром в 5000%

Маленькая поисковая фирма Zvents выпустила под свободной лицензией уникальную разработку — систему управления базами данных, которая легко распараллеливается на сотни машин. В роли серверов может использоваться стандартное дешёвое железо, оно в случае необходимости заменяется «на лету» без потери данных. Новая программа Hypertable теоретически рассчитана работать на кластере из 1000 узлов, хотя текущая альфа-версия 0.9 испытывалась только на десяти. Но тесты прошло отлично, а интерес к разработке уже проявила компания Yahoo. Дело в том, что в настоящее время в Hypertable используется файловая система Hadoop, ведущий разработчик которой работает как раз в Yahoo.

Руководители компании Zvents говорят, что они были вынуждены открыть свою программу в виде open source, потому что у них маленькая софтверная фирма и совершенно нет денег на инфраструктуру. Подобные СУБД коммерческого масштаба нужно испытывать на громадных кластерах.

Программа Hypertable создана по образцу известной базы данных Bigtable, которая используется в Google. Эта распределённая система, когда она была представлена на суд научной общественности в 2006 году, произвела настоящий фурор как одно из лучших изобретений в компьютерной области. Правда, там в качестве файловой системы используется запатентованная Google File System.

Программные интерфейсы к Hypertable слегка отличаются от тех, что обеспечивают доступ к Bigtable. Хотя Hypertable не сравнить по функционалу с мощными базами данных SQL, но она уже гораздо более продвинута, чем примитивная memcached, которая зачастую используется в роли «кэша» для SQL. Кстати, ведущие программисты из компании MySQL говорят, что теоретически и Hypertable тоже можно приспособить для такой роли.
http://habrahabr.ru/post/20134/

http://hypertable.org/

Всё в исподниках, такшта..

guest_20040621prog123, представителей агентства интернет-исследований здесь не жалуют, так что, видимо, вам лучше на этом и закончить.

Я сам себе агенство

vadiminfoprog123 Выяснилось, что «священная корова» — господствовавшая идея сведения всего разнообразия данных к таблицам реляционных СУБД — морально устарела.


Возможно, для того чтобы это устарело морально, должно появиться другая достойная "идея" в чем хранить "все разнообразие". А не что-то простое или что-то урощенное в плане требований к запросам. Т.е. нуно, скорее всего, превзойти РМД на логическом уровне, а не РСУБД на физическом для некоторых задач. Оные и иерархическим уступали в момент своего появления, но за счет логических преимуществ сразу захватили часть рынка.

ISAM непоколебим как скала, все остальное - приходяще и уходяще.

DirksDRBagaBaga,


В частности это:


Так что нас не должна удивлять эволюция SQL DB в NoSQL.

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

guest_20040621> Я сам себе агенство

Время такое, что бритва Хэнлона - второй вариант из возможных.

Глупость, - частный случай закономерности, возражений нет.

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

Займитесь серьезным чтением, - Платон, Аристотель, Онтология...
Сущность, в сегодняшнем понимании в укоренившемся контексте RDBMS , - свалка информации, преднамеренно дезорганизованной:)

NoSQL, т.е. голый ISAM без интерпретатора языка SQL, - наше всё:), но для этого нужна универсальная схема БД, тогда не надо ничего и ни с кем соединять и вся работа идёт через API с использованием функций типа FindKey, NextKeq и т.д. Естетственно скорость выше без такого звена как интерпретатор.

SERG1257prog123NoSQL, т.е. голый ISAM без интерпретатора языка SQL, - наше всё:) https://ru.wikipedia.org/wiki/Настоящие_программисты_не_используют_Паскаль
Потуги секс-меньшинств погоды не сделают:)

Неизменная схема БД - не нуждается в SQL. Идите на биржу:)

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