Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
CK>>>РСУБД по прежнему не могут в шардинг в автоматическом режиме, не могут в автоскейлинг. G>>Что значит "шардинг в автоматическом режиме" ? G>>Выбрать инстанс на который писать данные в зависимости от параметров — это вообще не задача СУБД, это задача клиентской библиотеки и подобный решений вагон и маленькая тележка. C>С чего бы? А кто будет обеспечивать переходные процессы, при resharding'е или failover'у?
failover и шардинг вещи ортогональные.
G>>Автоматически перераспределить данные при появлении нового шарда — это какая из NoSQL баз умеет? C>Все? Mongo, DynamoDB — точно.
Это с помощью middleware делается. Поверх postgres я видел аналогичную мидлварь, увы не могу вспомнить название.
G>>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться? C>Да. Чтобы при повышении нагрузки приложение не тормозило. Новые узлы берутся из облака или пула свободных хостов (если on-premise).
Если мы говорим об облаке, то в SQL Azre есть elastic scale.
Если мы говорим про наземный вариант, то тупо проще зарезервировать мощности под СУБД.
G>>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. Мамкин хайлоад с базой на 30 гб, где большая денормализованная таблица и джоины силами приложения, там и рядом не валялся. C>TPC-C — это вообще смех на палочке. Я уже привёл примеры масштаба — у Амазона хранилище выдерживает миллионы запросов в секунду. Это почти на три порядка больше, чем лучший результат TPC-C.
Соре, но амазон один такой. Его пример вовсе не является оптимальным для других систем.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> О каких объёмах речь? g>> 10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж. AB>Объемы HBase/Hadoop/&Co начинаются от десятков-сотен ТБ (до первого ПБ это такой игрушечный кластер на десяток-другой серверов).
Что за данные и что за задача решается?
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
G>>В MS SQL Server есть clustered columnstore indexes. Друид и прочие "column oriented written in java" неврно курят в сторонке. G>>И это еще "детский" уровень. Потому что у взрослых РСУБД есть в свои системы аналитики, рядом с которыми Druid выглядит как поделка.
С>С интересом выслушаю ваше мнение — зачем в Яндексе применяют Apache Cassandra.
Я понятия не имею зачем. Может просто потому что могут. Может кэш или еще что-то. Но уж точно не для хранения транзакционных данных.
Здравствуйте, Gattaka, Вы писали:
G>Я вас удивлю, но жесткий диск далеко не единственный способ оставить свои данные в сохранности. Более надежная фишка — сеть. Т.е. вместо того чтобы писать на медленный диск. Вы отправьте инфу по сети 100 нодам. Даже если 90 нод потеряет ее (что невероятно с точки зрения теории вероятности) вы сохраните информацию. Причем на 10 нодах. А не на одном паршивом диске. Скорость при этом небо и земля. Просто неспопоставимы по скорости диск и сеть. Сеть быстрее. И зачем нужен этот ваш ACID?
Ты не представляешь глубину всей глупости, которую написал.
Итак простой пример зачем нужен ACID:
Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
В итоге твоя система с легкостью продает два билета на одно место.
Ты получил по шапке за такую архитектуру и начал переделывать. Затребовал "кворум" при записи, чтобы 50%+1 одна нода возвращали что данные записаны. Система стала гораздо тормознее.
А все равно продаются по два билета. Потому что запись идет на 51 одну ноду, но данные читаются из остальных 49. И тут ты понял что тебе нужна атомарность (A из ACID).
Прикрутил affinity, чтобы данные одного сеанса шли на одну ноду. То есть полностью похерил всю "фишку" с сетью, но ладно, у тебя данные в памяти и все быстро, а для "надежности" у тебя все равно запись в несколько узлов\зеркал.
Но билеты все равно по два продаются. Оказывается что между чтением состояния и записью проходит время и параллельные операции могут "одновременно" прочитать что билеты не проданы, а потом записать что проданы.
Оказывается нужны констрейны и согласованность (С в ACID), чтобы такого не было.
Ну ок, собрал свой optimistic locking и WAL поверх NoSQL на каждое место (тормозит шопипец), записал в логику ограничений в "хранимые процедуры". Но все равно фигня происходит, когда параллельно пытаются купить билеты на два места, один клиент покупает 10е и 11е, а второй 11е и 10е.
То два билета на место, то дедлоки возникают. Тут ты понимаешь что тебе нужна независимость транзакций (I в ACID).
Наконец ты прикрутил транзакции поверх NoSQL. Это работает в 10 раз медленнее чем MS SQL, хотя пишется на диск не сразу. Только ноды у тебя падают, и после падения случается, что обращения происходят к ноде, которая часть записей до этого потеряла. И ты опять продаешь несколько билетов на одно место.
Когда тебя увольняют за профнепригодность, ты понимаешь что тебе изначально нужна была долговечность записи (D в ACID).
Я уже писал в одной из тем, что ACID это не прихоть инженеров, а здравый смысл людей. Ты не можешь сделать не ACID систему, если она хранит не-мусор.
Максимум что ты можешь сделать это ослабить требования ACID, там где потребитель не увидит разницы или вынести часть сложностей на другой уровень.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, WolfHound, Вы писали:
C>>>Никаких распределённых транзакций, естественно, нет. Они просто нереальны при таких нагрузках. WH>>Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе? C>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
Давай с этого места поподробнее. Как обеспечивается транзакционность счетчиков?
WH>>Часть шардов уже уменьшила счётчики, а один сказал, что товар закончился. Что делать? WH>>Как откатить транзакцию? C>Транзакций нет, о них можно забыть. Есть только некоторые атомарные операции, которые работают на уровне одной записи.
Атомарные операции — не транзакции?
Как атомарность дружит с твоей любимой CAP-теоремой? Чем жертвуют?
И как работает атомарность при покупке нескольких товаров? Если два клиента заказывают два товара но в разной последовательности.
Здравствуйте, Cyberax, Вы писали:
C>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
C>Транзакций нет, о них можно забыть. Есть только некоторые атомарные операции, которые работают на уровне одной записи.
Здравствуйте, Cyberax, Вы писали:
WH>>Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе? C>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
Как конкретно такое не допускается если счётчики товаров лежат в разных шардах?
C>А нету ACID в РСУБД, это просто фантазии DBA, которые не видели ничего дальше БД на одной машине.
Ну на одной машине то он не одно десятилетие есть.
А имея ACID на одной машине можно легко сделать ACID на кластере.
C>>>С шардингом, репликацией, танцами с бубном, облаком супер-пупер-DBA и инженеров из Oracle. Смогли победить, лишь разрешив запись с небольшого числа узлов и переведя все остальные в read-only. WH>>Звучит как одна база, запущенная на нескольких машинах. WH>>А шарды это когда базу разрезают на несколько кусков. C>Так именно так и делают. Базу режут на части, и дополнительно части хранят в нескольких экземплярах.
Что-то ты недоговариваешь. Или просто говоришь про то о чём слышал через несколько рук.
Ибо если база разрезана, то никакого взрывного роста трафика быть не может.
Ему просто взяться неоткуда.
Я ессно предполагаю, что у вас там систему не конченные идиоты делали.
WH>>Тут алгоритм распределённого консенсуса виноват. C>Нет. Виновата необходимость сериализации транзакций.
Ох. А для сериализации транзакций нужен распределённый консенсус.
И именно старые алгоритмы распределённого консенсуса обладают свойством взрывного роста трафика.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandjustas, Вы писали:
G>О каких объёмах речь? G>10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж.
"Одноклассники" обрабатывают в пике до миллиона запросов в секунду при объеме даных на сегодня в 50 ТБ.
Никакая РСУБД в "чистом виде" это не потянет.
Здравствуйте, WolfHound, Вы писали:
WH>Ну максимум что туда можно положить это лайки, посты и фотки котиков.
Или любую другую информацию, задержка в распространении которой не критична.
Тем более, что задержки измеряются долями секунды.
Ну вот ты делаешь запрос "дайка мне аналитику на прямо сейчас", а по факту получаешь аналичтику не на прямо сейчас, а на пол-секунды назад.
Критично?
ИМХО, нет.
Здравствуйте, WolfHound, Вы писали:
WH>>>Ну максимум что туда можно положить это лайки, посты и фотки котиков. C>>Угу. И ещё сотни миллионов покупок на миллиарды долларов. WH>То есть цена потери транзакции десяток долларов.
А есть инфа по потерянным транзакциям?
WH>При такой цене можно терять десятки транзакций каждый день и всем будет плевать.
Здравствуйте, WolfHound, Вы писали:
AB>>Они не теряли данные и без ACID WH>Если нет ACID, то потеря данных вопрос времени.
Это вопрос вероятности.
Данные дублируются, живут распределённо в журналах и очередях на обработку.
РСУБД на несколько порядков чаще отказывает, чем потеряются данные в такой системе.
WH>Вот как раз монга и теряла. Брала и разваливалась.
MS SQL 6.0 тоже многократно чаще 7-ки отказывал, и?
Это вопрос конкретной реализации, а не принципа.
Здравствуйте, gandjustas, Вы писали:
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить. G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс. G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные. G>В итоге твоя система с легкостью продает два билета на одно место.
Не продаёт.
Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Отлуп придёт до списывания денег со счёта, ес-но.
На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
Собсно, суть всех lock-free алгоритмов примерно такая же.
В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.
Здравствуйте, gandjustas, Вы писали:
g> AB>Объемы HBase/Hadoop/&Co начинаются от десятков-сотен ТБ (до первого ПБ это такой игрушечный кластер на десяток-другой серверов). g> Что за данные и что за задача решается?
Ну... Каждый использующий решает свои задачи — стек Hadoop достаточно развесист в плане компонентов и их возможных комбинаций, по этому число решаемых задач может быть очень велико. Цитата: "Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства." (это про YT, но для обсуждаемого вопроса не принципиально).
Здравствуйте, gandjustas, Вы писали:
G>Что значит "шардинг в автоматическом режиме" ?
это когда шарды перемещаются на новые ноды в автоматическом режиме
G>Что значит "автоскейлинг" ? G>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться?
NoSQL базы легко масштабируются (ваш кэп), обычно автоскейлинг работает так, пишем скрипт, который по ряду параметров (load average, latency) решает что ресурсов мало и разворачивает новые инстансы, после чего указывает субд на них. то же самое делается для даунскейлинга. С EC2 + CloudWatch это все довольно тривиально. Попробуй сделать что-то похожее со своей РСУБД.
Нормальная NoSQL СУБД это cattle, инстансы там могут появляться/исчезать довольно легко, большинство РСУБД это pets.
G>Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
с чего ты взял что нет гарантии записи на диск?
G>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. Мамкин хайлоад с базой на 30 гб, где большая денормализованная таблица и джоины силами приложения, там и рядом не валялся.
я видел веб проект с милионной аудиторией на РСУБД, где база использовалась именно так
Здравствуйте, gandjustas, Вы писали:
G>Ты не представляешь глубину всей глупости, которую написал.
фи
G>Итак простой пример зачем нужен ACID:
G>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить. G>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс. G>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные. G>В итоге твоя система с легкостью продает два билета на одно место.
G>Ты получил по шапке за такую архитектуру и начал переделывать. Затребовал "кворум" при записи, чтобы 50%+1 одна нода возвращали что данные записаны. Система стала гораздо тормознее. G>А все равно продаются по два билета. Потому что запись идет на 51 одну ноду, но данные читаются из остальных 49. И тут ты понял что тебе нужна атомарность (A из ACID).
Есть такая штука, consistent read называется. Система гоняет кворум не только на запись но и на чтение. И BTW, у тебя данные будут храниться не на всех нодах а на %replication-factor% нодах (на пяти например), поэтому кворум ты будешь гонять не между всеми нодами а только между пятью.
Здравствуйте, Sharov, Вы писали:
C>>Amazon использует nosql везде, Google их использует ещё более везде. S>Не совсем чтобы везде, но да, скорее Ваша правда. S>(я вопрос тут задал. Очень крутой дядька)
Да, для Data Warehousing и аналитики используется SQL, но это всё не online даже близко.
Здравствуйте, WolfHound, Вы писали:
C>>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история. WH>Как конкретно такое не допускается если счётчики товаров лежат в разных шардах?
С помощью идемпотентных изменений. Чем-то напоминает транзакции, да.
C>>А нету ACID в РСУБД, это просто фантазии DBA, которые не видели ничего дальше БД на одной машине. WH>Ну на одной машине то он не одно десятилетие есть. WH>А имея ACID на одной машине можно легко сделать ACID на кластере.
Отсюда подробнее, пжалуста. Я зааааписываю.
C>>Так именно так и делают. Базу режут на части, и дополнительно части хранят в нескольких экземплярах. WH>Что-то ты недоговариваешь. Или просто говоришь про то о чём слышал через несколько рук. WH>Ибо если база разрезана, то никакого взрывного роста трафика быть не может. WH>Ему просто взяться неоткуда.
Проблема в том, что при классических распределённых транзакциях блокировки должны проходить через центральный узел (который умрёт) или будут требоваться оптимистические блокировки с повторами (привет экспоненте).
C>>Нет. Виновата необходимость сериализации транзакций. WH>Ох. А для сериализации транзакций нужен распределённый консенсус. WH>И именно старые алгоритмы распределённого консенсуса обладают свойством взрывного роста трафика.
Проблема с консенсусом в том, что он должен запускаться при чтении, а не записи. Соответственно, это слишком дорого.
