Здравствуйте, gandjustas, Вы писали:
G>И еще раз: Приведи пример СУБД, которая не позволяет SQL доступ к данным. Покажи ту которая не умеет обеспечивать ACID.
Gemstone/S, Objectivity. А вот если ты термин "mature" заменишь на "mainstream", то тут будет сложнее. Но мы же тут не о высокой моде?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Не нужно обобщать Мне, к примеру, приходится отмахиваться от всяких Cassandr, хотя люди начитались реклам и спрашивают, а почему нет? У меня просто есть конкретные претензии как к ACID вообще, так и к конкретным имплементациям RDBMS в частности. G>>Конкретнее.
ANS>Самая большая проблема — DDL. Любое применение DDL это даунтайм.
Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей? Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/
ANS>Именно отсюда растут ноги у всяких sсhema-less способностей.
они совсем из другого места растут.
ANS>Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим.
Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.
ANS>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц.
MySQL — база для домашних страниц. Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.
ANS>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу.
Точно, вот только есть два простых факта:
1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.
2)Если всетаки понадобятся вагоны "кешей, шардов и реплик", то это решение уже будет приниматься на основе имеющихся данных, профиля их использования итп. NoSQL базы предлагают делать это заранее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. Я тут намедни термин интересный узнал: "непредвиденная консистентность". Вот такие системы обычно консистентны по недоразумению.
...a pattern I call “Potential Consistency”. Some well known architectures have this property– any system that relies on asynchronous master-slave replication + a cache (think mysql + memcache) has, at best, potential consistency.
Whether you do write-through or read-through caching (do you update the cache or invalidate it?) you can easily have different data in your master, each of your slaves (replication, especially in mysql, isn’t perfect because statement-based replication is non-deterministic) and memcache. And there’s no guarantees that this differences will ever be resolved. Your data might be consistent, but once it becomes inconsistent there no guarantees it will ever become consistent again. Unless you build something to repair that data. If you can do this successfully– congratulations, you’ve built an eventually consistent system.
Здравствуйте, gandjustas, Вы писали:
ANS>>Самая большая проблема — DDL. Любое применение DDL это даунтайм. G>Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей?
29'294'914 строк. Estimate — 5 часов.
G>Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/
...30 million rows...
ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.
Почти мгновенно
ANS>>Именно отсюда растут ноги у всяких sсhema-less способностей. G>они совсем из другого места растут.
Но, почему-то акцентируется именно возможность гибко менять схему. А не возможность простого хранения абстрактных неструктурированных данных.
ANS>>Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим. G>Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.
И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.
ANS>>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц. G>MySQL — база для домашних страниц.
Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.
G>Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники.
Никогда не лазил в исходники ни MySql ни Postgres. Что я потерял?
ANS>>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. G>Точно, вот только есть два простых факта: G>1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма.
Но не понятно откуда тогда эти кеши появляются если они никому не нужны.
G>2)Если всетаки понадобятся вагоны "кешей, шардов и реплик", то это решение уже будет приниматься на основе имеющихся данных, профиля их использования итп.
Да, плохо только, что принимаются во внимание "имеющихся данных, профиля их использования" и неберутся во внимание вопросы консистентности. Еще раз вопрос, не лучше ли сразу взять, например, FlockDB (напомню, что внизу в нём MySql)?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Самая большая проблема — DDL. Любое применение DDL это даунтайм. G>>Страшное слово "даунтайм". Сколько этот даунтайм продолжаться будет? например добавление колонки на миллионе записей?
ANS>29'294'914 строк. Estimate — 5 часов.
G>>Я вот в SQL Server такого не видел. То что криво DDL сделан в том же MySQL не является общей проблемой/
ANS>Да? Что я вижу: ANS>
...30 million rows...
ANS>ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.
ANS>Почти мгновенно
Ключевое выделил. Не делай так. Просто не делай. Есть другие способы.
ANS>>>Именно отсюда растут ноги у всяких sсhema-less способностей. G>>они совсем из другого места растут. ANS>Но, почему-то акцентируется именно возможность гибко менять схему. А не возможность простого хранения абстрактных неструктурированных данных.
"Гибко менять схему" фактически означает забивать на целостность существующих данных при изменениях схемы.
ANS>>>Т.е. хранение именно неструктурированных данных мало кому нужно, а вот возможность менять схему без трёхдневного даунтайма пригодилось бы многим. G>>Можно менять схему и без даунтайма вообще. Если ты так не умеешь, то это не проблема SQL, RDBMS и других аббривеатур.
ANS>Не умею. Научи.
Дорого тебе это выйдет.
ANS>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение.
А это и не нужно.
ANS>>>Плюс у разных БД могут быть разные "особенности" поведения при активном создании таблиц из программы. Типа, как у MySql, который открывал и никогда не закрывал файлы плюс не освобождал буферы из-под хоть раз использованных таблиц. G>>MySQL — база для домашних страниц. ANS>Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle.
У них спроси.
G>>Для серьезной работы с ней требуется обладать очень большими знаниями, зачастую лезть в исходники. ANS>Никогда не лазил в исходники ни MySql ни Postgres. Что я потерял?
Ничего, но и не приобрел тоже.
ANS>>>Плюс при попытках масштабирования либо ты завязываешся на мега железо, либо живёш с вагоном кешей, шардов и реплик. Что является NoSql (не-ACID, точнее) системой несмотря на наличие SQL БД внизу. G>>Точно, вот только есть два простых факта: G>>1)Далеко не всем система нужны вагоны "кешей, шардов и реплик", для 95% и более достаточно регулярных бекапов и они могут себе позволить час в неделю дунтайма. ANS>Но не понятно откуда тогда эти кеши появляются если они никому не нужны.
Зачастую как раз от того что люди не умеют работать с SQL
G>>2)Если всетаки понадобятся вагоны "кешей, шардов и реплик", то это решение уже будет приниматься на основе имеющихся данных, профиля их использования итп. ANS>Да, плохо только, что принимаются во внимание "имеющихся данных, профиля их использования" и неберутся во внимание вопросы консистентности.
См пункт 1.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Просто с логом быстрее. Пока что.
Ну-ну. =)
ANS>Ну, я конечно утрирую, однако возникает вопрос, если только оно и нужно, то почему за него не готовы платить широкие массы?
Шырокие массы за него отслюнявливают только в путь.
ANS>Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс?
С чего ты взял что не готовы? Где хоть одна бухгалтерская поделка на NoSql без Durability? MySQL и тот скрипя все что надо прикрутил.
Здравствуйте, IB, Вы писали:
ANS>>Ну, я конечно утрирую, однако возникает вопрос, если только оно и нужно, то почему за него не готовы платить широкие массы? IB>Шырокие массы за него отслюнявливают только в путь.
Тут в треде было сказано, что 90 процентов пользователей работают на только одном сервере. И два сервера для них равносильно организации экспедиции на марс. Это эти массы то отлюнявливают? Или термин "массы" для тебя имеет особое значение?
ANS>>Хе-хе. Так по треду постоянно апеллируют к тому, что нагруженые системы удел не многих, а у многих всё мол попроще. И им durability тоже нужно. Но как раз эти "многие" платить за обеспечение "D" не готовы. Парадокс? IB>С чего ты взял что не готовы? Где хоть одна бухгалтерская поделка на NoSql без Durability?
В 90 процентов случаев бухгалтер "в случае чего" вколотит данные заново. Потому, что стоит он дешевле сервера. И работают же как-то.
IB>MySQL и тот скрипя все что надо прикрутил.
Здравствуйте, gandjustas, Вы писали:
G>Дорого тебе это выйдет.
Т.е. — сложно. Об этом я и говорю.
ANS>>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение. G>А это и не нужно.
Нужно. И дело не только в убирании даунтайма без плясок с бубном человеком без сотни сертификатов. Возможность изменения схемы из прикладной программы синхронно и за конечное время даёт дополнительные возможности. Это как с кодогенерацией — находятся отдельные ретрограды, которые считают, что можно и без неё, но народ то пользуется.
Кстати, если это никому не нужно, то зачем люди изобретали и продолжают(!) изобретать такое чудо.
ANS>>Хорошо, FriendFeed отпадает Но зачем тогда SalesForce такую хитросхему наворотил если у них вполне себе Oracle. G>У них спроси.
Потому что им нужно, что бы схема менялась в произвольные моменты времени гарантировано за время комфортное для человека (это сколько там — меньше 300мс?).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>И в любом случае DDL не получится использовать на равных с DML. Это основное ограничение. G>>А это и не нужно.
ANS>Нужно. И дело не только в убирании даунтайма без плясок с бубном человеком без сотни сертификатов. Возможность изменения схемы из прикладной программы синхронно и за конечное время даёт дополнительные возможности. Это как с кодогенерацией — находятся отдельные ретрограды, которые считают, что можно и без неё, но народ то пользуется.
Ну ты придумал что нужно и для тебя это проблема. Другим не нужно и проблем нет.
ANS>Кстати, если это никому не нужно, то зачем люди изобретали и продолжают(!) изобретать такое чудо.
Идиотизмом страдают и не более того.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS> Это эти массы то отлюнявливают?
Ага, именно эти. 100% критичных к бизнесу приложений, начиная от бухгалтерии, сидит на RDBMS, которая таки обеспечивает требуемый уровень Durability, что бы ты там по этому поводу не думал.
ANS>В 90 процентов случаев бухгалтер "в случае чего" вколотит данные заново. ANS>Потому, что стоит он дешевле сервера. И работают же как-то.
Да ты чо? Понимаешь, проблема не в том, что данные потеряются, проблема в том, что данные не сойдутся — и вот это уже может стоить сильно дороже и сервера и всей бухгалтерии. Не говоря уже о том, что ты заблуждаешься относительно стоимости железа и человека в наш просвещенный век.
ANS>fsync перед отсылкой "OK" это не дюрабилити.
Я устал понимать, что ты понимаешь под durability, но задача БД — сделать так, чтобы любой уровень durability при установке БД мог быть обеспечен исключительно средствами администрирования, классические SQL БД это обеспечивают, в том числе и MySQL оборудованный InnoDB, а вот NoSQL — нет.
Более того, как показала практика, если отказаться от durability и consistency в одной конкретно взятой БД, например в том же MySQL-е, то в плане производительности все NoSQL сосут как промышленный пылесос, чего собственно и следовало ожидать: http://l-o-n-g.livejournal.com/153756.html
Здравствуйте, IB, Вы писали:
ANS>>fsync перед отсылкой "OK" это не дюрабилити. IB>Я устал понимать, что ты понимаешь под durability,
Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.
IB>но задача БД — сделать так, чтобы любой уровень durability при установке БД мог быть обеспечен исключительно средствами администрирования, классические SQL БД это обеспечивают, в том числе и MySQL оборудованный InnoDB, а вот NoSQL — нет.
Дело обстоит ровно наоборот. Если бы программисту пришлось что-то обеспечивать, то для этого не нужно ничего выдумывать.
Для примера достаточно рассмотреть Google Megastore. И сравнить с тем, что смогли выдать на гора а Амазоне.
IB>Более того, как показала практика, если отказаться от durability и consistency в одной конкретно взятой БД, например в том же MySQL-е, то в плане производительности все NoSQL сосут как промышленный пылесос, чего собственно и следовало ожидать: http://l-o-n-g.livejournal.com/153756.html
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться.
Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.
ANS>Дело обстоит ровно наоборот.
Да ты чо? Где у NoSql хоть какое-нибудь durability вместе с consistency.
ANS>Для примера достаточно рассмотреть
Для примера чего? Крутизны гугла и амазона? )
ANS>Это вообще что, о чем и к чему?
Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.
Здравствуйте, IB, Вы писали:
IB>Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.
А с включенными блокировками, на вставках, — MySQL не рвёт только очень ленивый.
Здравствуйте, IB, Вы писали:
ANS>>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться. IB>Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.
. Расскажи на пальцах, как в рамках одного хранилища данных получить таки "Durability" устойчивое к сбоям этого хранилища.
ANS>>Дело обстоит ровно наоборот. IB>Да ты чо? Где у NoSql хоть какое-нибудь durability вместе с consistency.
Всё на месте. Кстати, в тройке CAP и просто "Consistency" и более слабое требование "eventual consistency" подразумевает, что данные таки durable.
ANS>>Для примера достаточно рассмотреть IB>Для примера чего? Крутизны гугла и амазона? )
Не. Это пример того, что для ACID БД, то что сделал Amazon — потолок. А для т.н. NoSql возможно то, что сделал Гугль.
ANS>>Это вообще что, о чем и к чему? IB>Это о том, что NoSQL даже нормально писать не умеют. Если у банального MySql-я отключить блокировки и ряд других заморочек по согласованности, то он рвет чисто in memory NoSQL больше чем в два раза.
Странное обобщение. Сравнивать производительность key-value с, например, CouchDB некорректно. Впрочем, не смотря на то, что мне нравятся возможности CouchDB, лично для меня более приемлемый подход — FlockDB. А именно, внизу традиционная mature RDBMS, а сверху другой интерфейс предоставляющий определённые гарантии.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, IB, Вы писали:
ANS>>>Не зависимо от сбоев нижележащего оборудования закомиченные данные должны остаться. IB>>Вот и прекрасно. Традиционные SQL базы гарантируют это, а NoSql — нет.
ANS>Я уже спрашивал как
. Расскажи на пальцах, как в рамках одного хранилища данных получить таки "Durability" устойчивое к сбоям этого хранилища.
А вот интересно, является ли 'durability' полным синонимом 'fault tolerance'? Вроде как нет.
В оригинале у Грея было:
Durability: once a transaction is commited, it cannot be abrogated.
Т.е. подразумевается, что после завершения транзакции она не может быть отменена. Я считаю, что расширенное трактование данного термина как fault-tolerance, т.е. устойчивость к сбоям несколько неправильно. В чем я ошибаюсь?
Здравствуйте, _ABC_, Вы писали:
_AB>В оригинале у Грея было: _AB>
_AB>Durability: once a transaction is commited, it cannot be abrogated.
_AB>Т.е. подразумевается, что после завершения транзакции она не может быть отменена. Я считаю, что расширенное трактование данного термина как fault-tolerance, т.е. устойчивость к сбоям несколько неправильно. В чем я ошибаюсь?
В неверно акцентированном переводе слова "abroghated"?
И, вроде как, fault-tolerance не подразумевает под собой обязательную сохранность данных. Где то видел презентацию, где из-за того, что целостность промежуточной системы (очереди) долго восстанавливалась при креше приняли решение пересоздавать очередь, а старые данные просто терять. Если они не важны, то почему нет? И обратное верно — система может сохранять данные и не быть fault-tolerant. Просто это не совсем практично и по факту неработоспособность системы больше некого время может быть равносильна потере данных. Для теории это же не важно.
Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.
А её что, замачивают?
"Потеря ненужных данных" годится для всяких развлекательных ресурсов, где записи (как и их авторы) не несут никакой полезной нагрузки (с точки зрения владельца ресурса). Для софта, который так или иначе имеет дело с реальным миром, подход "работает пока не упадёт" чрезмерно оптимистичен.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Да? Что я вижу: ANS>
...30 million rows...
ANS>ALTER TABLE command is performed, adding 2 INT columns (not null) to the table, with a default value of 0. This command has been running for 29 hours.
ANS>Почти мгновенно
Стесняюсь спросить: а что будет, если мы в NoSQL попробуем запихать 60 миллионов нулей? Неужели есть способ обойти скорость света и получить мгновенный результат?
А если в NoSQL вы не собираетесь запихивать нули, то какого ж рожна вы это делаете с SQL?
Делаете обычные, nullable колонки. Если охота сделать так, чтобы при извлечении были нули там, где нет данных — рисуете view с isnull(column1, 0). Если хотите запретить вставлять null — вешаете instead of триггер.
В целом — выглядит как неудачный пример оправдать применение NoSQL при помощи некомпетентности в SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>В неверно акцентированном переводе слова "abroghated"?
Так вроде далее по тексту тоже не настаивают на восстановлении после сбоя. Надо перечитать, давно это было...
ANS>И, вроде как, fault-tolerance не подразумевает под собой обязательную сохранность данных. Где то видел презентацию, где из-за того, что целостность промежуточной системы (очереди) долго восстанавливалась при креше приняли решение пересоздавать очередь, а старые данные просто терять.
А при чем здесь fault-tolerance? Вы читали про целостность, вообще-то. А вот устойчивость к сбоям предполагает обязательную сохранность данных. Точнее, на практике предполагает потерю данных не более чем на оговоренный соглашением срок.
ANS>Если они не важны, то почему нет? И обратное верно — система может сохранять данные и не быть fault-tolerant. Просто это не совсем практично и по факту неработоспособность системы больше некого время может быть равносильна потере данных. Для теории это же не важно.
Если данные не важны — зачем их хранить постоянно? Это уже нецелевое расходование ресурсов, наверное.
ANS>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.
Вообще-то, в результате сбоя ты можешь потерять транзакции. Это оговорено явно и предусмотрены механизмы для их восстановления. "D" предусматривает гарантию не потери завершенной транзакции в штатном режиме. При этом успешное автоматическое восстановление после сбоя — это штатная ситуация.
В общем, либо я не так понял Грея (перечитаю на досуге), либо Вы, Андрей, не правы, идя вслед за вики и прочими mySQL-щиками и NoSQL-щиками в утверждении, что Durability — это гарантия сохранности данных после сбоя.
Здравствуйте, Sinclair, Вы писали:
S>А если в NoSQL вы не собираетесь запихивать нули, то какого ж рожна вы это делаете с SQL? S>Делаете обычные, nullable колонки. Если охота сделать так, чтобы при извлечении были нули там, где нет данных — рисуете view с isnull(column1, 0). Если хотите запретить вставлять null — вешаете instead of триггер. S>В целом — выглядит как неудачный пример оправдать применение NoSQL при помощи некомпетентности в SQL.
При чем тут NoSql? Негибкость изменения схемы это просто особенность текущей реализации СУБД. Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).
Мы уже победили, просто это еще не так заметно...
