AlexandrPlusПочему не выбрали традиционные реляционные sql-ые СУБД?

Потому что ACID им нафиг не нужен, а вот скорость вставки/чтения простых запросов критично.
Т.е. если какая-то часть данных "потеряется", то это не страшно.
А вот задержка в запросе на чтение/запись на пару миллисекунд - это очень критично.

<:o)

AlexandrPlusкак раз ACID выбранная ими СУБД обеспечивает

Чудес не бывает, хотя некоторые продолжают надеяться.
Если бы данная БД поддерживала ACID при высокой скорости, то тогда бы другие БД были просто не нужны.
Я верю, что она поддерживает какую-то транзакционность, достаточную для выполняемых задач.
Но ACID - нет, т.к. это серьезные тормоза на больших объемах данных.

Кстати на этом и "играет" MySQL.
Хотите "быстро" - вот быстрый движок, но нет ACID.
Хотите "надежно" - вот надежный движок, но скорость не впечатляет.

<:o)

vadiminfomad_nazgulЕсли бы данная БД поддерживала ACID при высокой скорости, то тогда бы другие БД были просто не нужны.

Чтобы другие были не нужны, понадобился бы все же в первую очередь SQL, скорее всего.
Ить их не называют NoACID, а NoSQL. В SQL, по-видимому, пока существенное достижения в БД проявились.

Если бы NoSQL представила "честный" ACID + большую скорость, то SQL действительно был б не нужен.
Я просто помню времена до массового SQL (хотя и RMD).
Когда появился SQL, который был быстрее и удобнее чем xBase, на тех же мощностях.
Так сразу наступил закат xBase.

Если NoSQL сейчас представить что-то подобное, как SQL тогда, то закат SQL будет стремительным.

Но пока кроме "маркетингового шума" NoSQL ничего не представили.
Да они быстрее SQL-серверов.
Но когда начинается разговора об ACID, то тут же всплывает куча "но".
А когда "под давлением общественности" NoSQL добиваются ACID, то выясняется, что производительность у NoSQL решений ниже, чем у существующих SQL-серверов.

vadiminfoТогда бы им стоило и называться No"честный"ACID. Ведь для захвата всего рынка не хватает "честности", а не SQL.
Вот именно!
Т.к. они не поддерживают ACID, то и не акцентируют на этом внимание!
А ACID прописан в стандарте SQL.
Но ACID нужен бизнесу.
Кому хочется из-за "повисшей" транзакции потерять данные.
Вот NoSQL и переносят фокус внимания с ACID на RMD.

vadiminfomad_nazgulКогда появился SQL, который был быстрее и удобнее чем xBase, на тех же мощностях.
Так сразу наступил закат xBase.
.
Но он не был быстрее иерархических СУБД, которые господствали в то время. Однако, сразу стал захватывать часть рынка.
Все же его сила в другом: в логической МД. Что способствало снижению затран на проекирование БД и извлечение информации - SQL ассоциативный и декларативный язык, который не праздноя себя являет в доступе к данным (другие МД тоже пытаются обзоводиться таким, но они там не основные или не такие успешные, судя по всему).


Прошу прощения. Вы знаете что такое xBase?
Это одна из реализаций RMD, никакими иерархическими БД там и не пахнет.
И проектирование БД для xBase абсолютно ничем не отличается от проектирование БД для SQL.
А были еще другие реляционные БД.
Например как Calrion и Paradox.

Иерархические БД - это совсем другая история.
Они живы до сих пор, скрываясь под видом файловых систем ;-)


vadiminfomad_nazgulЕсли NoSQL сейчас представить что-то подобное, как SQL тогда, то закат SQL будет стремительным.

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


Вся "сила" SQL по сравнению с другими БД, в надежности.
Я бы не сказал, что NoSQL не пользуются популярностью.
Пользуются, но только там, где во главу угла ставиться скорость в ущерб надежности.
Поэтому SQL так прочно засела в нише учетных система. ;-)

vadiminfomad_nazgulНо когда начинается разговора об ACID, то тут же всплывает куча "но".
А когда "под давлением общественности" NoSQL добиваются ACID, то выясняется, что производительность у NoSQL решений ниже, чем у существующих SQL-серверов.

Для кого куча "но" об ACID, а для кого куча "но" об SQL.

Я уже сказал, см. выше.
Никто из NoSQL не хочет признавать, что надежность системы и целостность данных не гарантируется в принципе.
Поэтому идут на маркетинговые ухищрения. ;-)

АдмiнiстраторInfernal V. Ravenпропущено...
Вырубает питание и падают оба мемори сервера.
Предполагается, естественно, что оба сервера работают на независимом питание, на независимых бесперебойниках ( хотябы ).
Вероятность выхода дисковой системы или железа одновременно обоих серверов достаточно мала, так как и при зеркалировании.

Э-э-э это уже "отмазки".
Т.к. хранение данных в памяти не надежно.
Построить систему из ненадежных элементов можно, но дорого.
А кеширование можно настроить и на SQL-сервере будет работать с такой же скоростью.

Ладно выключение питание.

Ну если OS "завалилась".
Данные не успели сохраниться на диск.
Что тогда?

Вы хотите сказать, что BSODов и Kernel Panic не сущствует :-)
Вот про это я говорил, что когда разговор заходит о надежности и целостности данных, то выходят различные "НО". ;-)