Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>И что? Ты или пишешь в те ноды, из которых потом читаешь, или продаешь два билета на место. Про это как раз написано сразу после процитированного тобой блока.
CK>Вот не понял как ты такой вывод сделал, БД запускает раунд какого-нибудь mulit-paxos-а, точно также как при записи, только данные не меняются. CK>Ты когда свой MSSQL реплицируешь, то тоже самое может быть, если ты читаешь данные из реплики, КМК.
Ни одна РСУБД не занимается такой фигней. А все приложения построены на простом принципе — читаем и пишем в одну ноду. А реплики используются для отчетности.
CK>>>И BTW, у тебя данные будут храниться не на всех нодах а на %replication-factor% нодах (на пяти например), поэтому кворум ты будешь гонять не между всеми нодами а только между пятью. G>>Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты. CK>Когда у тебя единственный мастер твоего MSSQL кластера отвалится ничего не застопроится, надо понимать?
Да, потому что там failover. Максимум 90 сек на восстановление. А еще и синхронный коммит есть, чтобы данные не терять.
CK>Вот давай на примере HBase (чтобы быть конкретным). Ты пишешь в регион (ака шард) который хранится на трех data node-ах HDFS, одна из которых отвалилась. На самом деле запись пройдет, т.к. данные пишутся в WAL (который тоже хранится в HDFS). HDFS перераспределит данные между оставшимися нодами рано или поздно. Если отвалится data node, на которой крутится region server, то запись не пройдет пока регион, в который ты пишешь, не переместится на другой region server (что вполне логично).
Ключевое выделил. Это "рано или поздно" как раз позволяет продать два билета на одно место если ты можешь прочитать из той ноды, для которой запись наступила "поздно".
CK>Если вернуться к примеру с билетами, я бы выбрал такую схему для hbase — каждый концерт, это отдельный ряд в hbase. Каждому месту соответствует отдельная колонка. Каждаый ряд в зале — отдельный column family (т.к. люди редко покупают билеты сразу в несколько рядов). Запись по одному ключу в hbase — атомарна, т.е. я могу сколько угодно билетов купить без нарушения целостности. Все что можно прочитать в HBase записано на диск (т.е. в HDFS с репликацией). Можно записывать транзакционно с помощью checkAndMutate, этого достаточно для того, чтобы проверить перед записью, что билет не куплен. Т.е. по сути, ни одна из проблем, описанных тобою выше, не имеет место и решение тривиально.
Я не силен в hbase, поэтому архитектуру комментировать не могу. Но если checkAndMutate от разных клиентов приходят в разные ноды, то ты продашь два билета на место. А если в одну, то твое решение ничем не лучше РСУБД. Если у тебя есть еще middleware, который от приложения скрывает кухню с разными нодами, то твое решение гарантированно хуже РСУБД.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>Выяснили уже что это не движок делает, а middleware. Middleware с такими функциями можно построить поверх любой субд. CK>зависит от БД, обычно все же этим БД занимается, т.к. движок БД должен знать где какой шард хранится, чтобы иметь возможность писать/читать
Я вот погугли монгу, сам движок не занимается, это отдельный middleware (mongos).
G>>SQL Azure умеет не хуже. Даже лучше во многих местах. CK>SQL Azure КМК не совсем СУБД, там скорее всего либо ограничения на транзакции/консистентность (как PNUTS, где транзакции работают только внутри таблиц), либо там не очень с масштабированием. Я правда никогда на эту БД не смотрел.
Конечно ограничения на транзакции. Консистентностью никто в здравом уме жертвовать не будет без прямого указания программиста.
В этом и суть. Любую РСУБД можно масштабировать добавляя некоторые ограничения. С NoSQL базами то же самое.
G>>И что это дает? G>>Внезапно за земле cattle имеет слишком большой оверхэд. CK>это дает современные девопс практики, автоматизация операций, запустили скрипт, изменили размер кластера, упала нода, просто убили ее и запустили новую и тд
Ага, для этого нужно еще железо и еще софт.
CK>что значит "на земле"?
"На земле" означает что ты платишь за железо, обслуживание и администрирование.
G>>Потому что с гарантией записи все преимущества nosql баз теряются, она начинают работать не быстрее взрослых субд. CK>безосновательное утверждение, давай на примерах чтоли? вот hbase например, гарантии записи есть, работает быстро даже на очень больших данных
В clustered columnstore indexes в MS SQL тоже есть. И по скорости CCI порвет hbase как тузик грелку.
G>>И? Ты теперь считаешь этот пример показательным? Вот ты на сайте RSDN. Нагрузка немаленькая, железо не космическое и таблицы нормализованные.
CK>У РСДН смешная аудитория
А у stackoverflow? Там тоже таблиц нормализованные.
CK>сайт, который я имел ввиду, это классифайд (один из крупнейших в РФ), по которому пользователи (порядка миллиона уников) непрерывно ищут товары со всякими хитровывернутыми фильтрами. При этом скорость выборки очень критична (пользователи теряют интерес к шопингу очень быстро, если сайт тупит над запросами по пол секунды).
По скольким позициям идет поиск?
Зачем делать запросы к транзакционной базе — поисковые индексы есть для поиска. И пофиг в целом, что они работают с лагом 5-10 минут.
Здравствуйте, gandjustas, Вы писали:
G>А если бы надо было несколько за раз ПБ обработать, то появилось бы несколько серверов, они бы прожевали каждый свой кусок данных, а потом в каком-нить middleware промежуточные результаты были бы объединены.
Здравствуйте, Cyberax, Вы писали:
S>>Вы точно уверены, что Амазон держит полмиллиарда запросов в секунду? C>Да. В этом году примерно столько и было.
То есть каждый житель США делал более 1 запроса в секунду? Чето мне кажется весь земной шар не генерирует такое количество запросов.
V>>>Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты". G>>Ага, это и называется WAL в ручную поверх NoSQL.
V>Не важно как это называется.
Ну если ты знаешь название, то понимаешь, что изобретаешь велосипед.
V>Важно отсутствие локов в нескольких таблицах одновременно.
Их и не было. В сценарии продажи билетов только одна таблица.
V>Все эти сценарии можно свести к тому, что в каждый момент времени лочится ровно одна запись.
Ок, сведи.
Напоминаю сценарий: один клиент покупает места 9 и 10, а другой 10 и 9. Клиенты делают это параллельно, независимо, друг о друге не знают.
V>Создай master-документ в состоянии "Initializing" — никто его менять не будет, пока он в этом состоянии. V>Неспешно напихай к нему slave-строки и остальные зависимые сущности. V>Тоже пихай без одновременной блокировки половины базы, а сугубо построчно.
Как это поможет. Два клиента создают каждый свой документ и пихают туда данные о покупке билетов.
V>Как закончишь, попытайся атомарно изменить состояние только лишь master-документа, т.е. одной всего записи.
То есть всё-таки нужна атомарность? Теперь осталось мелочь. Как атомарность совместить с горизонтальным масштабированием?
Или мы говорим о том, что все чтения и записи приходят в одну ноду?
V>>>В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия. G>>Ты сам понял что написал?
V>Я-то понял, бо последние лет 8 плотно занят именно lock-free алгоритмами.
И 0 лет базами данных
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>А если бы надо было несколько за раз ПБ обработать, то появилось бы несколько серверов, они бы прожевали каждый свой кусок данных, а потом в каком-нить middleware промежуточные результаты были бы объединены.
CK>Поздравляю, ты изобрел MR и Hadoop!
Это не я изобрел. Это работало еще задолго до "изобретения" MR и Hadoop.
А теперь вопрос — зачем нужен hadoop?
Здравствуйте, paucity, Вы писали:
P>В итоге получатся (в свете субжекта этой дискуссии), что, собственно, не NoSQL "победил" сам по себе, а тонна кастомного кода
В одной отдельно взятой кастомной задаче )
Здравствуйте, Sharov, Вы писали:
V>>Такая же точно. V>>Суть лок-фрии алгоритмов примерно такова: V>>1. прочитать текущее состояние; V>>2. сформировать следующее; V>>3. попытаться атомарно обновить текущее состояние, если не было изменений; V>>4. если были изменения, goto (1).
S>С этим я не спорю (про lock-free). Я не очень понимаю аналогию с очередями и ACID? Если у нас [b]одна/b] очередь и много микросервисов(бд), то это равносильно одному потоку, который по очереди с ними что-то делает, S>и если всё успешно, то ок, иначе повтор.
Суть в том, что п.п. 1 и 3 — относительно легковесные.
А тяжеловесная операция 2 заведомо не вызывает конфликтов, т.е. обладает произвольным параллелизмом.
Здравствуйте, gandjustas, Вы писали:
V>>Классика жанра же: V>>Image: smngoz6r70gecjbhs.bbbb4a9b.jpg G>А при чем тут кэш? Ты просто все известные слова решал написать?
А что есть кеш, по твоему?
G>Я тебе напомню исходный вопрос: G>
G>Что ты имеешь ввиду под "нормально кешировать данные" и какая РСУБД этого не умеет?
G>И тут второй вопрос родился. Как репликация связана с кэшем?
Ср-вами РСУБД масштабирование кешей выполняется через инструмент репликации.
Здравствуйте, gandjustas, Вы писали:
G>Только распределенные кэши не умеют оперировать данными, которые имеют объем более размера оперативной памяти. А 50ТБ оперативки это прям много.
Здравствуйте, gandjustas, Вы писали:
V>>Важно отсутствие локов в нескольких таблицах одновременно. G>Их и не было. В сценарии продажи билетов только одна таблица.
Как минимум две — "сеанс" и "места".
До какого-то порогового времени до начала сеанса можно резервировать.
В любом случае, тут о серьёзном масштабировании речи не идёт, т.е. кол-во сеансов и мест ничтожно.
V>>Все эти сценарии можно свести к тому, что в каждый момент времени лочится ровно одна запись. G>Ок, сведи. G>Напоминаю сценарий: один клиент покупает места 9 и 10, а другой 10 и 9. Клиенты делают это параллельно, независимо, друг о друге не знают.
Каждое место имеет несколько состояний "свободно", "в процессе резервирования", "продано".
Еще до попытки оплаты в процессе резервирования будет столкновение, каждому будет дан отлуп — будет предложено выбрать другое мн-во мест.
Первому сообщат, что занято 9-е место, а второму — что занято 10-е.
Проблемы пока не вижу.
V>>Создай master-документ в состоянии "Initializing" — никто его менять не будет, пока он в этом состоянии. V>>Неспешно напихай к нему slave-строки и остальные зависимые сущности. V>>Тоже пихай без одновременной блокировки половины базы, а сугубо построчно. G>Как это поможет. Два клиента создают каждый свой документ и пихают туда данные о покупке билетов.
Так и есть, оба создают "сделку" и пихают в неё билеты на места.
V>>Как закончишь, попытайся атомарно изменить состояние только лишь master-документа, т.е. одной всего записи. G>То есть всё-таки нужна атомарность?
Конечно. Речь же всегда о масштабе данных, требующих атомарности.
Например, размер созданного объекта в памяти может быть несколько килобайт, а атомарно изменить требуется лишь указатель на этот объект шириной в слово.
G>Теперь осталось мелочь. Как атомарность совместить с горизонтальным масштабированием?
С горизонтальным вообще легко — разнеси разные кинотеатры по разным сервакам.
G>Или мы говорим о том, что все чтения и записи приходят в одну ноду?
При партицировании?
Ты угадал.
Только не в "одну ноду", а в надёжный дублирующий кластер их.
Но логически это "одна нода".
V>>Я-то понял, бо последние лет 8 плотно занят именно lock-free алгоритмами. G>И 0 лет базами данных
Здравствуйте, gandjustas, Вы писали:
G>Я не силен в hbase, поэтому архитектуру комментировать не могу. Но если checkAndMutate от разных клиентов приходят в разные ноды, то ты продашь два билета на место. А если в одну, то твое решение ничем не лучше РСУБД.
Современные РСУБД не имеют достаточно развитых ср-в для автоматического партицирования.
Разворачивание и обслуживание таких систем на РСУБД дорого.
Более того, партицирование резко упрощает всё мн-во происходящих сценариев и навороченность РСУБД зачастую банальный оверкил.
G>Если у тебя есть еще middleware, который от приложения скрывает кухню с разными нодами, то твое решение гарантированно хуже РСУБД.
Звучит как ты хотел привести некий аргумент, но забыл.
Здравствуйте, gandjustas, Вы писали:
G>Ни одна РСУБД не занимается такой фигней. А все приложения построены на простом принципе — читаем и пишем в одну ноду. А реплики используются для отчетности.
самый популярный пример — zookeeper, там можно натурально гонять консенсус на чтение
hbase по другому работает, там данные делятся между регионами и за каждый регион отвечает один сервер (репликация работает на уровне hdfs) если secondary region servers не используются, поэтому нагрузка там распределяется между серверами
CK>>Вот давай на примере HBase (чтобы быть конкретным). Ты пишешь в регион (ака шард) который хранится на трех data node-ах HDFS, одна из которых отвалилась. На самом деле запись пройдет, т.к. данные пишутся в WAL (который тоже хранится в HDFS). HDFS перераспределит данные между оставшимися нодами рано или поздно. Если отвалится data node, на которой крутится region server, то запись не пройдет пока регион, в который ты пишешь, не переместится на другой region server (что вполне логично). G>Ключевое выделил. Это "рано или поздно" как раз позволяет продать два билета на одно место если ты можешь прочитать из той ноды, для которой запись наступила "поздно".
HBase не гарантирует availability, твой сетап тоже не гарантирует, но в случае hbase поломка одного region server-а не выведет из строя всю систему на 90 секунд, большая часть данных будет оставаться доступной еще до того как произошел failover (занимает меньше минуты, большая часть этого времени — таймаут region server-а), регион, region server которого отвалился, будет доступен после фейловера.
При этом, даже при failover тебе гарантируется strong consistency и ничего два раза продано не будет.
G>Я не силен в hbase, поэтому архитектуру комментировать не могу. Но если checkAndMutate от разных клиентов приходят в разные ноды, то ты продашь два билета на место. А если в одну, то твое решение ничем не лучше РСУБД. Если у тебя есть еще middleware, который от приложения скрывает кухню с разными нодами, то твое решение гарантированно хуже РСУБД.
Они приходят в одну ноду, если обрабатывают один и тот же ключ. Это лучше РСУБД тем, что билеты на разные концерты могут храниться/обрабатываться на разных серверах. У тебя все будет идти через мастер, если он отвалится, то все будут ждать.
Здравствуйте, Cyberax, Вы писали:
IB>>Как известно, когда в руках молоток, то все вокруг кажетя гвоздями )) C>См.: РСУБД.
Причем здесь РСУБД? С ними никто не носится как с писаной торбой пытаясь запихнуть в каждый сценарий )
C>Ага, и самый популярный язык — PHP.
То есть NoSQL все-таки не победили? Ну ок, тогда можно и закончить )
Здравствуйте, Cyberax, Вы писали:
C>Где конкретно, например, в Амазоне не критична целостность?
Понятия не имею ) Амазон большой, много чего себе может позволить потерять )
IB>>Совершенно верно, поскольку у NoSQL порог входа сильно ниже, чем во взрослую БД (в РСУБД все-таки нужна хоть какая-то квалификация) C>Это совершенно не так.
Это совершенно так, почитай еще раз внимательно что я написал )
C> В РСУБД разберётся любая обезьяна, а "волшебно работающие" транзакции позволяют не думать о CAP и прочем. Правильное использование NoSQL — это намного более сложная задача, где часто нужны всякие хитрые решения с идемпотентностью, reconciler'ами и прочим.
Я писал про порог вхождения, а не про правильное использование — это разные вещи.
Ты совершенно прав, правильно использовать NoSQL — серьезная задача, но начать использовать сильно проще, чем классическую реляционку, что, собственно, усугубляет проблему.
Здравствуйте, gandjustas, Вы писали:
G>Я вот погугли монгу, сам движок не занимается, это отдельный middleware (mongos).
монга это плохой пример, хороший пример это скажем cassandra или cockroachdb и там и там это все куда глубже сидит
G>Конечно ограничения на транзакции. Консистентностью никто в здравом уме жертвовать не будет без прямого указания программиста. G>В этом и суть. Любую РСУБД можно масштабировать добавляя некоторые ограничения. С NoSQL базами то же самое.
Вопрос в количестве усилий. Ну и для многих задач wide column store куда лучше заходит, нежели реляционная модель, с точки зрения удобства.
G>В clustered columnstore indexes в MS SQL тоже есть. И по скорости CCI порвет hbase как тузик грелку.
это вообще другое, hbase это не чистая колоночная БД, это wide column store
и на чтение может и порвет, а вот на запись точно нет
G>А у stackoverflow? Там тоже таблиц нормализованные.
я хз какая там схема и почему сделали именно так
ну и я не утверждаю что всем нужно делать одинаково
CK>>сайт, который я имел ввиду, это классифайд (один из крупнейших в РФ), по которому пользователи (порядка миллиона уников) непрерывно ищут товары со всякими хитровывернутыми фильтрами. При этом скорость выборки очень критична (пользователи теряют интерес к шопингу очень быстро, если сайт тупит над запросами по пол секунды).
G>По скольким позициям идет поиск?
я точно не помню, позиций не очень много, активных порядка ста тысяч (ЕМНИП), в таблице порядка тысячи столбцов, фильтрация может выполняться по сотням из них
G>Зачем делать запросы к транзакционной базе — поисковые индексы есть для поиска. И пофиг в целом, что они работают с лагом 5-10 минут.
Здравствуйте, Cyberax, Вы писали:
C>Замечательно! Можно показать РСУБД, которая выдержит нагрузку типичного проекта в Амазоне?
Остановись, там речь шла не про нагрузку, а про отказоустойчивость. =)
А про нагрузку — давай Амазоновскую команду и она мне любую РСУБД до такого же состояния доведет. )
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты. S>Будет новый раунд корпуса, не более. Стопориться ничего не будет.
Количество раундов заранее сверху ограничено?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> О каких объёмах речь? g>> 10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж. AB>Объемы HBase/Hadoop/&Co начинаются от десятков-сотен ТБ (до первого ПБ это такой игрушечный кластер на десяток-другой серверов).
Что за данные и что за задача решается?
Мы уже победили, просто это еще не так заметно...
