Re[22]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 28.04.13 07:59
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>> Если оптимизатор сильно не справляется, то с большой вероятностью стоит использовать альтернативные стратегии (NoSQL и прочая).

НС>Да да, тему nosql в корпоративных системах мы уже как то обсуждали
Ну дык. Местный банк какого-нибудь Задрищенска с сервером под DB2 на древнем AS/400, который они купили 10 лет назад — это серьёзная система. А Google с парой сотен тысяч серверов с NoSQL — это несерьёзные хиппи. Знакомо, да.

C>>Собственно, я их использую

НС>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.
Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.). В NoSQL у меня хранится петабайт данных, которые на SQL ну никак не налезут.

C>>И это называется "большая тройка", ага.

НС>Большая тройка это называется в силу количества инсталляций, а вовсе не из-за того что оно работает на амазоновском клауде. Основное применение больших sql серверов — коропоративные системы, а они на облака не ставятся.
1) Ещё как ставятся.
2) Количество инсталляций PostgreSQL и MySQL точно больше DB2 и я почти уверен, что больше MSSQL и Oracle даже без учёта сайтиков на PHP. Или считаем только инсталляции в приличных компаниях с дресскодом и без хиппи?

Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle. Ну да, там оптимизатор есть, но при этом геморрой с администрированием и стоит кучу денег. На кластерах стоит не просто кучу, а гору денег. У MSSQL хотя бы есть приличные инструменты для разработки, но только ради них затачивать всю архитектуру под MS — крайне сомнительное занятие.
Sapienti sat!
Re[23]: Зачем Майкрософту рубить сук, на котором он сидит?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.04.13 08:20
Оценка: 3 (1)
Здравствуйте, Cyberax, Вы писали:

C>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle. Ну да, там оптимизатор есть, но при этом геморрой с администрированием и стоит кучу денег. На кластерах стоит не просто кучу, а гору денег. У MSSQL хотя бы есть приличные инструменты для разработки, но только ради них затачивать всю архитектуру под MS — крайне сомнительное занятие.


В portaone ради "серьёзных людей" пришлось делать вариант поддержки базы Oracle. Теперь
1) нужен фактически отдельный DBA, оплата книг, курсов, etc, и он постоянно занят диагностиками и оптимизациями.
2) резко усложнилось администрирование — банальный запрос мелкой переделки структуры базы требует согласований, подгонки под умение базы в плане организации индексов, местами какие-то безумные требования типа "для этой колонки включите nls_sort_ci, и нам пофиг, что у вас там адрес узла, которому всякие особенности локализации в принципе запрещены", в результате мы рисуя чего хотим видеть — выглядим идиотами перед DBA'щиками.
3) DBA ходит и ноет "вы тут слишком много транзакций плодите. собирайте действия в пачки, даже если совершенно не связаны друг с другом. у меня коммит дорогой".
4) у клиентских библиотек в принципе не лечатся детские болезни. обрыв сети после отправки полного запроса, но до получения ответа — и клиент не знает про таймаут. перевод на connection pool под реальной нагрузкой даёт segfault'ы из-за обгонов. в ихней багбазе уже с десяток тикетов и фиксов на эти проблемы, но они всё равно не вылечены. в результате на клиентское соединение порождаем промежуточный процесс, который не жалко убить.
5) получили жёсткую привязку к RHEL, который отстаёт по куче софта.

И это я ещё не вспоминаю проблемы собственно DBA, и дублирование текстов запросов серьёзнее, чем "select foo from bar". Я давно уже жалею, что перед этим отказались от постгреса.
The God is real, unless declared integer.
Re[21]: Зачем Майкрософту рубить сук, на котором он сидит?
От: IT Россия linq2db.com
Дата: 28.04.13 14:44
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Только вот ты по поводу аппрува линуксового софта не ответил — там что, аппрувить не надо?


У меня пока не было в этом необходимости. Но, чувствую, что политика MS к этому приведёт.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ночной Смотрящий Россия  
Дата: 28.04.13 15:43
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Ну дык. Местный банк какого-нибудь Задрищенска с сервером под DB2 на древнем AS/400, который они купили 10 лет назад — это серьёзная система. А Google с парой сотен тысяч серверов с NoSQL — это несерьёзные хиппи. Знакомо, да.


Ты уже много лет не можешь понять, для чего нужны sql сервера. Гугль использует nosql для хранения слабоструктурированной информации, sql сервера нужны для хорошо структурированной информации (и оптимизатор значительный эффект тоже дает именно на хорошо структурированной информации).

НС>>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.

C>Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.).

Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.

C> В NoSQL у меня хранится петабайт данных


Дай угадаю — слабо структурированных?

C>1) Ещё как ставятся.


Только идиотами, способными доверить критичную информацию стороннему дяде.

C>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2


А в деньгах?

C>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle


Об этом и речь.
Re[24]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 28.04.13 20:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты уже много лет не можешь понять, для чего нужны sql сервера. Гугль использует nosql для хранения слабоструктурированной информации, sql сервера нужны для хорошо структурированной информации (и оптимизатор значительный эффект тоже дает именно на хорошо структурированной информации).

Неверно. NoSQL прекрасно может использоваться для структурированной информации, по которой надо делать сложные запросы. Использование NoSQL часто требуется из-за гигантского объёма данных, по которому обычные реляционные запросы просто непрактичны.

И оптимизатор тут совершенно пофиг.

НС>>>У тебя опять какая нибудь специфическая задача, нужная 0.01% инсталляций sql серверов.

C>>Конкретно PostgreSQL у меня для вполне классических реляционных проблем (учёт задач, метаданные и т.п.).
НС>Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.
Ну да. И это единственно правильный подход.

Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое. Так как масштабируемость такого подхода хромает — РСУБД не умеют нормально параллелизовать запросы (не говоря уж о настоящем массивном распределённом исполнении), так что как только объём данных станет слишком большим для одного узла, то всё.

C>> В NoSQL у меня хранится петабайт данных

НС>Дай угадаю — слабо структурированных?
Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".

C>>1) Ещё как ставятся.

НС>Только идиотами, способными доверить критичную информацию стороннему дяде.
LOL. Такой паранойей страдают, в основном, только банки. Нормальные компании не заморачиваются такой хренью.

C>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2

НС>А в деньгах?
У PostgreSQL цена — $0...

Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.

C>>Я вообще сейчас слабо понимаю смысл использования DB2 и Oracle

НС>Об этом и речь.
MSSQL ради него самого — туда же.
Sapienti sat!
Re[25]: Зачем Майкрософту рубить сук, на котором он сидит?
От: dimgel Россия http://dimgel.ru/
Дата: 29.04.13 00:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое.


А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.
Re: Зачем Майкрософту рубить сук, на котором он сидит?
От: matfei  
Дата: 29.04.13 03:36
Оценка:
Мы в курсе — по этому пишем до сих пор на С/C++ — и нам как-то пофиг — Windows/Linux/Mac или что-то еще это... х) Все компилируется под все платформы с требуемой скоростью работы без overhead — а детали платформы невелируются базовыми системными компонентами... х)
Re[26]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 29.04.13 03:54
Оценка:
Здравствуйте, dimgel, Вы писали:

C>>Если в проекте подтирать штанишки за оптимизатором, то с большой вероятностью стоит использовать что-то другое.

D>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.
Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.
Sapienti sat!
Re[25]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ночной Смотрящий Россия  
Дата: 29.04.13 08:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Неверно.


Верно.

C> NoSQL прекрасно может использоваться для структурированной информации


При этом страшно сливать классическим реляционным серверам.

C>И оптимизатор тут совершенно пофиг.


Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.

НС>>Т.е. смешные объемы, поэтому косяки оптимизатора просто не заметны, если специально их не искать.

C>Ну да. И это единственно правильный подход.

Вот только задачи бывают разными.

C>>> В NoSQL у меня хранится петабайт данных

НС>>Дай угадаю — слабо структурированных?
C>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".

Ну то есть таки слабо стурктурированных. ЧТД.

НС>>Только идиотами, способными доверить критичную информацию стороннему дяде.

C>LOL. Такой паранойей страдают, в основном, только банки. Нормальные компании не заморачиваются такой хренью.

А, ну ну.

C>>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2

НС>>А в деньгах?
C>У PostgreSQL цена — $0...

Не все так просто.

C>Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.


Это совершенно нормальный подход.
Re[27]: Зачем Майкрософту рубить сук, на котором он сидит?
От: dimgel Россия http://dimgel.ru/
Дата: 29.04.13 08:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

D>>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.

C>Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.

Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?
Re[28]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 29.04.13 18:01
Оценка: :)
Здравствуйте, dimgel, Вы писали:

D>>>А за этим чем-то другим не приходится штанишки подтирать? К примеру, гоняя раз в неделю скрипт, проверяющий логическую целостность NoSQL-базы, не поддерживающей FK.

C>>Угу. Тоже верный признак того, что что-то в технологии не так было выбрано.
D>Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?
Это интересный вопрос, который зависит от структуры данных.
Sapienti sat!
Re[26]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 29.04.13 18:08
Оценка: +2
Здравствуйте, Ночной Смотрящий, Вы писали:

C>> NoSQL прекрасно может использоваться для структурированной информации

НС>При этом страшно сливать классическим реляционным серверам.
Нет. Часто NoSQL работает на таких объёмах, где РБД просто не работают. Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке), но на таких гигантских объёмах, что это реально только с custom-ным map/reduce движком.

В Foursqure основной тип данных — это обычные географические координаты. Тем не менее, РБД не справляются даже близко.

C>>И оптимизатор тут совершенно пофиг.

НС>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.
Оптимизатор может улучшить производительность в несколько раз. Это тривиально для большинства NoSQL — тупо берём немного больше узлов.

НС>>>Дай угадаю — слабо структурированных?

C>>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".
НС>Ну то есть таки слабо стурктурированных. ЧТД.
Что именно слабо структурировано в графах?

C>>>>2) Количество инсталляций PostgreSQL и MySQL точно больше DB2

НС>>>А в деньгах?
C>>У PostgreSQL цена — $0...
НС>Не все так просто.
Ну так как будем сравнивать?

C>>Ну и выбирать БД по её цене — это как-то совсем по-олимпийски в Сочи.

НС>Это совершенно нормальный подход.
Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.
Sapienti sat!
Re[29]: Зачем Майкрософту рубить сук, на котором он сидит?
От: dimgel Россия http://dimgel.ru/
Дата: 29.04.13 18:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

D>>Ну и какую технологию ты бы выбрал, если данных петабайт сильно связанных данных?

C>Это интересный вопрос, который зависит от структуры данных.

Угу. Но какую бы ты ни выбрал, компенсировать её недостатки костылями тебе в любом случае придётся, если захочешь выжать из неё максимум. Тут как раз на днях неподалёку CAP-теорему вспоминали — что в общем по сути своей о том же: убить всех зайцев одним выстрелом невозможно.
Re[27]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ночной Смотрящий Россия  
Дата: 29.04.13 21:11
Оценка: +3
Здравствуйте, Cyberax, Вы писали:

НС>>При этом страшно сливать классическим реляционным серверам.

C>Нет. Часто NoSQL работает на таких объёмах, где РБД просто не работают.

А кто то спорил?

C> Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке)


Но работает он с ними как со слабо структурированными. Data mining — одна из классических задачек для нереляционных БД — много в память поднимать сравнительно простых по структуре данных, часто довольно разнородных, и потом их перелопачивать. На таких задачах толку от реляционных северов действительно немного. А вот когда у тебя в запросе сотня джойнов по разнотипным данным, тут nosql подохнет на сравнительно скромных объемах.

НС>>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.

C>Оптимизатор может улучшить производительность в несколько раз.

Он на несколько порядков ее может улучшить.

C> Это тривиально для большинства NoSQL — тупо берём немного больше узлов.


И транзакцию ты тоже по нескольким узлам размазывать будешь? Ах да, какие транзакции в nosql

C>>>Разных. Есть и очень структурированные графы, есть и почти неструктурированный "текст".

НС>>Ну то есть таки слабо стурктурированных. ЧТД.
C>Что именно слабо структурировано в графах?

Типов узлов и связей не очень много. Тебе, небось, их и читать нужно большими сериями с довольно тяжелой для CPU/памяти обработкой, да?

НС>>Не все так просто.

C>Ну так как будем сравнивать?

Не знаю. Вопрос весьма непростой.

НС>>Это совершенно нормальный подход.

C>Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.

Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера. Если ты с последним не сталкивался, это не значит что оно никому не нужно. Но ты можешь продолжать верить в толпу дядей-идиотов в корпорациях, не знающих о таком всемогутере как очередная nosql базка, и в толпу девелоперов, которые вливают огромное бабло в mssql, oracle, postgres и т.п.
Re[28]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Cyberax Марс  
Дата: 29.04.13 22:01
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

C>> Для примера, recommendation engine в Amazon работает со структурированными данными (информация о покупке)

НС>Но работает он с ними как со слабо структурированными. Data mining — одна из классических задачек для нереляционных БД — много в память поднимать сравнительно простых по структуре данных, часто довольно разнородных, и потом их перелопачивать. На таких задачах толку от реляционных северов действительно немного. А вот когда у тебя в запросе сотня джойнов по разнотипным данным, тут nosql подохнет на сравнительно скромных объемах.
Если у меня в запросе будет сотня джойнов, то скорее всего, я убегу нафиг из такого проекта. Такие запросы стоит писать на чём-то, что лучше чем SQL.

НС>>>Вот я и говорю — когда оптимизатор пофиг, тогда можно и nosql.

C>>Оптимизатор может улучшить производительность в несколько раз.
НС>Он на несколько порядков ее может улучшить.
По сравнению с отсутствием оптимизатора, да. По сравнению с оптимизатором Postgres — вряд ли.

C>> Это тривиально для большинства NoSQL — тупо берём немного больше узлов.

НС>И транзакцию ты тоже по нескольким узлам размазывать будешь? Ах да, какие транзакции в nosql
Можно и по нескольким узлам. Можно и с eventual consistency — зависит от задачи.

C>>Что именно слабо структурировано в графах?

НС>Типов узлов и связей не очень много. Тебе, небось, их и читать нужно большими сериями с довольно тяжелой для CPU/памяти обработкой, да?
По-разному, в части случаев просто надо делать простейшие вещи, типа нахождения объединения частично перекрывающихся отрезков. В других случаях приходится делать тяжёлые вычисления. Потом ещё есть запросы, которые нужно делать по хитрым параметрам и в realtime.

НС>>>Это совершенно нормальный подход.

C>>Для дядей в "серьёзных" компаниях, где пофиг на разработчиков и реальную эффективность? Ага.
НС>Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера.
Я вообще-то утверждал, что преимущества использования серверов "большой тройки" уже практически исчезли. А их недостатки как были, так и остались.

Я не утверждал, что SQL совсем не нужен.
Sapienti sat!
Re[2]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.04.13 09:00
Оценка:
Здравствуйте, IT, Вы писали:

IT>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.


А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?
Re[29]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ночной Смотрящий Россия  
Дата: 30.04.13 09:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если у меня в запросе будет сотня джойнов, то скорее всего, я убегу нафиг из такого проекта.


ЧТД.

НС>>Он на несколько порядков ее может улучшить.

C>По сравнению с отсутствием оптимизатора, да. По сравнению с оптимизатором Postgres — вряд ли.

Я пару порядков ловил даже на Оракле из-за косяков оптимизатора, хоть и не часто. Так что на постгри — без проблем.

НС>>Понимаешь ли, дорогой, есть много разных задач. Где то выгоднее распределенные nosql хранилища, где то нужны реляционные сервера.

C>Я вообще-то утверждал, что преимущества использования серверов "большой тройки" уже практически исчезли.

Тут главное — верить.
Re[3]: Зачем Майкрософту рубить сук, на котором он сидит?
От: IT Россия linq2db.com
Дата: 30.04.13 13:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:

IT>>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.


I>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?


С чем именно я спорил? И когда недавно?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Зачем Майкрософту рубить сук, на котором он сидит?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.04.13 14:32
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Некоторым это всё, конечно, покажется страшилками, но против фактов не попрёшь. Не бывает так, чтобы платформа потихоньку сдавала свои позиции, сдавала, сдавала, а потом раз и всех заборола! Хрен вам! Пока мы устойчиво катимся вниз и наклон только увеличивается.


I>>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?


IT>С чем именно я спорил? И когда недавно?


В этом году примерно На счет впф, сильверлайта и тд.
Re[5]: Зачем Майкрософту рубить сук, на котором он сидит?
От: IT Россия linq2db.com
Дата: 30.04.13 14:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>А совсем недавно ты с этим яростно спорил. Забрало что ли приподнял ?

IT>>С чем именно я спорил? И когда недавно?
I>В этом году примерно На счет впф, сильверлайта и тд.

Ну давай уже, признавайся, что там было? Нам всем жутко интересно!
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.