Здравствуйте, _ABC_, Вы писали:
_AB>Ну и почему у Вас тогда получается, что один сервер за 70 тысяч справляется хуже, чем три по пять?
Где же я такое писал? Я написал цитирую — "...разнесение с точки зрения уменьшения стоимости входа в эту стратегию (и возможно стоимости владения, но не факт), вам эффективнее использовать горизонтальное масштабирование (то бишь шардинг по русски ), чем вертикальное". Сервер за 70, 50 или даже 20k очевидно будет более эффективен (возможно гораздо более эффективен по производительности и стоимости владения, опять же в зависимости от условий), чем 3 по 1.5k. Но при всем этом вход самопальной горизонтальной системы будет ниже по деньгам, а возможности ее масштабирования никак не ниже чем у системы вертикального масштабирования.
_AB>Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый?
Вы ушли куда-то в сторону от темы. Если ставить так вопрос — то конечно DL385 G7 выйдет победителем. Я бы конечно мог сейчас с пеной у рта доказывать, что вот если силами моджахедов собрать в пакистане на коленке сервера с одним CPU, то это было бы еще круче, чем кастрированный DL385 G7, у которого какой-нибудь плюгавый мужик из HP при конфигурировании выдернул все что мог, но это пустая трата времени.
В общем, мой посыл был следующим — в некоторых случаях (не всегда) горизонтальное масштабирование будет эффективным чем вертикальное. Напр. с точки зрения снижения стоимости входа + возможно ROI. И это касается соврешенно разных систем — маленьких, средних, больших. Ваша фраза >"Рекомендация разносить данные на разные сервера, если их размер меньше десятков ГБ вызывает недоумение, особенно в разрезе песнопений об экономии на железе. >Зачем вообще может понадобиться разносить коллекцию, если её размер меньше, скажем, 10 Гб?"
по сути неверна, так как не учитывает все возможное многообразие задач. Приведу более простой пример из моей практики. В 2k3 разрабатывал одну web-систему — в бэкэнде был sql server 2k (лучшее решение на тот момент по произв./стоимость). Хотя данных было не очень много (около 5~7 Гб), OLTP-нагрузка для того времени была высокой, так что пришлось специально "хинтить", настраивать query governer и пинировать некоторые таблицы (ms-евангилисты, если вы это читаете срочно начинайте гуглить или бинговать эти страшные слова). Сервер хорошо держал нагрузку на OLTP, но поиск по БД (длинные запросы) убивал перфоманс напрочь; эскалация, массовый рост tempdb и скачки в RAM. Нашли быстрое решение — вынесли поисковые таблицы на отдельный mssql2k сервер, все стало super. Это ответ на ваш вопрос "зачем" ?
M>> Цитирую: M>> If the collection is small (less than say, 400MB) we recommend not bothering to shard it.
AB>Тоже разумная рекомендация, т.к. монга очень скорострельна на стандартных кейсах и шардинг маленьких коллекций может не иметь практического смысла.
Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
Здравствуйте, Mamut, Вы писали:
M> Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
Нет, где-то ниже объяснял, что до 400 — маленькие и обратного не следует. Все эти термины и числа условны исходя из банального здравого смысла.
Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
Здравствуйте, Anton Batenev, Вы писали:
AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте),
Какие, если не секрет?
AB>но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
То есть то, что писал gandjustas про mongo's global lock vs SQL's fine-grained locks, неверно?
Здравствуйте, dimgel, Вы писали:
d> AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), d> Какие, если не секрет?
На вскидку из того с чем сталкивался плотно:
* Низкое качество тестирования кода в результате чего релизы (хоть и частые) могут падать (или течь) в самом элементарном кейсе. Особенно это касается вспомогательных подсистем типа провайдера для PHP или nginx (это из тех, с которыми я имел дело — возможно, что и в других). Поправимо (ибо open source), но неприятно.
* Нагрузка на дисковую подсистему при перебалансироке и возникающие при этом эффекты с определением отказа ноды. Опять же не фатально, но нужен некоторый опыт эксплуатации, чтобы предвидеть и уметь справиться (на 3-м шарде такой опыт уже появляется).
* Каждый шард — это два сервера (а не один, как кажется в самом начале пути). Можно один, но неудобно в работе и рискованно.
* IPv6 (для меня достаточно актуально) — возможно, что сейчас ситуация поправилась, но в свое время тупо не работало.
Это из эксплуатации. С программированием как-то было все сильно проще за исключением разве что попытки эмуляции транзакционности (но тут сам боженька велел обломиться и согласиться на soft-вариант, который устроил).
d> AB>но они совершенно не в том шкафу, где пытаются их искать "крестоносцы" d> То есть то, что писал gandjustas про mongo's global lock vs SQL's fine-grained locks, неверно?
Возможно я пропустил, т.к. пришел поздно и ветка была уже большая.
Если речь идет об этом, то да, есть такое. На моей практике время блокировки на запись не превышает 0.5-0.6% от времени остальных запросов, по этому на моих кейсах эта особенность меня не беспокоит (но возможно, что у кого-то другой опыт).
M>> Ну да, ну да. Получается, что то, что больше 400 MB — это уже большие коллекции?
AB>Нет, где-то ниже объяснял, что до 400 — маленькие и обратного не следует. Все эти термины и числа условны исходя из банального здравого смысла.
Банальный зравый смысл показывает, что у того же Foursquare шарды на 64 гига, и что с нынешними объемами RAM'а "маленькие" коллекции начинаются, наверное, в районе гигабайта, а то и больше.
AB>Свои собственные скелеты в шкафу у монги есть (куда же без них, как и в любом другом продукте), но они совершенно не в том шкафу, где пытаются их искать "крестоносцы"
Я, вообще-то, говорю про другое Я говорю про то, что
_>Ужасы какие. Это же переделка всего. В то время как в случае nosql мы вообще ничего не трогаем проекте. Только запускаем новые сервера, правим конфиг и всё.
Ложь. Нет в NoSQL, которые позволяют сделать это настолько легко. Практически у всех или закат солнца вручную (типа банальной репликации копированием) или потеря потеря каких-либо важных свойств (типа половины букв в ACID).
Здравствуйте, Sinclair, Вы писали:
ANS>>Это ты так думаешь от того, что ты смотришь на сбой /мастера/ как на апокалипис, конец времени после которого уже не важно что там в БД за данные. Но при автофайловере такой сбой превращается в норму. И вот некая система видела данные, работала с ними, а потом трах-бах и не видит. Ну и какая это консистентность? S>И тем не менее, последовательность наблюдаемых изменений будет в такой системе одинаковой.
Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее. Единственный способ сохранить "Sequential Consistency" это будет запретить и чтение и запись. Практичность подобного решения сомнительна.
ANS>>Не важно ставим или нет. ACID система работает как единое целое, что повышает требования к коммуникационным каналам между нодами. S>Нет. Это вы себе придумали зачем-то. ACID построен на понятиях сериализуемости. Требования задавать общесистемные часы у ACID нету.
Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила.
S>>>С чего вы это взяли? Я же вам уже написал, что при таком подходе надо останавливать систему при падении вообще любой реплики, скольно бы их ни было. ANS>>Достаточно кворума. Т.е. получается при одном сервере его падение — катастрофа. При двух — падение слейва катастрофа. При трёх серверах для даунтайма нужно одновременное падение двух. S>Вы опять сами себе противоречите. При двух серверах падение любого получается катастрофа — ведь останется только один сервер! Значит, система из двух серверов неотказоустойчива. Тогда и три сервера вам ничем не помогут — ведь при падении одного из них останется только два, а неотказоустойчивость этой комбинации уже доказана. S>Я вам это уже в третий раз рассказываю, а вы игнорируете. Почему? Не совпадает с вашим шаблоном?
Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер".
S>>>Плохо работает, чего тут думать. Уменьшили латентность, получили потерю консистентности. На всякий случай: если отказаться от идеи пестовать split brain, то можно сохранить консистентность, ценой некоторого роста латентности. ANS>>Чего? S>Что конкретно вам непонятно? Вам непонятно, почему уменьшается латентность? Потому что европейским клиентам быстрее сбегать в европейский датацентр, чем в северную америку. Непонятно, почему возникает неконсистентность? Потому что мы разрешаем европейским клиентам работать со своей репликой, не извещая об этом американскую реплику. Непонятно, как сохранить консистентность? Элементарно — запрещать модификации при потере связи между датацентрами, или заставлять европейских клиентов ходить в американский датацентр. Непонятно, почему ухудшится латентность? Потому, что операции записи теперь будут стоить немножко больше. S>Если вам кажется, что запрет модификаций — это отказ от availability, то это тоже иллюзия. Потому, что бескомпромиссная availabilty вообще невозможна в распределённой среде. Ведь канал между серверами гораздо надёжнее канала между сервером и клиентом; а в случае падения последнего никакая избыточность на серверной стороне вас не спасёт. S>Вот поэтому-то CAP-теорема и является фуфлом: рассматриваемая ею модель слишком сферическая и слишком в вакууме. S>Для того, чтобы осмысленно рассуждать о нарушениях консистентности, доступности и связности, надо вводить более продвинутые модели. И сравнивать не абсолютные величины типа "есть"/"нету", а вероятности тех или иных событий.
Очень много рассуждений. Я только понял, что с твоей точки зрения это нормально, что пользователь работал работал, а потом после очередного рефреша у него пропали данные за 10 часов работы. И ACID это не противоречит.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее.
Ок, в такой схеме (если происходит фейловер для клиента, который работал с мастером на запись) — да, нарушается последовательность, это правда. С точки зрения теории кристалла, это частичное нарушение durability. Не очень важно то, что произошёл фейловер. С тем же успехом могло произойти восстановление из бэкапа — и с тем же результатом, "изменения за последние xxx секунд потеряны".
Нужно понимать, что схем, которые бы гарантировали 100% durability, в природе не существует. Кворум, на который вы так сильно уповаете, принципиально не лучше. Для него просто вероятность нарушения durability ниже. Это место вам понятно или нужно подробнее пояснять?
ANS>Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила.
На чём основана ваша уверенность? И зачем она вам нужна?
ANS>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер".
Поясните. Я не вижу ошибки.
ANS>Очень много рассуждений. Я только понял, что с твоей точки зрения это нормально, что пользователь работал работал, а потом после очередного рефреша у него пропали данные за 10 часов работы. И ACID это не противоречит.
Нет, это противоречит "математически строгому ACID". Да, это нормально. Я вам ещё раз объясню: схема, в которой данные не пропадают никогда, физически нереализуема. Всё, что можно сделать — это уменьшить плотность вероятности сбоя в единицу времени. Вы рассматриваете консистентность как булеву переменную. Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. Осмысленный подход — вводить вероятностные параметры системы — MTBF, MTBR, и т.д., и сравнивать различные реализации по этим параметрам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
__>по сути неверна, так как не учитывает все возможное многообразие задач. Приведу более простой пример из моей практики. В 2k3 разрабатывал одну web-систему — в бэкэнде был sql server 2k (лучшее решение на тот момент по произв./стоимость). Хотя данных было не очень много (около 5~7 Гб), OLTP-нагрузка для того времени была высокой, так что пришлось специально "хинтить", настраивать query governer и пинировать некоторые таблицы (ms-евангилисты, если вы это читаете срочно начинайте гуглить или бинговать эти страшные слова).
Ну да, конечно. MS евангелисты не знают того, что знаем мы, SQL Server DBA среднего пошиба.
Верится с трудом, хотя если имеются в виду определенные MS SQL Server MVP последнего созыва, то вполне может быть, что и не знают. Мельчает народ, мельчает...
Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы.
__>Сервер хорошо держал нагрузку на OLTP, но поиск по БД (длинные запросы) убивал перфоманс напрочь; эскалация, массовый рост tempdb и скачки в RAM. Нашли быстрое решение — вынесли поисковые таблицы на отдельный mssql2k сервер, все стало super. Это ответ на ваш вопрос "зачем" ?
Так вроде как абсолютно стандартное решение — разделение OLTP и BI нагрузок. Разве нет?
Здравствуйте, _ABC_, Вы писали:
_AB>Ну да, конечно. MS евангелисты не знают того, что знаем мы, SQL Server DBA среднего пошиба.
Я не DBA, так что высказаться на тему сравнения евангелистов и DBA с полной страстью не смогу. Но если бы нужно было поставить кругленькую сумму денег на DBA против евангелиста при оценке навыков владения SQL Server, я бы ставил на DBA среднего пошиба. В память врезалась одна история — будучи еще зеленым программистом получил психологическую травму, посетив одну конференцию MS. Там известный упитанный евангелист на спорте с постамента призывно кричал что SQL Server как труба. Шок был жесткий (я только не понял железная или пластиковая . Или габой ?). _AB>Верится с трудом, хотя если имеются в виду определенные MS SQL Server MVP последнего созыва, то вполне может быть, что и не знают. Мельчает народ, мельчает...
MVP — это model-view-controller ? Шутка
Они точно не знают. Да и зачем им это? Ведь есть книжки Дилани и Бен-Гана, где по верхам накидано что и как. Или еще хуже SQL Server для начинающих русского писателя Пети Иванова (это вообще супер, читаешь слезами обливаешься). А понимать концепции работы оптимизатора, системы ввода-вывода, стратегий соединения — не барское это дело для таких людей . _AB>Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы.
Использование хинтов как хирургия. Такое вмешательство крайне редко, опасно но иногда необходимо. Если не умеете этого делать, лучше придерживаться общепринятой концепции — хинты зло, микрософт не рекомендует. _AB>Так вроде как абсолютно стандартное решение — разделение OLTP и BI нагрузок. Разве нет?
Это просто контрпример к вашей фразе — зачем дробить коллекции меньше 10Гб. Ответ — производственная необходимость
Здравствуйте, a_g_99, Вы писали:
_AB>>Ну а уж от хинтов программисты просто без ума, пихают их куда не попадя. Поубивав бы. __>Использование хинтов как хирургия. Такое вмешательство крайне редко, опасно но иногда необходимо.
Вот-вот. Хирургия. А пошла мода при насморке нос отрезать.
__>Если не умеете этого делать, лучше придерживаться общепринятой концепции — хинты зло, микрософт не рекомендует.
В том-то и проблема, что "умеют".
Здравствуйте, a_g_99, Вы писали:
_AB>>Суть понятна. Почему DL385 G7 с 2-мя процами и 32 ГБ оперативной пямяти за примерно 10 тысяч в данном случае справится хуже, чем 3 сервера с одним процом и 4 ГБ оперативы по пять тысяч каждый? __>Вы ушли куда-то в сторону от темы. Если ставить так вопрос — то конечно DL385 G7 выйдет победителем. Я бы конечно мог сейчас с пеной у рта доказывать, что вот если силами моджахедов собрать в пакистане на коленке сервера с одним CPU, то это было бы еще круче, чем кастрированный DL385 G7, у которого какой-нибудь плюгавый мужик из HP при конфигурировании выдернул все что мог, но это пустая трата времени.
Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики.
__>В общем, мой посыл был следующим — в некоторых случаях (не всегда) горизонтальное масштабирование будет эффективным чем вертикальное. Напр. с точки зрения снижения стоимости входа + возможно ROI. И это касается соврешенно разных систем — маленьких, средних, больших.
Покажите пожалуйста, в каких именно случаях это так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики.
Простой пример для серии IBM iSeries 80x (AS400). Я взял эту серию для сравнения исходя из двух причин:
1) Сервера серии уже настроены и преконфигурированы.
2) Для данной серии есть уже готовая метрика CPW, разработанная самой IBM для расчета производительности системы. Методику расчета можете погуглить отдельно. Производительность каждого сервера оценивается данной метрикой.
Средние цены в штатах на сервера можно посмотреть напр. здесь — http://www.nvcsales.com/ibm/eserver-i.asp.
Теперь простой пример:
берем средненькие iSeries 800 (FP — 2464) стоимостью $51,893 при CPW=950
и берем хороший мощный iSeries 870 в интерпрайзе (FP — 2486) стоимостью $1,966,778 при CPW=11500
Итого теор. чтобы полностью покрыть один [870] нам потребуется 11500/950 = 13 [800] серверов
Цена 13*$51,893 = 674,609 < 2 млн. в 3 раза. Соотвественно если посмотрите на различные серии то увидите, что чем ближе серии тем меньше разрыв по деньгам (что логично)
Естесвенно TCO для сети машин будет существенно(многократно?) выше чем для одного суперсервера за счет Software license costs & maintenance, электроэнергии и пр. adm. costs. Но ROI скорее всего ниже.
S>Покажите пожалуйста, в каких именно случаях это так.
Я кратко попробую перечислить области, наверное так будет наглядно и правильно:
1) CDN-системы. Здесь DL определяет реализацию.
2) открытые проекты & community, которые должы использовать "общественные" мощности. проект SETI
3) системы с неизвестным верхним пределом масштабирования. напр. youtube
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Sinclair, Вы писали:
S>>Ну вы бы хоть какой-то пример привели в защиту своих утверждений. Я пока никак не могу найти ситуацию, где цена одного сервера росла бы быстрее, чем цена кучи серверов, суммарно вытягивающих все те же характеристики. __>Итого теор. чтобы полностью покрыть один [870] нам потребуется 11500/950 = 13 [800] серверов
А вот тут поподробнее. Я, конечно, верю, что есть задачи с идеальной параллельностью, но мы, вроде бы, о БД говорим — а тут все не совсем так, прямо скажем.
Почему 13 серверов будут работать в 13 раз быстрее одного? Ну и, разумеется, не посчитана инфраструктура
Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Здравствуйте, a_g_99, Вы писали:
ДФ>А вот тут поподробнее. Я, конечно, верю, что есть задачи с идеальной параллельностью, но мы, вроде бы, о БД говорим — а тут все не совсем так, прямо скажем.
В этом-то то и преимущество окружающего нас мира — в нем существует огромный разброс задач даже применительно к БД. Я напр. могу привести кучу реальных примеров — один сервер, одна БД — успешное решение. Но есть и другие, когда разделение задач действительно выгодно (напр. OLTP и OLAP, CDN/geolocation) ДФ>Почему 13 серверов будут работать в 13 раз быстрее одного? Ну и, разумеется, не посчитана инфраструктура
Вы неправильно поняли. Из такого "идеализированного" сравнения следует что 13 серверов могут работать примерно так же как один, но стоимость затрат на их приобретение будет существенно ниже. Про инфраструктуру — согласен на 100%. Дополнительно нужно будет организовать сеть, пространство, обеспечить поддержку пула серверов и т.д. Но даже при таком раскладе стоимость подобной сети будет пониже одного суперсервера + создается возможность более гибкого масштабирования кластера в целом.
ДФ>Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине.
Я буду только за, если кто-то приведет стату по tpc cluster/no cluster, чтобы разрушить или подтвердить мои утверждения
Здравствуйте, a_g_99, Вы писали: __>Цена 13*$51,893 = 674,609 < 2 млн. в 3 раза. Соотвественно если посмотрите на различные серии то увидите, что чем ближе серии тем меньше разрыв по деньгам (что логично)
Спасибо, интересный пример.
Да, если говорить о чистой вычислительной мощности, то цена растёт нелинейно, по крайней мере, за пределами "среднего" диапазона.
Но для баз данных важна дисковая подсистема. И у меня вызывает лёгкую оторопь манера некоторых людей тут сравнивать многодисковые SAN-системы со встроенными в дешёвые сервера десктопными винтами.
__>Естесвенно TCO для сети машин будет существенно(многократно?) выше чем для одного суперсервера за счет Software license costs & maintenance, электроэнергии и пр. adm. costs. Но ROI скорее всего ниже.
S>>Покажите пожалуйста, в каких именно случаях это так. __>Я кратко попробую перечислить области, наверное так будет наглядно и правильно: __>1) CDN-системы. Здесь DL определяет реализацию. __>2) открытые проекты & community, которые должы использовать "общественные" мощности. проект SETI __>3) системы с неизвестным верхним пределом масштабирования. напр. youtube
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, a_g_99, Вы писали:
ДФ>>Лучше уж сравнивать по какому-нибудь tpc.org, там есть кластерные решения и решения на одной машине. __>Я буду только за, если кто-то приведет стату по tpc cluster/no cluster, чтобы разрушить или подтвердить мои утверждения
А чего тут приводить — всё доступно публично. Кластерных решений — всего четыре. Из относительно свежих — вот:
10366554 tpmC при цене 1.38 USD за tpmC
30249688 tpmC при цене 1.01 USD за tpmC
Всё остальное — некластерное. Например, есть 5055888 tpmC при цене 0.89 USD за tpmC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Не будет. В момент "фэйловера" она нарушиться, если есть недореплицированные комиты. Эти комиты уезжают в будущее. S>Ок, в такой схеме (если происходит фейловер для клиента, который работал с мастером на запись) — да, нарушается последовательность, это правда. С точки зрения теории кристалла, это частичное нарушение durability. Не очень важно то, что произошёл фейловер. С тем же успехом могло произойти восстановление из бэкапа — и с тем же результатом, "изменения за последние xxx секунд потеряны".
Не "потеряны", а "уехали в будущее". Это хужее будет.
S>Нужно понимать, что схем, которые бы гарантировали 100% durability, в природе не существует. Кворум, на который вы так сильно уповаете, принципиально не лучше. Для него просто вероятность нарушения durability ниже. Это место вам понятно или нужно подробнее пояснять?
Далось тебе это дюрабилити. Вроде говорили про консистентность. Пробую последний раз. В такой схеме "фэйловер" это штатная ситуация и может происходить хоть по 100 раз на день. (Собственно, есть статистика, что большая часть так называемых фэйловеров происходит просто от того, что система что-то там надумала, а не из-за реальных сбоев). Каждый раз будет бочина с консистентностью. Клиент (напр., сервер приложений) должен это учитывать (например, что бы поддерживать когерентность кеша).
ANS>>Маша сделала комит, а потом говорит Пете человеческим голосом: "Смотри что я тут закомитила". Петя смотрит и в зависимости от того, что он может увидеть и получаются разные гарантии консистентности. Ты утверждаешь, что в ACID системе Петя (после получения приглашения от Маши) может не увидеть Машин комит, а через 5 минут позже — увидеть. Я уверен, что в ACID системе Петя обязан увидеть комит Маши сразу, если она его пригласила. S>На чём основана ваша уверенность? И зачем она вам нужна?
На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов.
ANS>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". S>Поясните. Я не вижу ошибки.
Ошибка после дефиса.
S>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не "потеряны", а "уехали в будущее". Это хужее будет.
Вы продолжаете говорить загадками. Поясните мне разницу между эффектами, наблюдаемыми клиентом при падении одной машины и восстановлении из бэкапа, датированного Tx-Delta, и при фейловере на слейва, который отстаёт по репликации на Delta.
ANS>Далось тебе это дюрабилити. Вроде говорили про консистентность.
Просто то, что в CAP называют консистентностью, в ACID называют дюрабилити. Мы же это вроде бы уже обсуждали.
ANS>Пробую последний раз. В такой схеме "фэйловер" это штатная ситуация и может происходить хоть по 100 раз на день. (Собственно, есть статистика, что большая часть так называемых фэйловеров происходит просто от того, что система что-то там надумала, а не из-за реальных сбоев). Каждый раз будет бочина с консистентностью. Клиент (напр., сервер приложений) должен это учитывать (например, что бы поддерживать когерентность кеша).
Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"? Поймите, что вся теория надёжности — про построение более надёжных систем из менее надёжных компонентов. Если у вас сервер A падал в среднем раз в шесть месяцев, то от включения его в Active/Passive кластер он не станет падать чаще. Вся идея фейловера — в том, чтобы увеличить MTBF. Если вам это непонятно — спрашивайте.
Если сервер падает 100 раз в день, значит у него MTBF
ANS>На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов.
Вы путаете две разных вещи. Вы говорите о действиях, происходящих в одной транзакции. ACID требует от них упорядоченности.
Если вы разносите проверку уникальности и запись в две разных транзакции — значит, вы не понимаете, что такое транзакция. Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
ANS>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". ANS>Ошибка после дефиса.
Простите, а сколько серверов останется после падения одного из двух? Если у вас ещё и арифметика альтернативная, то придётся беседу свернуть. S>>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. ANS>Ерунда.
Прекрасный аргумент. Продолжайте в том же духе — это соберёт под знамёна NoSQL массы поклонников.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Не "потеряны", а "уехали в будущее". Это хужее будет. S>Вы продолжаете говорить загадками. Поясните мне разницу между эффектами, наблюдаемыми клиентом при падении одной машины и восстановлении из бэкапа, датированного Tx-Delta, и при фейловере на слейва, который отстаёт по репликации на Delta.
.
ANS>>Далось тебе это дюрабилити. Вроде говорили про консистентность. S>Просто то, что в CAP называют консистентностью, в ACID называют дюрабилити. Мы же это вроде бы уже обсуждали.
Это не так. То, что гарантии консистентности в ACID /похоже/ проистекают из D не делает это одинаковыми.
S>Вы не то объясняете. Кто вам сказал, что фейловер — это "штатная ситуация"?
Иначе нет никакого смысла огород городить.
ANS>>На практике. btw, запись в РДБМС обычно состоит еще и из чтения (для проверки,к примеру, уникальности). В sequental consistency операции чтения и записи могут разъехаться во времени, что сделает невозможным проверку констрейнтов. S>Вы путаете две разных вещи. Вы говорите о действиях, происходящих в одной транзакции. ACID требует от них упорядоченности. S>Если вы разносите проверку уникальности и запись в две разных транзакции — значит, вы не понимаете, что такое транзакция.
Когда говорят о консистентности, то, естественно, рассматривают отдельные операции чтения/записи. Границы транзакций это просто те диапазоны в пределах которых операции чтения/записи могут перемещаться системой. В твоей модели операции могут уезжать за границы транзакций, что есть ерунда.
S>Конечно же, в этом случае ACID не даст вам никаких гарантий. Sequential consistency соблюдается между отдельными транзакциями.
Всё таки. Маша сделала комит и звонит Пете. Петя комита не видит, проходит пол часа потом видит. По твоему это для ACID базы нормально?
ANS>>>>Совсем нет. Твоя ошибка в концовке фразы "При двух серверах падение любого получается катастрофа — ведь останется только один сервер". ANS>>Ошибка после дефиса. S>Простите, а сколько серверов останется после падения одного из двух? Если у вас ещё и арифметика альтернативная, то придётся беседу свернуть.
Уточню. Ошибка в том, что ты поставил слово "ведь". Правильно так: "При двух серверах падение любого — останется только один сервер. Получается катастрофа, потому что...".
S>>>Это бессмысленный подход — с его точки зрения все системы одинаковы, т.к. ни одна не обеспечивает консистентности. ANS>>Ерунда. S>Прекрасный аргумент.
Это не аргумент. Это оценка.
S>Продолжайте в том же духе — это соберёт под знамёна NoSQL массы поклонников.
Как вроде я тебя агитирую. Постов, где люди делают фэйловер на 2-х серверах и асинхронной репликации и удивляются результату, в инете есть. Хотя даже одного примера достаточно, чтобы показать, что схема в общем случае не рабочая. И, что интересно, речь тут не об NoSql.
срочно начинайте гуглить или бинговать 
