Re[35]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 08:08
Оценка:
Здравствуйте, _ABC_, Вы писали:

ANS>>В неверно акцентированном переводе слова "abroghated"?

_AB>Так вроде далее по тексту тоже не настаивают на восстановлении после сбоя. Надо перечитать, давно это было...

Это уже будет не durability, а просто поддержка целостности рабоочих структур. В большинстве случаев именно такие гарантии дают журналируемые ФС, но это никто не называет "durability". Имхо, главное тут неаннулируемость изменений.

_AB> Точнее, на практике предполагает потерю данных не более чем на оговоренный соглашением срок.


Я напомню начало начал треда. Кто-то нашел какую-то конкретную реализацию NoSql БД, которая работает в облаке, и сказал, что если запустить инстанс на одной машине (не в облаке), то сбрасывание данных из volatile памяти в долговременное хранилиже раз в 60 сек делает все NoSql не-durable. Я просто заметил, что между потерей данных за 60 сек, и потерей данных за 1 сек нет принципиальной разницы. Данные стали неконсистентны и их нужно привести в актуальное состояние человеческим вмешательством.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[35]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 08:17
Оценка:
Здравствуйте, Sinix, Вы писали:

ANS>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

S>А её что, замачивают?

Вот именно по-этому я и сказал, что durability никому не нужна. Инженеры знают что её нет (у подавляющего большинства), но делают вид что она есть, потому что в рекламном проспекте слово такое написано. И что интересно, никто не упомянул тут баланс между затратами и результатом, и всё такое прочее. А просто категорично утверждают, что durability есть. Но, при этом, возможность потери данных никто не скрывает. Вот такое вот слабенькое durability.

S>"Потеря ненужных данных" годится для всяких развлекательных ресурсов, где записи (как и их авторы) не несут никакой полезной нагрузки (с точки зрения владельца ресурса). Для софта, который так или иначе имеет дело с реальным миром, подход "работает пока не упадёт" чрезмерно оптимистичен.


Да, да. А потом, последует пожимание плечами и фраза о том, что возможность потери данных никто не замалчивает.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[36]: Про NoSQL
От: Sinix  
Дата: 06.02.11 09:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Моё мнение, если бы была явно оглашена возможность терять транзакции, пусть даже не штатно, а в результате сбоя, то "ACI" не получил бы особого распространения.

S>>А её что, замачивают?

ANS>Вот именно по-этому я и сказал, что durability никому не нужна. Инженеры знают что её нет (у подавляющего большинства), но делают вид что она есть, потому что в рекламном проспекте слово такое написано. ...


По-моему, вы играете за обе стороны — сами придумываете доводы за оппонентов, и сами же их опровергаете.

Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).
Во-вторых, ваш тезис "не будет durability — нафиг ACI!" слегка расходится с реальностью: вам всё равно надо будет как-то разгребать проблемы параллельной обработки данных и защищаться от непредсказуемых побочных эффектов.
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.11 15:06
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>При чем тут NoSql? Негибкость изменения схемы это просто особенность текущей реализации СУБД.
Брр. Поясните мне, что вы называете "негибкостью изменения схемы". Пример, который приведён выше по ветке, некорректен — он не связан с реализацией СУБД. Он связан с тем, что перед СУБД ставят сомнительную задачу — "выкопать окоп для стрельбы с коня".
Если эту же задачу поставить перед NoSQL, она справится ничуть не лучше.

ANS>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).

Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).
Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.

Скорее всего, у меня просто фантазия ограничена моими привычками мыслить в терминах DDL. В таком случае, можно привести пример такого "изменения схемы", которое покажет преимущества NoSQL в полный рост.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.02.11 15:22
Оценка:
Здравствуйте, messir VolanD, Вы писали:
MV>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:
Ну, пока что там всё в порядке.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 18:35
Оценка: :)
Здравствуйте, Sinix, Вы писали:

S>Во-первых, durability не даёт 100% гарантии, но, в тоже время, позволяет без существенных затрат обеспечивать сервис в 5-6 девяток за счёт почти моментального восстановления (в большинстве случаев).


Бред.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:15
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

ANS>>Еще раз, schema-less появилась не из желания хранить неструктурированные данные, а просто как ответ на желание гибко менять схему. И если проблема downtime еще как-то разрешима, хоть и не до конца, и в каждом конкретном случае по своему, что автоматом поднимает требования к уровню исполнителей. То если тебе нужно менять схему в ран-тайм за фиксированное время (реал-тайм), тогда скажи "привет" подходу от FriendFeed (у них MySql) или SalesForce (у них Oracle). Кстати, в итоге, и у тех и у тех получился NoSql (поверх Sql).

S>Мне не очень понятно, что вы называете "менять схему". Если у вас схема мягкая, то RDBMS будут с этим работать не сильно хуже, чем NoSQL. А местами — лучше (теми местами, где схема всё-таки известна. Ключевые слова — semantic query optimization).

Так я с этим полностью согласен. Более того, имхо, в 99% случаев схема известна. Просто в зависимости от пожеланий пользователя она может меняться. Именно из-за эффективности и нужно при любой возможности создавать структуры в БД.
Тот же SalesForce — это крупнейшаая SaaS CRM. Пользователи могут создавать свои структуры (таблицы) и всё такое прочее. Естественно пользователи не хотят ждать пока схема поменяется. Что у SF получилось — я описывал
Автор: Andrei N.Sobchuck
Дата: 30.01.11
. Хотя Oracle вроде много чего умеет. В результате есть, озвученная и тобой, теория, что все изменения могут происходить мгновенно. И есть практика от SF и FF.

S>Если схема жёсткая, то я не понимаю, как её обеспечить в "schemaless" инфраструктуре.


На словах, мне нравятся идеи устройства CouchDB.

S>"изменения схемы", которое покажет преимущества NoSQL в полный рост.


Я уж не знаю почему, но в реальной жизни — в обоих примерах с выше — в итоге NoSql получается.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[5]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:17
Оценка:
Здравствуйте, gandjustas, Вы писали:

F>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?


G>А где его достаточно? Таких задач исчезающе мало.


btw, Amazon S3 Cloud Stores 262 Billion Objects
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.02.11 21:22
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, gandjustas, Вы писали:


F>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?


G>>А где его достаточно? Таких задач исчезающе мало.


ANS>btw, Amazon S3 Cloud Stores 262 Billion Objects

И что? Это не ответ на вопрос никак.
Re[15]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.02.11 21:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

MV>>Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:

S>Ну, пока что там всё в порядке.

Я так понял это формат экспорта.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.02.11 04:40
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я так понял это формат экспорта.

Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.02.11 07:02
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Я так понял это формат экспорта.

S>Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.

Хе-хе. У FlockDB тоже внизу SQL, а сверху вполне себе графовая NoSql. Это ведь зависит от патерна использования.
Интересно как они теги обрабатывают.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.11 18:37
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)

Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 26.02.11 21:18
Оценка:
M>>Правда, какой там закат солнца вручную при модификации дерева (это я про nested sets)
S>Совершенно верно. Поэтому его применение оправдано только при крайне редких изменениях.

А хоцца-то частые изменения


dmitriid.comGitHubLinkedIn
Re[16]: Про NoSQL
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.11 16:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M>А хоцца-то частые изменения

Берите транзитивные замыкания, кто ж вам мешает-то
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 27.02.11 21:23
Оценка:
M>>А хоцца-то частые изменения
S>Берите транзитивные замыкания, кто ж вам мешает-то

Ой, дяденька, не ругайтесь Я лучше какой-нить Neo4j возьму %)


dmitriid.comGitHubLinkedIn
Re: Про NoSQL
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.02.11 10:58
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Думаю, это достаточно философское замечание


Я думаю, эта мудрость взята отсюда
Re[2]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 28.02.11 11:11
Оценка:
M>>Думаю, это достаточно философское замечание

Pzz>Я думаю, эта мудрость взята отсюда


Ну это-то понятно


dmitriid.comGitHubLinkedIn
Re[17]: andrei.sobchuck
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.03.11 09:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Я так понял это формат экспорта.

S>Хм. Может быть. Но судя по MS SQL внутрях — там таки SQL.

Не только. Еще и Redis.

А мне тут говорят, что любое кеширование — от неумения SQL пользовать
Автор: gandjustas
Дата: 31.01.11
.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Про NoSQL
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 03.05.11 15:07
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mamut, Вы писали:


M>>Странно, что в «Философии» про NoSQL мало говорят, но сегодня в твиттере увидел следующее:


К>[cut]


К>Эрик Мейер noSQL называть coSQL (via Mirrorer)


Я не видел, чтобы это кто-то постил. Так что вот: A Co-Relational Model of Data for Large Shared Data Banks
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.