Здравствуйте, gandjustas, Вы писали:
g> "Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства." g> Тут про обработку этих данных ни слова как-то.
Так из сути хранимых данных приблизительно понятно же как их обрабатывают...
g> AB>"Требуется вычислять сложные агрегаты типа количества уникальных посетителей" g> Ага, на одном сайте. Это какую часть данных трогает?
Не знаю, а какая существенная разница? Параллельно же идут подобные же запросы для других счетчиков, плюс наверняка есть внутренняя аналитика не привязанная к конкретному счетчику и оперирующая всеми данными.
g> g>> То есть можно считать что 374 сервера и 2 ПБ сжатых данных, это около 5 тб на сервер. g> AB>Ты забыл про репликацию и отказоустойчивость уровня ДЦ. g> Это надо добавить к указанному объему или отнять?
Умножить на фактор репликации и возможность потери как минимум одного ДЦ без влияния на работу сервиса.
g> Запись же не синхронная (не атомарная). Я на РСУБД тоже делал запись по 1000 строк в секунду. В открытый bulk load писались строки и раз в минуту это дело перекидывалось в живые таблицы.
Не синхронная, но скорее всего атомарная на уровне ноды (в Hadoop она атомарная на уровне кластера) и должна раскатиться за разумное время. А разница между 1000 строк в секунду и 230 как бы в 230 раз.
g> Если у тебя проект вырос до состояния петабайт данных, то фичи "из коробки" тебя интересовать не будут от слова совсем.
Эм... Как раз наоборот — то, что оно все уже готово, протестировано и "просто работает" позволяет сосредоточиться на задачах верхнего уровня — тем и ценны обсуждаемые NoSQL решения.
Здравствуйте, gandjustas, Вы писали:
g> Сервак был один. 8 ядер, 64 гб памяти, диск на 1ТБ. g> В начале переделки база занимала 40 гб.
Ох... Я вот даже не знаю, что на данный пример ответить...
Один сервер = нет никакой отказоустойчивости (даже уровня ноды). Все данные влезли в память на старте и большая их часть впоследствии = скорострельность любой правильно приготовленной базы тут должна быть чуть ли не равна скорости чтения из памяти. Аренда подобного сервера обойдется в 60-100 EUR в месяц в зависимости от комплектации, аренда виртуалки еще дешевле.
Ну т.е. при подобных вводных в контексте темы про NoSQL в общем и цены масштабируемости в частности обсуждать как бы пока и нечего.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Сервак был один. 8 ядер, 64 гб памяти, диск на 1ТБ. g>> В начале переделки база занимала 40 гб.
AB>Ох... Я вот даже не знаю, что на данный пример ответить...
AB>Один сервер = нет никакой отказоустойчивости (даже уровня ноды).
Один сервер не означает что он единственный и никак не зеркалируется.
AB>Все данные влезли в память на старте и большая их часть впоследствии = скорострельность любой правильно приготовленной базы тут должна быть чуть ли не равна скорости чтения из памяти. Аренда подобного сервера обойдется в 60-100 EUR в месяц в зависимости от комплектации, аренда виртуалки еще дешевле.
Так суть NoSQL решений по большей части в том, что все данные умещаются в памяти. Когда это не так — начинает сосать как валютная проститутка. РСУБД при этом вполне нормально работают при объеме данных в разы превышающих объемы ОП.
AB>Ну т.е. при подобных вводных в контексте темы про NoSQL в общем и цены масштабируемости в частности обсуждать как бы пока и нечего.
Там какбы даже при 100кратном росте объема данных нечего было обсуждать.
Вот и получается что для NoSQL нужен или масштаб амазона, где РСУБД гарантированно не справится или маленькая база, которая гарантированно в память одного сервера влезет.
Здравствуйте, gandjustas, Вы писали:
V>>Именно так. V>>Это основная фишка систем с высокой пропускной способностью. G>Если они на разных шардах — чем поможет?
1. Пакетность обработки независимых транзакций ортогональна твоему вопросу — это просто единственный способ достижения максимальной эффективности.
2. Сайберикс сразу дал ответы на все потенциальные вопросы — "квоты". Особенно смешно смотрелось, когда это слово тебе потребовалось пояснять: http://www.rsdn.org/forum/flame.comp/7205390.1
Но ты всё-равно не понял.
B>>провел. правда с ораклом. теперь у нас hadoop ... G>С ораклом все плохо из-за цены лицензий.
не факт. с вашим стандард едишеном там дешевле выйдет т.к. лицензируется сокет, а не каждое ядрышко, как у мсскл
B>>подозрительные у вас расчеты ... G>Потому что совокупные мощности требуемые для базы в 250гб на SQL Server оказались в сильно ниже, чем для аналогичного размера баз mongodb. G>Требования к дискам (скорости) и процесоорам и памяти росли в зависимости логарифма от объёма данных, а для монги требования к памяти и количеству серверов росли линейно. G>Иметь один сервер с 500ГБ ОП на тот момент было слишком накладно.
ну тогда ясно. раз пошел рост требований, значит там чего-то джоинили. натянули на бедолагу реляционный подход.
монги, касандры и прочие документ-ориентированные думаны под иную архитектуру, тотально без джоинов.
G>>>И ключевая проблема в том, что scale up для SQL Server требовал дисков и памяти, процессор по большей части отдыхал (не более 25% нагрузки для базы в 250гб получалось), аналитика была отдельно. А для монги нужен был полноценный сервер. B>>еще бы, стандард эдишен. 25% небойсь четко одно ядро G>25% от 6 ядер. То есть двух хватало на тот объем.
это уровень моего мобильного телефона. в телефоне правда 8 ядер. не, я понимаю, можно и так, но смысла так ужимать с каждым годом все меньше.
B>>именно. по этому всякие хадупы с даталейками и теснят, там гораздо выше утилизация ресурсов, процы всегда на 100% загружены. G>Это самоцель? Какой смысл в хадупе, загружающем ядро на 100% когда с тем же объемом MS SQL загрузит ядро на 50% ?
тот же смысл зачем sql server делает фуллскан с хеш-джоином вместо nl. нестед-луп поблочно будет долбить час, хеш-джоин хоть и поднимет лишние гигабайты, но с определенных объемах много, много, много быстрей.
смысл хадупа вместо траты на лицензии вложиться в железо, т.е. вместо одного ЕЕ сервера мсскл в тот же бюджет разворачивать десяток нод хадупа, которые вместо одного ядра на 50% задействуют 100 и заметно обгонят. пусть проделав много "лишней" работы, но обгонят. и бюджет сохранят.
Здравствуйте, vdimas, Вы писали: V>И ты где-то наблюдал в достаточном кол-ве у новичков NoSQL? V>Там же в основном SQLite или MySQL.
Я наблюдал SQLite с двухколоночными таблицами (int id, varchar(max) json).
V>Убери такое согласование м/у таблицами в RDBMS, например, убери внешний ключ для целей повышения эффективности, и вот ты уже двигаешься в сторону NoSQL. ))
Мне не удавалось наблюдать повышение эффективности при убирании внешнего ключа. Как правило, такие "трюки" применяются по невежеству. То есть люди добиваются замены очень плохого квери плана на просто плохой, и радуются уже этому.
Видел пример, когда на время апгрейда базы дропались индексы, "чтобы апдейт был быстрее". Надо было видеть изумление девелоперов, когда добавление правильных индексов ускорило апгрейд в 50 раз. V>Я тебе уже описывал некоторые трюки, которые пришлось проворачивать, чтобы РСУБД быстрее пахала.
Описание было неубедительным, увы.
Чтобы меня убедить, нужен пример SQL скрипта с замерами производительности и обсуждаемым планом, а не голословные утверждения "Foreign key тормозит".
Потому, к примеру, что наличие foreign key способно не только незначительно замедлить некоторые сценарии, но и существенно ускорить некоторые другие.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Так суть NoSQL решений по большей части в том, что все данные умещаются в памяти. Когда это не так — начинает сосать как валютная проститутка. РСУБД при этом вполне нормально работают при объеме данных в разы превышающих объемы ОП.
Смотря какой NoSQL, есть такая штука, RUM conjecture называется, которая в общем приближении описывает как БД себя ведет в ситуации ограниченности ресурсов. Согласно RUM, если у тебя размер базы сильно больше RAM, ты будешь жертвовать либо скоростью чтения (HBase, Cassandra) либо скоростью записи (привет MSSQL). Но пользователь HBase, в случае слишком медленного чтения просто поднимет еще несколько region серверов. Пользователь MSSQL же, в случае слишком медленной записи попал.
Здравствуйте, gandjustas, Вы писали:
g> Один сервер не означает что он единственный и никак не зеркалируется.
Ну т.е. уже размен начинается уже не 1:6, а исходя из того, о чем ты не договариваешь.
g> Так суть NoSQL решений по большей части в том, что все данные умещаются в памяти. g> Когда это не так — начинает сосать как валютная проститутка.
У тебя столько железа не будет, чтобы данные NoSQL <используемого по назначению> в памяти уместить.
g> Вот и получается что для NoSQL нужен или масштаб амазона, где РСУБД гарантированно не справится
Конечно, у компаний масштабов "амазона" NoSQL используется и в хвост и в гриву. Но для получения профита совершенно не обязательно быть такими большими.
Например, любая более-менее крупная торговая сеть уездного города M может использовать (и есть те, кто использует) возможности технологии для "аналитики по чекам" (не помню как оно у них правильно называется) и построения тех же ML моделей. Для ML например, берем чек, берем соответствующего человека на кассе с камер наблюдения, проводим его по раскадровке в обратном порядке по торговому залу, сохраняем трэк движения, пробуем добавить к трэку вероятностную мета-информацию о поле, возрасте, MAC и названии мобильного устройства, etc. Пробуем связать полученную информацию с другими трэками — опа, у очень похожего трэка засветился "ребенок начальных классов". А сколько у нас вообще посетителей с такими детьми в магазин ходят? А каким маршрутом и к каким кассам они ходят чаще? В этот момент смышленый директор по продажам (а глупые подобные системы не строят) уже начинает отбирать у тебя клавиатуру...
Здравствуйте, Ballista, Вы писали:
B>смысл хадупа вместо траты на лицензии вложиться в железо, т.е. вместо одного ЕЕ сервера мсскл в тот же бюджет разворачивать десяток нод хадупа, которые вместо одного ядра на 50% задействуют 100 и заметно обгонят. пусть проделав много "лишней" работы, но обгонят. и бюджет сохранят.
Я тут вижу демпинг со стороны тех, кто сдаёт вам железо в аренду. Эти, по-хорошему, должна заниматься Антимонопольная Комиссия.
S>Чтобы меня убедить, нужен пример SQL скрипта с замерами производительности и обсуждаемым планом, а не голословные утверждения "Foreign key тормозит". S>Потому, к примеру, что наличие foreign key способно не только незначительно замедлить некоторые сценарии, но и существенно ускорить некоторые другие.
в плане ничего не увидишь. проблема в том, что без FK сервер может применять многоблочную запись, контроллер может применять read ahead, а с FK скорость бывает и в 10 раз падает, потому что сервер вынужден читать по блочно, на один блок таблицы, N блоков FK таблицы/индекса, гоняя головки HDD, вымывая кеши контроллеров.
Здравствуйте, Ballista, Вы писали: B>в плане ничего не увидишь. проблема в том, что без FK сервер может применять многоблочную запись, контроллер может применять read ahead, а с FK скорость бывает и в 10 раз падает, потому что сервер вынужден читать по блочно, на один блок таблицы, N блоков FK таблицы/индекса, гоняя головки HDD, вымывая кеши контроллеров.
Ну, если не в плане, то в статистике запроса мы должны это увидеть.
Где посмотреть на пример? Чтобы прямо было видно как cache miss возрастает, и как контроллер при записи перестаёт применять read ahead.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Что значит "шардинг в автоматическом режиме" ? G>Выбрать инстанс на который писать данные в зависимости от параметров — это вообще не задача СУБД, это задача клиентской библиотеки и подобный решений вагон и маленькая тележка.
Смешались мухи. Клиента вообще не должно интересовать, сколько инстансов и куда он пишет. Есть некий фасад, куда можно постучаться, а далее это уже чистой воды серверная задача: сделать раутинг запроса, исполнить его на подходящем инстансе, дать ответ.
G>Что значит "автоскейлинг" ? G>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться?
Железо — либо физически уже готовое в резерве, либо мы на клауде, где резерв обеспечен датацентром. Далее одна-единственная команда "добавить", поданная человеком или условным крон-скриптом.
G>Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
Маркетинговый хайп сейчас реально большой (особенно если добавить блокчейн!), но не кэшем единым живы NoSQL (иначе бы ничего кроме Redis/MemCache не надо было). Классические сценарии — это разреженные данные высокой размерности (колоночные NoSQL), или работа со слабоструктурированными исходными данными (документ-ориентированные NoSQL). Классический подход на РСУБД даст либо крайне неэффективный в индексировании property bag (для первого случая), либо впихивание документов в BLOB с пред-парсингом ключевых параметров, и при смене модели данных этот пред-парсинг надо будет прогонять заново по всей базе, что крайне дорого (для второго случая).
G>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные.
А зачем стэк-оверфлоерам NoSQL? У них строго структурированный блок данных: сообщение-юзер-метаданные. Да и по размеру — ввиду продуманной реализации — серверов у них по пальцам пересчитать в одной стойке, и вся БД аж на двух серваках, если склероз не склерозит, и то с целью быстрого переключения в случае сбоя (master-slave). Т.е. переход на NoSQL им не даст ничего кроме лишней головной боли "зачем же мы всё поломали".
Здравствуйте, Anton Batenev, Вы писали:
WH>> А NoSQL уже научился ACID? Или всё так же данные теряет?
AB>Они не теряли данные и без ACID....
Может и не теряют — пофиг: у них частенько что-нибудь просто не работает, постоянно. Гугл — плохой пример: поисковик-то может и работает (не уверен), а остальное через жопу.
Всё сказанное выше — личное мнение, если не указано обратное.
А по-моему медленнее, и иногда на три и больше порядка, настолько что некоторые потом начинают выяснять, почему именно данные пошли пешком по дну Атлантики, в вместо того, чтоб со скоростью света вжик-вжик.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ballista, Вы писали: B>>в плане ничего не увидишь. проблема в том, что без FK сервер может применять многоблочную запись, контроллер может применять read ahead, а с FK скорость бывает и в 10 раз падает, потому что сервер вынужден читать по блочно, на один блок таблицы, N блоков FK таблицы/индекса, гоняя головки HDD, вымывая кеши контроллеров. S>Ну, если не в плане, то в статистике запроса мы должны это увидеть. S>Где посмотреть на пример? Чтобы прямо было видно как cache miss возрастает, и как контроллер при записи перестаёт применять read ahead.
лично я смотрел сырые оракловые трейсы, пытаясь понять откуда 8 раз разница. мне кажется майкрософт в принципе нигде не показывает применяет ли мсскл многоблочное чтение или читает лишь один блок. т.е. вы вообще ничего не увидите на уровне мсскл. плюс я говорил о вымывании в кешах контроллера, думаю в большинстве случаев это вообще не посмотреть.
но суть не в этом, суть в том что люди, которых в невежестве не заподозрить открыто советуют дизейблить FK при загрузке. Например Kimball тут советует http://www.essai.rnu.tn/Ebook/Informatique/The%20Data%20Warehouse%20Toolkit,%203rd%20Edition.pdf
еще тут конкретно в связке с мсскл
Jeff Smith on Tue Oct 12, 2010 10:16 am
Defining the foreign keys on the fact table is supposed to help the star schema optimizer in SQL Server 2008. Without the constraints, the optimizer decides on it's own which table is the fact table and which is a dimension table.
If you define the foreign keys, turn off the referential integrity otherwise it will bring your load to a standstill.
Some say that you should turn the referential integrity back on after the load to prevent developers from doing something they shouldn't do with the dimension tables. Some say leave it off. Personally, turn the referential integrity on between loads — the added protection doesn't hurt.
Здравствуйте, IB, Вы писали:
P>>В итоге получатся (в свете субжекта этой дискуссии), что, собственно, не NoSQL "победил" сам по себе, а тонна кастомного кода IB>В одной отдельно взятой кастомной задаче )
И ведь что характерно, ничего нового не придумано. Единственный способ обойтись без распределенных транзакций — идемпотентность и асинхронная обработка.
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить...
Такие системы строятся с ключевой системой, выполняющей роль шедулера. Все запросы, прилетают шедулеру, как бы параллельно они не приходили, они всегда выстроятся в очереди на выполнение у шедулера последоватльно. Щедулер не выполняет преобразований, сохранений и прочей грязной работы, он только содержит метаинформацию всей системы и ставит задачи, с учётом этой метаинформации, задачи параллельно выполянются на нодах.Чтоб не возникакло конфликтов на нодах-это обеспечиваетcя на уровне шедулера. Шедулер может (а может и не может) как часть себя содержать RDBMS, выполняющую OLTP-он работает с метаданными системы, размеры которых могут укладываться в несколько десятков GB для систем, которые обслуживают петабайты целевой информации. Далее шедулер назначает выполнение на разные подсистемы, одной из которых может быть распределённая NoSQL, целевые данные хранящая. "Назначение выполнения" означает чёткую инструкцию о том, что с чем делать и что куда сохранять. Задачу исполнениея следующей задачи в потоке шедулер строит с учётом того, как он построил исолнение предыдущей задачи в очереди. То есть, в NoSQL в таких системах не осуществляется какой либо транзакционной логики, она лишь исполняет простые команды, что-то куда-то положить, что-то где-то изменить. Консистентность NoSQL базы обеспечивается упоямнутым выше шедулером. Никто и нигде в здравом уме не использует распределённые NoSQL базы так же, как используются RDBMS, например, для OLTP.
Здравствуйте, Sinclair, Вы писали:
V>>Убери такое согласование м/у таблицами в RDBMS, например, убери внешний ключ для целей повышения эффективности, и вот ты уже двигаешься в сторону NoSQL. )) S>Мне не удавалось наблюдать повышение эффективности при убирании внешнего ключа.
Я тебе дважды давал ссылку на статью от "Одноклассников", там убирание внешнего ключа упоминалось в числе первых мер.
S>Как правило, такие "трюки" применяются по невежеству.
А с каких пор аргументы в стиле "я такого не наблюдал" не являются невежеством? ))
Всегда ж являлись...
S>То есть люди добиваются замены очень плохого квери плана на просто плохой, и радуются уже этому.
При чём тут план запроса и обязательная надобность обращения к индексам справочных таблиц?
Вот у тебя есть некая таблица, ссылается по внешним ключам на десяток справочников.
Каждое обновление или добавление в такую таблицу должно обращаться к индексам справочников.
Обратное тоже верно — каждое удаление из справочника должно проверять допустимость такого удаления по всем зависимым внешним ключам.
По-сути, твои утверждения сводятся к тому, что цена таких операций равна строго 0-лю.
Не смешно.
S>Видел пример, когда на время апгрейда базы дропались индексы, "чтобы апдейт был быстрее". Надо было видеть изумление девелоперов, когда добавление правильных индексов ускорило апгрейд в 50 раз.
Ой, опять... не тошни уже вот этим, плиз.
Каждый раз когда ты что-то эдакое совсем уж упоротое вещаешь, я обязательно нахожу тонны твоих недоговорённостей в изначальном посыле и со скукой смотрю затем на тщательную спекуляцию поверх этой недоговорённости. ))
По-другому еще не было ни разу, так что, предлагаю доморощенному манипулятору малость расслабиться и не смущать неподготовленного читателя всякой ахинеей.
"Трюкач" помнишь?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Единственный способ обойтись без распределенных транзакций — идемпотентность и асинхронная обработка.
Ес-но.
Но для этого нужны прикладные "знания" о характере данных (т.е. о неких гарантиях, простой пример — о неизменности данных за вчерашнее число).
РСУБД такими "знаниями" не обладает.
В итоге, обсуждаемое ручное "допиливание" пляшет как раз вокруг подобных "знаний".
Здравствуйте, nekocoder, Вы писали:
C>>Можно сказать по-другому: РСУБД остались там, где производительность не важна или нет больших объёмов данных. N>Фейсбук работает на MySQL. Распределенном и вероятно модифицированном, но все же.
Слишком мало подробностей.
SQL-сервак можно использовать как "удобное хранилище" конкретного узла, т.е. SQL тут не значит ровным счётом ничего, если данные м/у узлами гоняются силами некоей внешней системы.
