Здравствуйте, vdimas, Вы писали:
V>Для такого сценария квалификация не нужна.
Тем лучше. =)
V>А где я тебе возьму, например, циферки по хранению BigData в MS SQL?
Ну а чего тогда вообще заикался? ) Нет ножек — нет варенья, без циферок сказки свои деткам будешь рассказывать, перед сном =)
V>Сама MS использует HDInsight для интеграции РСУБД и BigData...
Что означает, что все данные, которые в биг-дате, есть и в РСУБД, что в свою очередь означает, что в РСУБД их как минимум столько же, сколько в бигдате.
Ты всегда не особо тщателен в выборе аргументов, вот и в очередной раз сам себя оговорил =)
V>По моим наблюдениям за твоими "аргументами".
Свое блестящее владение аргументацией ты продемонстрировал выше. =)
V>Какой ты скользский, однако: V>
V>большинство NoSQL как раз для "на коленных" проектов
V>Фигню спорол и ну давай стрелки переводить.
Ты не только свою логику изложить нормально не можешь, ты даже за чужой уследить не в состоянии.
"Обидно, когда тонко и изящьно оскорбляешь собеседника, а он слишком глуп чтобы понять" (с) =))
V>Скучно...
А мне весело =) Ты так забавно бесишься, что тебя стебать сплошное удовольствие ))
V>Я читаю тебя и вижу избыток аллегорий из разряда "кривые", "жопа" и т.д.
"Свинья везде грязь найдет" (с) =))
P. S.
Ты ловко замял тему кеширования. Уже осознал какой бред пронес? ))
Здравствуйте, gandjustas, Вы писали:
S>>Будет новый раунд корпуса, не более. Стопориться ничего не будет. G>Количество раундов заранее сверху ограничено?
Ну да, бесконечно гонять консенсус смысли не имеет.
Здравствуйте, gandjustas, Вы писали:
S>>>Вы точно уверены, что Амазон держит полмиллиарда запросов в секунду? C>>Да. В этом году примерно столько и было. G>То есть каждый житель США делал более 1 запроса в секунду? Чето мне кажется весь земной шар не генерирует такое количество запросов.
На один просмотр страницы может приходиться около пары десятков запросов.
Здравствуйте, gandjustas, Вы писали:
C>>Consistency. Она обеспечивается частично — есть гарантия того, что нельзя продать больше товаров, чем есть на складе. Но нет гарантии, что клиент может купить товар, если товар ещё доступен. G>Ты все уходишь от вопроса каким образом это достигается. G>Если у тебя атомарные счетчика в разных шардах, то каким образом обеспечивается атомарное изменение обоих?
Атомарных изменений между разными объектами нет. Код делает идемпотентные изменения (возможно с несколькими retry'ами) в обоих счётчиках неатомарно. Однако, можно коррелировать все изменения с помощью ID запроса, который будет одинаков везде.
Это позволяет в фоновом режиме восстанавливать целостность, если клиент неожиданно помер в середине серии изменений.
Здравствуйте, Слава, Вы писали:
C>>Стоит понимать, что один просмотр страницы выливается в несколько запросов к хранилищу. С>Стоит наверное уточнить, что полмиллиарда распределены по всем датацентрам Амазона, а их вообще-то 18 штук, ну и так далее.
Нет. Это была нагрузка в американском сегменте. Остальные Амазоны работают отдельно от американского.
Здравствуйте, gandjustas, Вы писали:
G>Я того, чтобы просто хранить огромные объемы данных не нужны ни базы данных, ни hadoop. Нужно просто много дисков. Даже не много серверов, а просто дисков.
Это бред. Просто бред.
Сложить данные — это вообще не проблема. У меня домашняя файлопомойка в шкафу сейчас на 20ТБ.
Проблема в том, что доступ к данным будет медленным. Один сервер физически не сможет обеспечить более 10ГБит пропускной способности или более нескольких сотен запросов в секунду. А это сейчас вообще детская нагрузка.
Значит надо как-то распределять данные между несколькиими узлами — и всё. Прощай ACID и РСУБД.
Здравствуйте, IB, Вы писали:
IB>>>Как известно, когда в руках молоток, то все вокруг кажетя гвоздями )) C>>См.: РСУБД. IB>Причем здесь РСУБД? С ними никто не носится как с писаной торбой пытаясь запихнуть в каждый сценарий )
Как никто? А IB?
C>>Ага, и самый популярный язык — PHP. IB>То есть NoSQL все-таки не победили? Ну ок, тогда можно и закончить )
Таки победил, просто это пока не так заметно.
GIV>Булшыт какой-то. Графиг показывает одно, подпись к нему другое, точных цифр нет, как и что считали непонятно.
гуглите idc database market share 2017, тысяч за 5 баксов они его раздают с пояснениями и подробностями что и как считалось.
Здравствуйте, IB, Вы писали:
C>>Где конкретно, например, в Амазоне не критична целостность? IB>Понятия не имею ) Амазон большой, много чего себе может позволить потерять )
Ну вот целостность везде важна.
C>> В РСУБД разберётся любая обезьяна, а "волшебно работающие" транзакции позволяют не думать о CAP и прочем. Правильное использование NoSQL — это намного более сложная задача, где часто нужны всякие хитрые решения с идемпотентностью, reconciler'ами и прочим. IB>Я писал про порог вхождения, а не про правильное использование — это разные вещи.
Где РСУБД сложнее, ну вот где? Простые SQL пишутся через 10 минут после открывания HOWTO.
Здравствуйте, IB, Вы писали:
C>>Замечательно! Можно показать РСУБД, которая выдержит нагрузку типичного проекта в Амазоне? IB>Остановись, там речь шла не про нагрузку, а про отказоустойчивость. =)
А в чём разница? Если я возьму MSSQL и нагружу его, то он тоже откажет.
IB>А про нагрузку — давай Амазоновскую команду и она мне любую РСУБД до такого же состояния доведет. )
Не доведёт. Точнее, получится что-то, что будет использовать РСУБД как key-value хранилище.
Здравствуйте, gandjustas, Вы писали:
g> Я того, чтобы просто хранить огромные объемы данных не нужны ни базы данных, ни hadoop. Нужно просто много дисков. Даже не много серверов, а просто дисков.
А зачем просто хранить огромные объемы данных, если их не обрабатывать?
g> Ну ок, сложили 20 триллионов строк на диски. Какие запросы к ним делаются? Хоть один запрос трогает хотя бы 10% этих данных? Что-то сомневаюсь. Я так понимаю, что scope большинства запросов ограничен одним сайтом, то есть где-то 0.01% от данных.
"Требуется вычислять сложные агрегаты типа количества уникальных посетителей"
"Один запрос может потребовать просканировать сотни миллионов строк за время не более нескольких секунд, или миллионы строк за время не более нескольких сотен миллисекунд."
g> То есть можно считать что 374 сервера и 2 ПБ сжатых данных, это около 5 тб на сервер.
Ты забыл про репликацию и отказоустойчивость уровня ДЦ. Ну и тут говорят, что уже 3.4 PB данных и 420 серверов на 6 дата-центров.
g> У меня кейс с большим объемом на сервер был и РСУБД (не олап система, а именно РСУБД) нормально пережевывала этот объем.
Ты забыл, что помимо объемов данных есть еще нефиговый такой рейт записи ("более 20 миллиардах событий в сутки", если взять тупо среднее, то ~230 тыс. событий в секунду) и чтения (про это официальных цифр я сходу не нашел, но по обрывочным сведениям, это "2 млн. в сутки" => ~200 rps в пике).
g> А если бы надо было несколько за раз ПБ обработать, то появилось бы несколько серверов, они бы прожевали каждый свой кусок данных, а потом в каком-нить middleware промежуточные результаты были бы объединены. Я думаю и в яндексе происходит то же самое.
Ты сейчас рассказываешь про классический MapReduce, работающий во множестве NoSQL решений (типа того же Hadoop) что называется "из коробки".
Здравствуйте, gandjustas, Вы писали:
g> Это зависит от РСУБД. Например на MS SQL scale-up обходится дешевле, чем scale-out в монге. Потому что диски и память дешевы, а процессоры с материнками — нет. Получается что поставить 10 серверов монги дороже, чем в 10 раз увеличить память и диски в сервере ms sql и увеличить количество ядер для удержания нагрузки.
Это утверждение справедливо только для небольших объемов ресурсов, пока ты не подходишь к потолку по физическим ограничениям. Когда становится некуда доставлять CPU/RAM => апгрейд тушки на новую модель (плюс закупка новых лицензий, если ПО лицензируется на аппаратные ресурсы) => ценник начинает расти нелинейно. Плюс не забываем, что тебе в любом случае нужно иметь >> 1 сервера, чтобы минимизировать ущерб от отказов и нелинейный ценник еще начинает умножаться на N.
Иметь много дешевых (непроизводительных) серверов тоже не разумно, т.к. пространство и электричество в ДЦ не менее дороги. По этому находят некий баланс цены условного юнита, к его производительности и сильно от него стараются не отклоняться. Ну а дальше, если упрощать, "вот тебе железо, крутись как хочешь" и здесь легкость горизонтального масштабирования начинает играть совсем новыми красками.
Здравствуйте, Cyberax, Вы писали:
C>Это позволяет в фоновом режиме восстанавливать целостность, если клиент неожиданно помер в середине серии изменений.
А если другой клиент считал не корректные изменения прежде чем в фоновом режиме целостность восстановилась?
Здравствуйте, vdimas, Вы писали:
V>Это ты заикался о бигадата в РСУБД.
Ты даже не помнишь уже о чем сам же писал, себя-то хоть перечитывай иногда )
V>Ох, блин, опять. V>Послан.
Да ты опять слил... Быстро ты в этот раз ))
Здравствуйте, Cyberax, Вы писали:
C>А в чём разница? Если я возьму MSSQL и нагружу его, то он тоже откажет.
Ну, если можно нагружать до тех пор пока не ляжет, то разницы между реляционкой и NoSQL опять-таки нет, положить не рассчитаной нагрузкой все что угодно можно ))
IB>>А про нагрузку — давай Амазоновскую команду и она мне любую РСУБД до такого же состояния доведет. ) C>Не доведёт. Точнее, получится что-то, что будет использовать РСУБД как key-value хранилище.
Ну нет, скорее сверху балансер прикрутят на несколько независимых баз. )
Здравствуйте, Cyberax, Вы писали:
C>Ну вот целостность везде важна.
Ну конечно же нет, есть дофига сценариев, где она либо вообще не уперлась, либо можно на ней сэкономить до определенной степени )
C>Где РСУБД сложнее, ну вот где? Простые SQL пишутся через 10 минут после открывания HOWTO.
Это тебе так кажется, потому что ты успел забыть то, что некоторые даже не знали... А для того, кто первый раз столкнулся с задачей хранения это серьезный челледж. Монгу прикрутить не думая — на порядок проще.
Здравствуйте, Cyberax, Вы писали: IB>>Я писал про порог вхождения, а не про правильное использование — это разные вещи. C>Где РСУБД сложнее, ну вот где? Простые SQL пишутся через 10 минут после открывания HOWTO.
Ну я реально встречался с людьми, для которых всё вот это — какая-то непонятная муть.
Вот у них есть JSON-объект; они вообще всю логику приложения представляют себе в терминах JSON-объектов.
А теперь им надо его как-то заперсистить, и тут начинается: надо учить про типы данных; надо придумывать длины для строковых колонок; синтаксис UPDATE и INSERT совершенно разный; экранирование всё это ужасное...
А потом мы немножечко меняем схему, и выясняется, что RDBMS бьёт по рукам — то нельзя дропнуть колонку, на которую ссылается форин кей, то ещё какая пежня.
На фоне этого NoSQL, в котором можно просто сказать .Save() и не париться, выглядит прямо таки как свежий воздух сразу после курилки.
Вот она — целевая аудитория.
Тут же ещё фишка в том, что на разных уровнях люди думают о разном.
На определённом этапе развития люди думают о том, как обеспечить fault tolerance, какая будет производительность, сколько будет стоить это всё обслуживать.
Но в мире есть огромное количество программистов, для которых вот это всё — сильно выше их головы. Им бы сделать так, чтобы оно хоть как-то заработало.
Хотя бы в основном сценарии, happy path. Ну и что, что медленно. Ну и что, что при малейшем сбое мы оставляем систему в неконсистентном состоянии. Пусть хотя бы можно будет прокликать от начала и до конца.
Подавляющее большинство инструментов проектируются именно для этих людей. Code first? ASP.Net WebPages? VB/vcx? Куда ни ткни — все хотят на ёлку.
Смешно то, что SQL в своё время проектировался именно как инструмент для посредственностей, неспособных правильно манипулировать структурками в файлах на фортране.
Это как если бы мы наблюдали за тем, как коробка-автомат воспринимается новым поколением водителей как слишком сложная в управлении.
Ну вот на мой взгляд, подвох NoSQL как раз в том, что его кривая квалификации имеет некоторый провал.
То есть чтобы нахипстерить на нём "лендинг паге" нужно в 2-3 раза меньше времени, чем с использованием традиционных SQL. Новичку — вообще может в 10 раз меньше потребоваться, особенно если он изучал только курсы по вёрстке и ангуляру.
И профессионалам допилить NoSQL до амазоновских эпических масштабов тоже существенно дешевле, чем RDBMS.
А вот в середине этого спектра, где у нас и разработчик имеет хоть какую-то квалификацию, и нагрузка на проект уже выше демо-уровня, но ни мега-гуру ни миллиардов прибыльных транзакций в секунду нет, RDBMS уделывают NoSQL.
Потому что в них как раз вложены огромные усилия — в то, чтобы заставить относительно неплохо крутиться схему, спроектированную по учебнику. А NoSQL в этом случае отходит в сторонку: "сам написал — сам и трахайся".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
