Здравствуйте, _ABC_, Вы писали:
ANS>>В неверно акцентированном переводе слова "abroghated"? _AB>Так вроде далее по тексту тоже не настаивают на восстановлении после сбоя. Надо перечитать, давно это было...
Это уже будет не durability, а просто поддержка целостности рабоочих структур. В большинстве случаев именно такие гарантии дают журналируемые ФС, но это никто не называет "durability". Имхо, главное тут неаннулируемость изменений.
_AB> Точнее, на практике предполагает потерю данных не более чем на оговоренный соглашением срок.
Я напомню начало начал треда. Кто-то нашел какую-то конкретную реализацию NoSql БД, которая работает в облаке, и сказал, что если запустить инстанс на одной машине (не в облаке), то сбрасывание данных из volatile памяти в долговременное хранилиже раз в 60 сек делает все NoSql не-durable. Я просто заметил, что между потерей данных за 60 сек, и потерей данных за 1 сек нет принципиальной разницы. Данные стали неконсистентны и их нужно привести в актуальное состояние человеческим вмешательством.
Здравствуйте, Sinix, Вы писали:
ANS>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения. S>А её что, замачивают?
Вот именно по-этому я и сказал, что durability никому не нужна. Инженеры знают что её нет (у подавляющего большинства), но делают вид что она есть, потому что в рекламном проспекте слово такое написано. И что интересно, никто не упомянул тут баланс между затратами и результатом, и всё такое прочее. А просто категорично утверждают, что durability есть. Но, при этом, возможность потери данных никто не скрывает. Вот такое вот слабенькое durability.
S>"Потеря ненужных данных" годится для всяких развлекательных ресурсов, где записи (как и их авторы) не несут никакой полезной нагрузки (с точки зрения владельца ресурса). Для софта, который так или иначе имеет дело с реальным миром, подход "работает пока не упадёт" чрезмерно оптимистичен.
Да, да. А потом, последует пожимание плечами и фраза о том, что возможность потери данных никто не замалчивает.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения. S>>А её что, замачивают?
ANS>Вот именно по-этому я и сказал, что durability никому не нужна. Инженеры знают что её нет (у подавляющего большинства), но делают вид что она есть, потому что в рекламном проспекте слово такое написано. ...
По-моему, вы играете за обе стороны — сами придумываете доводы за оппонентов, и сами же их опровергаете.
Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).
Во-вторых, ваш тезис "не будет durability — нафиг ACI!" слегка расходится с реальностью: вам всё равно надо будет как-то разгребать проблемы параллельной обработки данных и защищаться от непредсказуемых побочных эффектов.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>При чем тут NoSql? Негибкость изменения схемы это просто особенность текущей реализации СУБД.
Брр. Поясните мне, что вы называете "негибкостью изменения схемы". Пример, который приведён выше по ветке, некорректен — он не связан с реализацией СУБД. Он связан с тем, что перед СУБД ставят сомнительную задачу — "выкопать окоп для стрельбы с коня".
Если эту же задачу поставить перед NoSQL, она справится ничуть не лучше.
ANS>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).
Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).
Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.
Скорее всего, у меня просто фантазия ограничена моими привычками мыслить в терминах DDL. В таком случае, можно привести пример такого "изменения схемы", которое покажет преимущества NoSQL в полный рост.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, messir VolanD, Вы писали: MV>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:
Ну, пока что там всё в порядке.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).
Здравствуйте, Sinclair, Вы писали:
ANS>>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql). S>Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).
Так я с этим полностью согласен. Более того, имхо, в 99% случаев схема известна. Просто в зависимости от пожеланий пользователя она может меняться. Именно из-за эффективности и нужно при любой возможности создавать структуры в БД.
Тот же SalesForce — это крупнейшаая SaaS CRM. Пользователи могут создавать свои структуры (таблицы) и всё такое прочее. Естественно пользователи не хотят ждать пока схема поменяется. Что у SF получилось — я описывал
. Хотя Oracle вроде много чего умеет. В результате есть, озвученная и тобой, теория, что все изменения могут происходить мгновенно. И есть практика от SF и FF.
S>Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.
На словах, мне нравятся идеи устройства CouchDB.
S>"изменения схемы", которое покажет преимущества NoSQL в полный рост.
Я уж не знаю почему, но в реальной жизни — в обоих примерах с выше — в итоге NoSql получается.
Здравствуйте, gandjustas, Вы писали:
F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>А где его достаточно? Таких задач исчезающе мало.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?
G>>А где его достаточно? Таких задач исчезающе мало.
ANS>btw, Amazon S3 Cloud Stores 262 Billion Objects
И что? Это не ответ на вопрос никак.
Здравствуйте, Sinclair, Вы писали:
MV>>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (: S>Ну, пока что там всё в порядке.
Здравствуйте, Mamut, Вы писали:
M>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)
Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets) S>Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Mamut, Вы писали:
M>>Странно, что в «Философии» про NoSQL мало говорят, но сегодня в твиттере увидел следующее:
К>[cut]
К>Эрик Мейер noSQL называть coSQL (via Mirrorer)