Здравствуйте, GarryIV, Вы писали: GIV>Булшыт какой-то. Графиг показывает одно, подпись к нему другое, точных цифр нет, как и что считали непонятно.
Всё согласуется.
Полный рынок в 2017 — $50 миллиардов.
Хадуп с NoSQL — 3% от этого.
При этом Cumulative Average Growth Rate, т.е. ежегодный прирост (в среднем за 4 года), устроен так:
— весь рынок: 10% в год
— реляционки: 11% в год
— хадуп и NoSQL: ажно 36% в год
— остальные нереляционные неудачники: падение на 23% в год.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, rm822, Вы писали:
R>Учитывая что общий объем рынка ~$50 Bln, а монго как крупный игрок nosql гордо заявляет ~$0.1 Bln цифры похожи на правду
Ах так это рынок продажи лицензий и услуг?
Не ну понятно этот весь NoSQL бесплатен и открыт. А за поддержку далеко не все платят. Мы например с Оракла мигрировали на Postrges + Hadoop чтоб не платить за лицензию. Так что низкая доля выручки тут скорее плюс для потребителя.
GIV>Мы например с Оракла мигрировали на Postrges + Hadoop чтоб не платить за лицензию.
Многие мигрировали по ценовым соображениям, и почти никто по соображениям что nosql чем-то лучше.
Пойнт в том что рынок поделен монстрами с выручкой в десятки млрд $.
Если бы NoSQL представлял для них какую-то угрозу, то эти компании были скуплены бы на корню, и/или в доработки RDBMS были бы брошены колоссальные ресурсы.
Здравствуйте, rm822, Вы писали:
GIV>>Мы например с Оракла мигрировали на Postrges + Hadoop чтоб не платить за лицензию. R>Многие мигрировали по ценовым соображениям, и почти никто по соображениям что nosql чем-то лучше.
NoSQL понятно чем лучше и хуже, тут даже обсуждать нечего.
R>Пойнт в том что рынок поделен монстрами с выручкой в десятки млрд $. R>Если бы NoSQL представлял для них какую-то угрозу, то эти компании были скуплены бы на корню, и/или в доработки RDBMS были бы брошены колоссальные ресурсы.
Мне вот абсолютно все равно представляет ли NoSQL угрозу RDBMS или нет в плане зарабатывания бабла на его продаже.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Я того, чтобы просто хранить огромные объемы данных не нужны ни базы данных, ни hadoop. Нужно просто много дисков. Даже не много серверов, а просто дисков. C>Это бред. Просто бред.
Что именно?
C>Сложить данные — это вообще не проблема. У меня домашняя файлопомойка в шкафу сейчас на 20ТБ.
Ты только что сам назвал это бредом, не?
C>Проблема в том, что доступ к данным будет медленным. Один сервер физически не сможет обеспечить более 10ГБит пропускной способности или более нескольких сотен запросов в секунду. А это сейчас вообще детская нагрузка.
Ну ок, поставь два сервера. В этом проблема?
C>Значит надо как-то распределять данные между несколькиими узлами — и всё. Прощай ACID и РСУБД.
А вот это действительно бред. При добавлении правил локальности данных ты не жертвуешь ACID, там где нужен ACID.
Еще раз для тебя повторю простую вещь:
Пока у тебя транзакции не пересекают границы инстанса — ты не теряешь ничего.
Например счетчики ВСЕХ товаров амазона можно было бы положить в одну РСУБД и ВСЕГДА иметь ГАРАНТИЮ консистентности. А для надежности иметь пару зеркал с синхронным коммитом. Причем сервис был бы не сильно нагруженным, пару тыщ простых запросов в секунду от силы.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Я того, чтобы просто хранить огромные объемы данных не нужны ни базы данных, ни hadoop. Нужно просто много дисков. Даже не много серверов, а просто дисков. AB>А зачем просто хранить огромные объемы данных, если их не обрабатывать?
Я вот не знаю зачем. Но именно хранение огромных объемов "продают" как фишку бигдаты.
Процитирую из твоего же сообщения
"Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства."
Тут про обработку этих данных ни слова как-то.
g>> Ну ок, сложили 20 триллионов строк на диски. Какие запросы к ним делаются? Хоть один запрос трогает хотя бы 10% этих данных? Что-то сомневаюсь. Я так понимаю, что scope большинства запросов ограничен одним сайтом, то есть где-то 0.01% от данных. AB>"Требуется вычислять сложные агрегаты типа количества уникальных посетителей"
Ага, на одном сайте. Это какую часть данных трогает?
AB>"Один запрос может потребовать просканировать сотни миллионов строк за время не более нескольких секунд, или миллионы строк за время не более нескольких сотен миллисекунд." g>> То есть можно считать что 374 сервера и 2 ПБ сжатых данных, это около 5 тб на сервер. AB>Ты забыл про репликацию и отказоустойчивость уровня ДЦ.
Это надо добавить к указанному объему или отнять?
AB>Ну и тут говорят, что уже 3.4 PB данных и 420 серверов на 6 дата-центров.
8ТБ на сервер. Повторюсь, что я видел живую MS SQL базу, которая жила на одном сервере, объем баз был 40ТБ. Из них около 8ТБ занимал CCI, по которому в реальном времени гонялись аналитические запросы.
g>> У меня кейс с большим объемом на сервер был и РСУБД (не олап система, а именно РСУБД) нормально пережевывала этот объем. AB>Ты забыл, что помимо объемов данных есть еще нефиговый такой рейт записи ("более 20 миллиардах событий в сутки", если взять тупо среднее, то ~230 тыс. событий в секунду) и чтения (про это официальных цифр я сходу не нашел, но по обрывочным сведениям, это "2 млн. в сутки" => ~200 rps в пике).
Запись же не синхронная (не атомарная). Я на РСУБД тоже делал запись по 1000 строк в секунду. В открытый bulk load писались строки и раз в минуту это дело перекидывалось в живые таблицы.
g>> А если бы надо было несколько за раз ПБ обработать, то появилось бы несколько серверов, они бы прожевали каждый свой кусок данных, а потом в каком-нить middleware промежуточные результаты были бы объединены. Я думаю и в яндексе происходит то же самое. AB>Ты сейчас рассказываешь про классический MapReduce, работающий во множестве NoSQL решений (типа того же Hadoop) что называется "из коробки".
Если у тебя проект вырос до состояния петабайт данных, то фичи "из коробки" тебя интересовать не будут от слова совсем.
Или кто-то реально думает, что его стартапу с 3 клиентами понадобится mapreduce?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Это зависит от РСУБД. Например на MS SQL scale-up обходится дешевле, чем scale-out в монге. Потому что диски и память дешевы, а процессоры с материнками — нет. Получается что поставить 10 серверов монги дороже, чем в 10 раз увеличить память и диски в сервере ms sql и увеличить количество ядер для удержания нагрузки.
AB>Это утверждение справедливо только для небольших объемов ресурсов, пока ты не подходишь к потолку по физическим ограничениям. Когда становится некуда доставлять CPU/RAM => апгрейд тушки на новую модель (плюс закупка новых лицензий, если ПО лицензируется на аппаратные ресурсы) => ценник начинает расти нелинейно. Плюс не забываем, что тебе в любом случае нужно иметь >> 1 сервера, чтобы минимизировать ущерб от отказов и нелинейный ценник еще начинает умножаться на N.
Я же говорю, мы считали а не теоретизировали.
Был один проект с базой на MS SQL, которую залетный архитектор переделал на Mongo.
Сервак был один. 8 ядер, 64 гб памяти, диск на 1ТБ.
В начале переделки база занимала 40 гб. На аналогичный сервак с монгой отлично влезало.
К концу переделки объем данных вырос до 250 гб. Оказалось что сервак с MS SQL отлично справлялся и с таким объемом (не совсем отлично, но добавление еще 32 гб решило проблемы), а для монги уже понадобилось 4 сервака как для SQL Server.
Когда собрали статку по нагрузке оказалось что один MS SQL эквивалентен примерно 6 монговским. При этом апгрейд его почти в половину дешевле (с учетом лицензий), чем удовение кластера монги.
Причем уже на тот момент было понятно как секционировать базу MS SQL для scaleout, чтобы выдержать экспоненциальный рост (который в итоге не случился).
AB>Иметь много дешевых (непроизводительных) серверов тоже не разумно, т.к. пространство и электричество в ДЦ не менее дороги. По этому находят некий баланс цены условного юнита, к его производительности и сильно от него стараются не отклоняться. Ну а дальше, если упрощать, "вот тебе железо, крутись как хочешь" и здесь легкость горизонтального масштабирования начинает играть совсем новыми красками.
На самом деле в чистом железе scaleup сильно дешевле scale-out пока банально не упрешься в ограничения scale up. То есть не получится в современный сервак воткнуть 10ТБ оперативки как ни крути. Но 1ТБ воткнуть можно и это будет дешевле, чем иметь 8 серваков по 128ГБ и сильно дешевле, чем 32 сервака по 32 гб ОП. Раз 5 это считал, и каждый раж scale up дешевле выходило.
С софтом сильно разные фишки получаются. Иногда scale up для софта дорогой, а иногда scale out. Иногда софт просто не держит scale up.
Здравствуйте, gandjustas, Вы писали:
G>Я же говорю, мы считали а не теоретизировали.
А на расчеты можно взглянуть, или оне были на салфетке в кафе? (реально инетересно, без подвоха)
G>На самом деле в чистом железе scaleup сильно дешевле scale-out пока банально не упрешься в ограничения scale up. То есть не получится в современный сервак воткнуть 10ТБ оперативки как ни крути. Но 1ТБ воткнуть можно и это будет дешевле, чем иметь 8 серваков по 128ГБ и сильно дешевле, чем 32 сервака по 32 гб ОП. Раз 5 это считал, и каждый раж scale up дешевле выходило. G>С софтом сильно разные фишки получаются. Иногда scale up для софта дорогой, а иногда scale out. Иногда софт просто не держит scale up.
Кмк, в перспективе, особенно там, где возможен exp рост, scaleout лучше scaleup. Лучше переделать, чем недоделать. Плюс облака никто не отменял, так что железо не проблема.
подозрительные из вас счетоводы
G>Был один проект с базой на MS SQL, которую залетный архитектор переделал на Mongo. G>Сервак был один. 8 ядер, 64 гб памяти, диск на 1ТБ. G>В начале переделки база занимала 40 гб. На аналогичный сервак с монгой отлично влезало. G>К концу переделки объем данных вырос до 250 гб. Оказалось что сервак с MS SQL отлично справлялся и с таким объемом (не совсем отлично, но добавление еще 32 гб решило проблемы), а для монги уже понадобилось 4 сервака как для SQL Server.
с 40 на 250 гб значит требуется нормальный партишенинг, нормальный партишенинг и паралелльность — ЕЕ редакция мсскл. ЕЕ редакция это $14k за ядрышко и четверть млн баксов за 20 ядер entry level сервера. 4 сервера монги явно более чем в 10 раз дешевле обошлись, при этом у монги redundancy ...
G>На самом деле в чистом железе scaleup сильно дешевле scale-out пока банально не упрешься в ограничения scale up. То есть не получится в современный сервак воткнуть 10ТБ оперативки как ни крути. Но 1ТБ воткнуть можно и это будет дешевле, чем иметь 8 серваков по 128ГБ и сильно дешевле, чем 32 сервака по 32 гб ОП. Раз 5 это считал, и каждый раж scale up дешевле выходило.
ерунда. лицензия мсскл задирает стоимость по экспоненте.
Здравствуйте, Cyberax, Вы писали:
C>Ещё есть очень интересная оптимизация — идемпотентные операции можно безопасно группировать, что невозможно с классическими транзакциями. Так что когда шард получает запрос, он не выполняет его сразу же, а кладёт в очередь
Именно так.
Это основная фишка систем с высокой пропускной способностью.
Здравствуйте, gandjustas, Вы писали:
G>И как работает атомарность при покупке нескольких товаров? Если два клиента заказывают два товара но в разной последовательности.
Если в рамках одной покупки, то товары можно отсортировать по ID.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот на мой взгляд, подвох NoSQL как раз в том, что его кривая квалификации имеет некоторый провал. S>То есть чтобы нахипстерить на нём "лендинг паге" нужно в 2-3 раза меньше времени, чем с использованием традиционных SQL. Новичку — вообще может в 10 раз меньше потребоваться, особенно если он изучал только курсы по вёрстке и ангуляру.
И ты где-то наблюдал в достаточном кол-ве у новичков NoSQL?
Там же в основном SQLite или MySQL.
Я наблюдал NoSQL уже явно в неординарных сценариях.
S>И профессионалам допилить NoSQL до амазоновских эпических масштабов тоже существенно дешевле, чем RDBMS.
Так он изначально под такие сценарии и проектировался — для произвольного горизонтального масштабирования простой выборки или для произвольного повышения доступности.
S>А вот в середине этого спектра, где у нас и разработчик имеет хоть какую-то квалификацию, и нагрузка на проект уже выше демо-уровня, но ни мега-гуру ни миллиардов прибыльных транзакций в секунду нет, RDBMS уделывают NoSQL. S>Потому что в них как раз вложены огромные усилия — в то, чтобы заставить относительно неплохо крутиться схему, спроектированную по учебнику.
С этим никто не спорил.
S>А NoSQL в этом случае отходит в сторонку: "сам написал — сам и трахайся".
NoSQL это вообще просто "кирпичик" дизайна — самодостаточное изолированное хранилище или набор их (грубо таблица или набор несвязанных таблиц).
RDBMS — это согласованный набор хранилищ/таблиц.
Убери такое согласование м/у таблицами в RDBMS, например, убери внешний ключ для целей повышения эффективности, и вот ты уже двигаешься в сторону NoSQL. ))
Я тебе уже описывал некоторые трюки, которые пришлось проворачивать, чтобы РСУБД быстрее пахала.
С разменом на всё больший контроль не ср-вами базы, а внешней обвязкой.
В пределе такие трюки и дают NoSQL.
Здравствуйте, Cyberax, Вы писали:
C>Amazon использует nosql везде, Google их использует ещё более везде.
А почему ты считаешь, что используемые в Google базы данных относятся к nosql? Вполне себе sql с транзакциями (обычно к nosql относят то, что не поддерживает целостность данных).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, WolfHound, Вы писали:
WH>>>>А NoSQL уже научился ACID? Или всё так же данные теряет? C>>>Если у вас NoSQL теряет данные — то это ваши проблемы. WH>>То есть не умеет. А это означает что NoSQL как был кэшем так им и остался. C>При высокой нагрузке ACID не существует, от слова "совсем нафиг". Более того, и даже в классических РСУБД приходится думать об идемпотентности и правильном дизайне операций.
WH>>Ну максимум что туда можно положить это лайки, посты и фотки котиков. C>Угу. И ещё сотни миллионов покупок на миллиарды долларов.
A>А почему ты считаешь, что используемые в Google базы данных относятся к nosql? Вполне себе sql с транзакциями (обычно к nosql относят то, что не поддерживает целостность данных).
hadoop и hbase были созданы по мотивам документа гугла, который описывал как работает гугловый поисковый индекс.
Здравствуйте, Ballista, Вы писали:
G>>Я же говорю, мы считали а не теоретизировали. B>подозрительные из вас счетоводы
Сами можете повторить эксперимент.
G>>Был один проект с базой на MS SQL, которую залетный архитектор переделал на Mongo. G>>Сервак был один. 8 ядер, 64 гб памяти, диск на 1ТБ. G>>В начале переделки база занимала 40 гб. На аналогичный сервак с монгой отлично влезало. G>>К концу переделки объем данных вырос до 250 гб. Оказалось что сервак с MS SQL отлично справлялся и с таким объемом (не совсем отлично, но добавление еще 32 гб решило проблемы), а для монги уже понадобилось 4 сервака как для SQL Server.
B>с 40 на 250 гб значит требуется нормальный партишенинг, нормальный партишенинг и паралелльность — ЕЕ редакция мсскл. ЕЕ редакция это $14k за ядрышко и четверть млн баксов за 20 ядер entry level сервера. 4 сервера монги явно более чем в 10 раз дешевле обошлись, при этом у монги redundancy ...
Standard хватало.
И ключевая проблема в том, что scale up для SQL Server требовал дисков и памяти, процессор по большей части отдыхал (не более 25% нагрузки для базы в 250гб получалось), аналитика была отдельно. А для монги нужен был полноценный сервер.
G>>На самом деле в чистом железе scaleup сильно дешевле scale-out пока банально не упрешься в ограничения scale up. То есть не получится в современный сервак воткнуть 10ТБ оперативки как ни крути. Но 1ТБ воткнуть можно и это будет дешевле, чем иметь 8 серваков по 128ГБ и сильно дешевле, чем 32 сервака по 32 гб ОП. Раз 5 это считал, и каждый раж scale up дешевле выходило.
B>ерунда. лицензия мсскл задирает стоимость по экспоненте.
Только если нагрузка на проц растет по экспоненте. А на практике нет. Правильная архитектра РСУБД почти всегда упирается сначала в диски.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Cyberax, Вы писали:
C>>Ещё есть очень интересная оптимизация — идемпотентные операции можно безопасно группировать, что невозможно с классическими транзакциями. Так что когда шард получает запрос, он не выполняет его сразу же, а кладёт в очередь
V>Именно так. V>Это основная фишка систем с высокой пропускной способностью.
G>>>Я же говорю, мы считали а не теоретизировали. B>>подозрительные из вас счетоводы G>Сами можете повторить эксперимент.
провел. правда с ораклом. теперь у нас hadoop ...
B>>с 40 на 250 гб значит требуется нормальный партишенинг, нормальный партишенинг и паралелльность — ЕЕ редакция мсскл. ЕЕ редакция это $14k за ядрышко и четверть млн баксов за 20 ядер entry level сервера. 4 сервера монги явно более чем в 10 раз дешевле обошлись, при этом у монги redundancy ... G>Standard хватало.
серьезно ? в 21 веке без партишенинга и без параллельности в запросах ? но даже так, микро-сервер с 20 ядрами потянет на $74. все равно заметно дороже хоть 8 серверов, а ведь мсскл еще и не дешевая дисковая полка нужна.
подозрительные у вас расчеты ...
G>И ключевая проблема в том, что scale up для SQL Server требовал дисков и памяти, процессор по большей части отдыхал (не более 25% нагрузки для базы в 250гб получалось), аналитика была отдельно. А для монги нужен был полноценный сервер.
еще бы, стандард эдишен. 25% небойсь четко одно ядро
B>>ерунда. лицензия мсскл задирает стоимость по экспоненте. G>Только если нагрузка на проц растет по экспоненте. А на практике нет. Правильная архитектра РСУБД почти всегда упирается сначала в диски.
именно. по этому всякие хадупы с даталейками и теснят, там гораздо выше утилизация ресурсов, процы всегда на 100% загружены.
Здравствуйте, Ballista, Вы писали:
G>>>>Я же говорю, мы считали а не теоретизировали. B>>>подозрительные из вас счетоводы G>>Сами можете повторить эксперимент.
B>провел. правда с ораклом. теперь у нас hadoop ...
С ораклом все плохо из-за цены лицензий.
B>>>с 40 на 250 гб значит требуется нормальный партишенинг, нормальный партишенинг и паралелльность — ЕЕ редакция мсскл. ЕЕ редакция это $14k за ядрышко и четверть млн баксов за 20 ядер entry level сервера. 4 сервера монги явно более чем в 10 раз дешевле обошлись, при этом у монги redundancy ... G>>Standard хватало.
B>серьезно ? в 21 веке без партишенинга и без параллельности в запросах ?
На тот момент хватало. Сейчас хз что там, давно уже там не работаю.
B>но даже так, микро-сервер с 20 ядрами потянет на $74. все равно заметно дороже хоть 8 серверов, а ведь мсскл еще и не дешевая дисковая полка нужна.
Больше ССД для tempdb нужен, чем дорогая полка.
B>подозрительные у вас расчеты ...
Потому что совокупные мощности требуемые для базы в 250гб на SQL Server оказались в сильно ниже, чем для аналогичного размера баз mongodb.
Требования к дискам (скорости) и процесоорам и памяти росли в зависимости логарифма от объёма данных, а для монги требования к памяти и количеству серверов росли линейно.
Иметь один сервер с 500ГБ ОП на тот момент было слишком накладно.
G>>И ключевая проблема в том, что scale up для SQL Server требовал дисков и памяти, процессор по большей части отдыхал (не более 25% нагрузки для базы в 250гб получалось), аналитика была отдельно. А для монги нужен был полноценный сервер. B>еще бы, стандард эдишен. 25% небойсь четко одно ядро
25% от 6 ядер. То есть двух хватало на тот объем.
B>>>ерунда. лицензия мсскл задирает стоимость по экспоненте. G>>Только если нагрузка на проц растет по экспоненте. А на практике нет. Правильная архитектра РСУБД почти всегда упирается сначала в диски. B>именно. по этому всякие хадупы с даталейками и теснят, там гораздо выше утилизация ресурсов, процы всегда на 100% загружены.
Это самоцель? Какой смысл в хадупе, загружающем ядро на 100% когда с тем же объемом MS SQL загрузит ядро на 50% ?
