"Не сложно" в данном контексте означало, что задача выполнима для разработчиков реляционнйих баз данных.valchkou wrote:Вы рассуждаете как наши топ манагеры.
Попробуйте сделать! хотя конечно понятие сложности у всех разное.
A бэкап что делать будет?valchkou wrote:Но такие проекты админов не требуют.
наоборот я считаю, что смогут и возможно сейчас самое подходящее время.nightmare2 wrote:"Не сложно" в данном контексте означало, что задача выполнима для разработчиков реляционнйих баз данных.valchkou wrote:Вы рассуждаете как наши топ манагеры.
Попробуйте сделать! хотя конечно понятие сложности у всех разное.
Или вы считаете, что разработчики ORACLE или SQL Server не осилят MongoDB/Cassandra/whatever?
Очень своевременное замечание, не в пользу relational DB.nightmare2 wrote:A бэкап что делать будет?valchkou wrote:Но такие проекты админов не требуют.
Тараканы могут разбегаться и в RDBS с таким же успехом. Другое дело, что cтоимость поддержки тараканов и managed service от хостера какого-нибудь Dynamo или Cassandra по сравнению с таким же сервисом от Оракла будут различаться в разы, а то и на порядки.valchkou wrote: Очень своевременное замечание, не в пользу relational DB.
на cassandra его делать не надо, данные сами разбегаются по серверам, как тараканы из тумбочки.
А postgres/mysql?dotcom wrote:Тараканы могут разбегаться и в RDBS с таким же успехом. Другое дело, что cтоимость поддержки тараканов и managed service от хостера какого-нибудь Dynamo или Cassandra по сравнению с таким же сервисом от Оракла будут различаться в разы, а то и на порядки.valchkou wrote: Очень своевременное замечание, не в пользу relational DB.
на cassandra его делать не надо, данные сами разбегаются по серверам, как тараканы из тумбочки.
Данные то разбегаются, только проблемы могут быть не хардварные а софтварные(ошибка в программе) и проблемные данные тоже будут разбегаться с той же скоростью.valchkou wrote:Очень своевременное замечание, не в пользу relational DB.nightmare2 wrote:A бэкап что делать будет?valchkou wrote:Но такие проекты админов не требуют.
на cassandra его делать не надо, данные сами разбегаются по серверам, как тараканы из тумбочки.
Тут сложно сравнивать. Если не мучиться с бездонной файловой системой для MySQL, то цена должна быть та же.crypto5 wrote: А postgres/mysql?
Что такое бездонная файловая система? И та же по сравнению с чем?dotcom wrote:Тут сложно сравнивать. Если не мучиться с бездонной файловой системой для MySQL, то цена должна быть та же.crypto5 wrote: А postgres/mysql?
И что это меняет?valchkou wrote:Очень своевременное замечание, не в пользу relational DB.
на cassandra его делать не надо, данные сами разбегаются по серверам, как тараканы из тумбочки.
все верно,nightmare2 wrote:И что это меняет?valchkou wrote:Очень своевременное замечание, не в пользу relational DB.
на cassandra его делать не надо, данные сами разбегаются по серверам, как тараканы из тумбочки.
Когда ваша кассандра загнется вместе с серверами где живут тараканы и данные, кто будет восстанавливать все это?
И самое главное, кто будет за все это отвечать?
Хотя тут уже написали про распределенные транзакции но я имел ввиду немного другое. Транзакционная модель подрузомевает наличие транзакционного менеджера (то бишь арбитра). Наличие арбитра дает автоматический bottleneck и в некоторых случаях spof. Плюс реалиоционная модель не подрузомевала concurrent updates of same data/row, так как полагается на наличие транзакции. Если нужно сделать true master-master model или синхроный кластер то появляются выше-упомянуютые распределенные транзакции со всем ихним nightmare.ПростоНик wrote:kostik78,
не могли бы вы развить тему по поводу "реляционные транзакционые БД плохо работают в распределенных системах, хотя народ упорно пытался/пытается их применять" ?
Всю жизнь работаю с такими системами, и еще никто не жаловался.
Простой пример - Authorization session store на несколько десятков милионов пользователей с несколькими тысячами реквестов в секунду. Я в Оракле не большой специалист, но вот про MySQL и Postgres могу сказать, что им плохо будет от такого. С другой стороны Riak вполне себя хорошо чуствует в этой самой же ситуации.valchkou wrote: А давайте возьмем конкретный проект, и попробуем дополнить одно другим.
У нас NoSql пришел, чтобы убить SQL. Держать обе и накладно и смысла нет.
это пример проекта где нужен sql + nosql ?kostik78 wrote:Простой пример - Authorization session storevalchkou wrote: А давайте возьмем конкретный проект, и попробуем дополнить одно другим.
У нас NoSql пришел, чтобы убить SQL. Держать обе и накладно и смысла нет.
Это пример где NoSQL работает лучше чем SQL. И Authorization sessions store это типичный use-case для cloud-base service/product. Чем плох этот пример? Опять же практически в любом комерческом сервисе нужен BI.valchkou wrote:это пример проекта где нужен sql + nosql ?kostik78 wrote: Простой пример - Authorization session store
Пример хорош, я просто не понял к чему он,kostik78 wrote:Это пример где NoSQL работает лучше чем SQL. И Authorization sessions store это типичный use-case для cloud-base service/product. Чем плох этот пример? Опять же практически в любом комерческом сервисе нужен BI.valchkou wrote:это пример проекта где нужен sql + nosql ?kostik78 wrote: Простой пример - Authorization session store
НУ видимо в этом примере данные пользователей хранятся в SQL, и используются для создания сессии, а сама сессия хранится в NoSql.valchkou wrote:Пример хорош, я просто не понял к чему он,kostik78 wrote:Это пример где NoSQL работает лучше чем SQL. И Authorization sessions store это типичный use-case для cloud-base service/product. Чем плох этот пример? Опять же практически в любом комерческом сервисе нужен BI.valchkou wrote:это пример проекта где нужен sql + nosql ?kostik78 wrote: Простой пример - Authorization session store
вы ответили примером на мой пост, показать проект, где SQL и NOSQL друг друга дополняют.
А получилось наоборот. Или я что то не так понял
Это проблема не ограниченности NoSql, а незрелости решений на рынке, особенно два года назад. Со временем все устаканится.Easbayguy wrote:Три года назад когда у нас в компании прозвучала МОНГО и народ начал раздувать шеки, никто не говорил об ограниченной применимости продукта. Все кричали, все никиких больше денег ораклу, даже с МySQL заставляли переписовать на монго. Сейчас, 2 ВП больше нету. Вернули все что перевели с МySQL и о монго никто больше не заикается.
а почему?Easbayguy wrote:Три года назад когда у нас в компании прозвучала МОНГО и народ начал раздувать шеки, никто не говорил об ограниченной применимости продукта. Все кричали, все никиких больше денег ораклу, даже с МySQL заставляли переписовать на монго. Сейчас, 2 ВП больше нету. Вернули все что перевели с МySQL и о монго никто больше не заикается. Сейчас перевожу базы на более приличное железо.
Понимаете если никто вашим сайтом не пользуется или блог там какой, то МонгоДБ можно использовать, если 2 часа простоя в деkабре могут обойтис в несколько миллионов долларов то нет. Так как большинство стартапов работает на уровне концепций и до настояшего траффика просто не доходит, то для разработки прототипа и навешать лапшу самое то.crypto5 wrote:Это проблема не ограниченности NoSql, а незрелости решений на рынке, особенно два года назад. Со временем все устаканится.Easbayguy wrote:Три года назад когда у нас в компании прозвучала МОНГО и народ начал раздувать шеки, никто не говорил об ограниченной применимости продукта. Все кричали, все никиких больше денег ораклу, даже с МySQL заставляли переписовать на монго. Сейчас, 2 ВП больше нету. Вернули все что перевели с МySQL и о монго никто больше не заикается.
Бездонная = distributed. Большие базы в MySQL либо надо сегментировать самому на уровне приложения, либо масштабировать за счет файловой системы. И то и другое требует больше затрат умственной деятельности, чем типичный NoSQL. Про "сранение с чем" - это про цену? Я говорил, что затраты на хостинг open source'а mysql/postgres и nosql'ного решения будет примерно тем же. Dynamo только вроде не open source, но это исключение.crypto5 wrote: Что такое бездонная файловая система? И та же по сравнению с чем?
Хорошо смотрим весь стекvalchkou wrote: Пример хорош, я просто не понял к чему он,
вы ответили примером на мой пост, показать проект, где SQL и NOSQL друг друга дополняют.
А получилось наоборот. Или я что то не так понял
Пристроили NoSQL. 
Ну или пример Mongo (тоже будет работать но ограничениями). А можно взять Postgres (for free) или VerticaDB( for free on start and later for money). Работать будет лучше чем NoSQL. Ну а когда сервис выростет до биг-дайта, то там будет делать гибридный BI - Hadoop + Postgres/VerticaDB.