Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Можешь подробнее?
V>По ссылке ходил?
Да, там про replica set. Какое отношение к кэширванию оно имеет?

Здравствуйте, gandjustas, Вы писали:

C>>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
G>Давай с этого места поподробнее. Как обеспечивается транзакционность счетчиков?
В другом сообщении описал.

C>>Транзакций нет, о них можно забыть. Есть только некоторые атомарные операции, которые работают на уровне одной записи.
G>Атомарные операции — не транзакции?
Они не затрагивают больше одной записи. В классических РСУБД терминах — ровно как autocommit.

G>И как работает атомарность при покупке нескольких товаров? Если два клиента заказывают два товара но в разной последовательности.
Нормально работают.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>О каких объёмах речь?
G>>10 миллиардов строк — 40 ТБ данных на ms sql. На ОДНОМ сервере, работает нормально. Там правда охренеть какой сторедж.

V>"Одноклассники" обрабатывают в пике до миллиона запросов в секунду при объеме даных на сегодня в 50 ТБ.
Каждый запрос обрабатывает все 50 ТБ ? Или ты просто так цифры привел?

V>Никакая РСУБД в "чистом виде" это не потянет.
Миллион запросов в секунду — это каких запросов? Обычная СУБД может и миллион в секунду потянуть, если будет достаточно памяти, дисков и ядре процессора.

Только если надо миллон раз в секунду обрабатывать 50ТБ, то тут уже никто не справится.

Здравствуйте, gandjustas, Вы писали:

C>>С чего бы? А кто будет обеспечивать переходные процессы, при resharding'е или failover'у?
G>failover и шардинг вещи ортогональные.
Один шард очень горячий и должен быть разбит. Кто будет это делать?

G>>>Автоматически перераспределить данные при появлении нового шарда — это какая из NoSQL баз умеет?
C>>Все? Mongo, DynamoDB — точно.
G>Это с помощью middleware делается. Поверх postgres я видел аналогичную мидлварь, увы не могу вспомнить название.
Можно сцылки?

C>>Да. Чтобы при повышении нагрузки приложение не тормозило. Новые узлы берутся из облака или пула свободных хостов (если on-premise).
G>Если мы говорим об облаке, то в SQL Azre есть elastic scale.
Да-да. Oracle так же говорил про RAC. Только это всё чистая и наглая ложь, РСУБД не масштабируются без потери ACID.

C>>TPC-C — это вообще смех на палочке. Я уже привёл примеры масштаба — у Амазона хранилище выдерживает миллионы запросов в секунду. Это почти на три порядка больше, чем лучший результат TPC-C.
G>Соре, но амазон один такой. Его пример вовсе не является оптимальным для других систем.
Не один. Таких задач полно.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Итак простой пример зачем нужен ACID:

G>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>>В итоге твоя система с легкостью продает два билета на одно место.

V>Не продаёт.
Да-да, только я вживую видел как подобная система делала две подтверждающих транзакции во внешней системы вместо одной. Хорошо что это не списывание денег было, но просто отправка писем.

V>Такие операции работают через подтверждение, т.е. максимум что страшного можеть случиться — две операции будут поставлены в очередь на обработку, хотя одну из них можно было в очередь превентивно не ставить. Ну и потом, кто будет второй, тому придёт отлуп "ай нет, сорри, все-таки уже продали билеты".
Ага, это и называется WAL в ручную поверх NoSQL.
А потом еще наступает понимание, что нужны еще и транзакции на несколько строк\документов.

V>На очередях прекрасно можно реализовать ACID, не лоча при этом единовременно все сущности.
V>Собсно, суть всех lock-free алгоритмов примерно такая же.
Да-да, и все эти алгоритмы уже реализованы в РСУБД в механизме ЛОГА.

V>В этом смысле РСУБД обеспечивает столкновение на условных мьютексах, а система с очередями — на условных "неподвижных точках", которые крутятся вокруг некоего прикладного условия.
Ты сам понял что написал?


Для пользователя все равно мьютексы так или еще что-то. Билеты или проданы или нет — это пользователю важно.

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, gandjustas, Вы писали:

g>> AB>Объемы HBase/Hadoop/&Co начинаются от десятков-сотен ТБ (до первого ПБ это такой игрушечный кластер на десяток-другой серверов).
g>> Что за данные и что за задача решается?

AB>Ну... Каждый использующий решает свои задачи — стек Hadoop достаточно развесист в плане компонентов и их возможных комбинаций, по этому число решаемых задач может быть очень велико.
Так у вас есть конкретные задачи которые так решаются или только абстрактные сведения?


AB>Цитата: "Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства." (это про YT, но для обсуждаемого вопроса не принципиально).
Ключевое выделил.

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, gandjustas, Вы писали:

G>>Что значит "шардинг в автоматическом режиме" ?
CK>это когда шарды перемещаются на новые ноды в автоматическом режиме
Выяснили уже что это не движок делает, а middleware. Middleware с такими функциями можно построить поверх любой субд.

G>>Что значит "автоскейлинг" ?
G>>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться?

CK>NoSQL базы легко масштабируются (ваш кэп), обычно автоскейлинг работает так, пишем скрипт, который по ряду параметров (load average, latency) решает что ресурсов мало и разворачивает новые инстансы, после чего указывает субд на них. то же самое делается для даунскейлинга. С EC2 + CloudWatch это все довольно тривиально. Попробуй сделать что-то похожее со своей РСУБД.
SQL Azure умеет не хуже. Даже лучше во многих местах.
А что касается наземной, а не облачной истории, то выгоднее тупо больше железа зарезервировать под СУБД.

CK>Нормальная NoSQL СУБД это cattle, инстансы там могут появляться/исчезать довольно легко, большинство РСУБД это pets.
И что это дает?
Внезапно за земле cattle имеет слишком большой оверхэд.


G>>Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
CK>с чего ты взял что нет гарантии записи на диск?
Потому что с гарантией записи все преимущества nosql баз теряются, она начинают работать не быстрее взрослых субд.

G>>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. Мамкин хайлоад с базой на 30 гб, где большая денормализованная таблица и джоины силами приложения, там и рядом не валялся.
CK>я видел веб проект с милионной аудиторией на РСУБД, где база использовалась именно так
И? Ты теперь считаешь этот пример показательным? Вот ты на сайте RSDN. Нагрузка немаленькая, железо не космическое и таблицы нормализованные.

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, gandjustas, Вы писали:

G>>Ты не представляешь глубину всей глупости, которую написал.

CK>фи

G>>Итак простой пример зачем нужен ACID:

G>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>>В итоге твоя система с легкостью продает два билета на одно место.

G>>Ты получил по шапке за такую архитектуру и начал переделывать. Затребовал "кворум" при записи, чтобы 50%+1 одна нода возвращали что данные записаны. Система стала гораздо тормознее.
G>>А все равно продаются по два билета. Потому что запись идет на 51 одну ноду, но данные читаются из остальных 49. И тут ты понял что тебе нужна атомарность (A из ACID).

CK>Есть такая штука, consistent read называется. Система гоняет кворум не только на запись но и на чтение.
И что? Ты или пишешь в те ноды, из которых потом читаешь, или продаешь два билета на место. Про это как раз написано сразу после процитированного тобой блока.


CK>И BTW, у тебя данные будут храниться не на всех нодах а на %replication-factor% нодах (на пяти например), поэтому кворум ты будешь гонять не между всеми нодами а только между пятью.
Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты.

Здравствуйте, Cyberax, Вы писали:

C>Проблема с консенсусом в том, что он должен запускаться при чтении, а не записи. Соответственно, это слишком дорого.

И? Рано или поздно консенсус же должен отработать. Где проблема-то?

Здравствуйте, gandjustas, Вы писали:

G>Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты.

Будет новый раунд консенсуса, не более. Стопориться ничего не будет.

Здравствуйте, Cyberax, Вы писали:

WH>>Как конкретно такое не допускается если счётчики товаров лежат в разных шардах?
C>С помощью идемпотентных изменений. Чем-то напоминает транзакции, да.
C>Проблема в том, что при классических распределённых транзакциях блокировки должны проходить через центральный узел (который умрёт) или будут требоваться оптимистические блокировки с повторами (привет экспоненте).

Какие-то взаимоисключающие параграфы.

Итак, у тебя есть заказ на товар А и Б. Счетчики лежат в разных шардах. Тебе их надо одновременно два уменьшить.
Куда будет отправляться идемпотентная команда, уменьшающая каждый из них, чтобы у тебя не возникло гонки с другой транзакцией также содержащей товары А и Б?

Здравствуйте, Cyberax, Вы писали:

C>>>Транзакций нет, о них можно забыть. Есть только некоторые атомарные операции, которые работают на уровне одной записи.
G>>Атомарные операции — не транзакции?
C>Они не затрагивают больше одной записи. В классических РСУБД терминах — ровно как autocommit.

G>>И как работает атомарность при покупке нескольких товаров? Если два клиента заказывают два товара но в разной последовательности.
C>Нормально работают.

Не юли, а ответь на вопрос.
Есть две параллельные транзакции на товары А и Б. Счетчики в разных шардах, как обеспечивается их атомарное уменьшение?

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

C>>>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
G>>Давай с этого места поподробнее. Как обеспечивается транзакционность счетчиков?
C>В другом сообщении описал.

И ответь всетаки чем из CAP жертвуется? Я так понимаю что availability.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты.
S>Будет новый раунд корпуса, не более. Стопориться ничего не будет.
Количество раундов заранее сверху ограничено?

Здравствуйте, jazzer, Вы писали:

WH>>>Если их нет, то как идёт обработка ситуации что одного из нескольких товаров не оказалось на складе?
C>>Такого не допускается. Счётчики товара строго транзакционны. То как оно обеспечивается — отдельная и длинная история.
J>рассказывай
Счётчики разделены между шардами, при этом каждый шард получает квоту на запись. Т.е. если у нас 10000 разрешений (скажем, товаров на складе) и 5 шардов, то каждый шард может автономно выдать 2000 разрешений.

Текущее общее значение оставшихся разрешений — eventually consistent и неспешно синхронизируется между шардами.

Естественно, при низких значениях доступных разрешений нужна особая обработка — в опустевшие шарды добавляется "перенаправление" на шарды с ещё оставшимися разрешениями. Там тоже интересный алгоритм, который этим занимается.

Сами счётчики организованы как множества транзакций. Т.е. операция "взять разрешение" выглядит как "записать ID операции в множество завершённые_операции и уменьшить значение счётчика, если ID операции не в множестве завершённые_операции и счётчик больше нуля". Это гарантирует идемпотентность операции, её можно повторять произвольное число раз. Соответственно, откат выглядит как обратная операция и он тоже идемпотентный.

Когда транзакция полностью завершена, ID операции убирается из множества "завершённые_операции". ID операции так же состоит из времени начала операции и уникального случайного 64-битного числа, так что специальная задача (reconciler) в фоновом режиме сканирует все счётчики и вычищает транзакции, которые длятся слишком долго.

Ещё есть очень интересная оптимизация — идемпотентные операции можно безопасно группировать, что невозможно с классическими транзакциями. Так что когда шард получает запрос, он не выполняет его сразу же, а кладёт в очередь и начинает ждать ответа. И каждые 10-20 миллисекунд накопившиеся в очереди запросы всей пачкой выполняются, и результаты отдаются ждущим клиентам. Таким образом, количество операций получается ограничено интервалом времени, при сбросе значений каждые 20 мс. у нас всего 50 операций записи в секунду.

Это так по верхам, самые интересные части.

Здравствуйте, gandjustas, Вы писали:

G>>>Давай с этого места поподробнее. Как обеспечивается транзакционность счетчиков?
C>>В другом сообщении описал.
G>И ответь всетаки чем из CAP жертвуется? Я так понимаю что availability.
Consistency. Она обеспечивается частично — есть гарантия того, что нельзя продать больше товаров, чем есть на складе. Но нет гарантии, что клиент может купить товар, если товар ещё доступен.

Здравствуйте, Cyberax, Вы писали:

C>Счётчики разделены между шардами, при этом каждый шард получает квоту на запись. Т.е. если у нас 10000 разрешений (скажем, товаров на складе) и 5 шардов, то каждый шард может автономно выдать 2000 разрешений.

C>Текущее общее значение оставшихся разрешений — eventually consistent и неспешно синхронизируется между шардами.

C>Естественно, при низких значениях доступных разрешений нужна особая обработка — в опустевшие шарды добавляется "перенаправление" на шарды с ещё оставшимися разрешениями. Там тоже интересный алгоритм, который этим занимается.

C>Сами счётчики организованы как множества транзакций. Т.е. операция "взять разрешение" выглядит как "записать ID операции в множество завершённые_операции и уменьшить значение счётчика, если ID операции не в множестве завершённые_операции и счётчик больше нуля". Это гарантирует идемпотентность операции, её можно повторять произвольное число раз. Соответственно, откат выглядит как обратная операция и он тоже идемпотентный.

C>Когда транзакция полностью завершена, ID операции убирается из множества "завершённые_операции". ID операции так же состоит из времени начала операции и уникального случайного 64-битного числа, так что специальная задача (reconciler) в фоновом режиме сканирует все счётчики и вычищает транзакции, которые длятся слишком долго.

C>Ещё есть очень интересная оптимизация — идемпотентные операции можно безопасно группировать, что невозможно с классическими транзакциями. Так что когда шард получает запрос, он не выполняет его сразу же, а кладёт в очередь и начинает ждать ответа. И каждые 10-20 миллисекунд накопившиеся в очереди запросы всей пачкой выполняются, и результаты отдаются ждущим клиентам. Таким образом, количество операций получается ограничено интервалом времени, при сбросе значений каждые 20 мс. у нас всего 50 операций записи в секунду.

C>Это так по верхам, самые интересные части.

В итоге получатся (в свете субжекта этой дискуссии), что, собственно, не NoSQL "победил" сам по себе, а тонна кастомного кода

Здравствуйте, gandjustas, Вы писали:

g> Так у вас есть конкретные задачи которые так решаются или только абстрактные сведения?

У меня есть конкретные, но без разглашения подробностей.

g> AB>Цитата: "Поисковые логи и индексы, пользовательские данные, картографическая информация, промежуточные данные и результаты алгоритмов машинного обучения — все это может занимать сотни петабайт дискового пространства." (это про YT, но для обсуждаемого вопроса не принципиально).
g> Ключевое выделил.

Ты же понимаешь, что это всего лишь фигура речи и оно там реально столько занимает? Если хочешь конкретных цифр, например вот для ClickHouse речь идет про 17 ПБ "сырых" данных без дублирования и репликации (и это было 4 года назад, и только для одной из подсистем, если верить написанному).

Здравствуйте, Cyberax, Вы писали:

C>Счётчики разделены между шардами, при этом каждый шард получает квоту на запись. Т.е. если у нас 10000 разрешений (скажем, товаров на складе) и 5 шардов, то каждый шард может автономно выдать 2000 разрешений.

C>Текущее общее значение оставшихся разрешений — eventually consistent и неспешно синхронизируется между шардами.

C>Естественно, при низких значениях доступных разрешений нужна особая обработка — в опустевшие шарды добавляется "перенаправление" на шарды с ещё оставшимися разрешениями. Там тоже интересный алгоритм, который этим занимается.

Этот интересный алгоритм в студию, а то опять все простенькое как рокетсайнс выдают.
Вот как вы обеспечиваете раздачу пряников на шарды?

C>Это так по верхам, самые интересные части.
Как раз наоборот

Здравствуйте, Sharov, Вы писали:

C>>Проблема с консенсусом в том, что он должен запускаться при чтении, а не записи. Соответственно, это слишком дорого.
S>И? Рано или поздно консенсус же должен отработать. Где проблема-то?
Проблема в том, что для consistent-транзакций консенсус надо запускать при чтении данных, а не записи.

Т.е. в природе нет consistent write, есть только consistent read.