100% Durability невозможно. Физика запрещает.
Но чем больше девяток, тем сон спокойнее.
Yura
Yura
И потом, где-то нужен высокий уровень гарантий, а где-то нет
Как-то получается, что везде, где я работал, нужен был высокий. И когда его не было, была головная боль.
Но у меня не такой разнообразный опыт. И, наверняка, где-то высокий не нужен.
yopp
да никогда он не нужен для _всех_ данных
yopp
каждая девятка стоит на порядок дороже следующей
yopp
к 5 девятке мы говорим уже об астрономических суммах, после неё начинается область научной фантастики
Yura
да никогда он не нужен для _всех_ данных
Для всех - нет. Но для 95% данных - практически всегда.
yopp
для 95% данных почти никогда :)
yopp
вот для 5% да
Yura
каждая девятка стоит на порядок дороже следующей
Да. И пока они окупаются, есть смысл их добавлять.
yopp
ну вот простой пример с тремя локациями: лондон, китай, штаты
yopp
и когда у нас данных например 20Пб
yopp
на самом деле даже десятка терабайт хватит
Yura
для 95% данных почти никогда :)
Как я уже говорил, у меня был другой опыт.
5% - не важен уровень надёжности, 95% - важен - это то, с чем сталкивался я. Мой опыт может отличаться от вашего.
Из 95% можно было пожертвовать 50% ценой большой головной боли, но не хотелось. Оставшиеся 45% обеспечивались стольким кол-вом девяток, насколько хватало бюджета, и очень расстраивались, что физика против 100% дюрабилити.
Повторюсь: у каждого свой опыт. У меня - такой.
yopp
везде есть точка, где 95% становится мифом
yopp
я к тому, что tiered подход к хранимым данным, с заранее сформулированными рисками и вывдеными из них требованиями к durability может экономить бешенные бабки
yopp
потому что кроме сохранности данных, ещё есть их доступность
Yura
Мы спорим о пустом. Даже если вам нужна высокая надежность даже для 1 гигабайта, это уже означает, что вам нужна высокая надежность
Yura
yopp
вот гитхаб урок про доступность vs сохранность получил
yopp
они слишком много внимания уделяли сохранности и получили по лбу доступностью
Yura
Потому и сели в лужу.
Yura
Если бы у них была сохранность, они бы меньше времени потратили на восстановление.
yopp
меньше времени это функция доступности
yopp
а не сохранности
Yura
Вот именно: сохранность очень часто коррелирует с доступностью.
yopp
у них всё было, и delayed реплики, и бэкапы
Yura
у них всё было, и delayed реплики, и бэкапы
У них не было ни чего, что накрывало те несчастные 40 секунд.
Yura
О чем мы спорим?
yopp
почему спорим то. обсуждаем беду у коллег по цеху
Yura
👍
yopp
я вот не считаю что они в лужу сели
yopp
всем когда-то придётся получить по лбу
Yura
Ну, сели-встали. Жизнь продолжается. 😂😁
yopp
много интересных кейсов. с таймаутами интересная проблема. вероятно высокие требования по таймаутам были обусловлены жестким требованиям к производительности. если сервис не укладывается, значит с ним что-то не так.
это очень разумный подход. но вот как его совместить с такими стуациями, это задача
yopp
что делать если у тебя целостность нарушилась в большом кластере тоже интересная проблема
Анатолий
где можно почитать про все эти доступности и сохранности в актуальных версиях?
Анатолий
довольно интересные вещи обсуждаете, но знаний не хватает чтобы понять =((
Анатолий
к примеру не понял почему из-за лага в ~40 секунд потом не смогли восстановить East сервера.. отправить оказавшиеся на них уникальные write операции в West и заново синхронизировать - почему так нельзя было? зачем из бэкапа восстанавливаться и накатывать все операции из логов...
Анатолий
вообще говоря кластер в моём понимание должен автоматом решать такие вопросы, раз уж он кластер
Анатолий
синхронизация зафейлилась из-за сетевых проблем - по идее же стандартная ситуация. когда читаешь про всякие master-master, master-slave - вроде всё описывается
Анатолий
должно быть стандартное решение
Анатолий
всякие верткальные или горизонтальные - наверное в данном случае горизонтальные шардинги... вот это всё
Анатолий
ну или другой вывод - в github была какая-то кривая архитектура в кластере
Yura
к примеру не понял почему из-за лага в ~40 секунд потом не смогли восстановить East сервера.. отправить оказавшиеся на них уникальные write операции в West и заново синхронизировать - почему так нельзя было? зачем из бэкапа восстанавливаться и накатывать все операции из логов...
Потому что:
А) для начала нужно восстановить хоть какую-то работоспособность, и т.к. West получил большее кол-во записей, было решено восстанавливать с него, но для этого его нужно было целиком перетащить на East, т.к. отката в mysql не предусмотрено.
б) автоматического разрешения конфликтов нет, а потому те 40 сек пришлось накатывать в полуручном режиме.
Yura
вообще говоря кластер в моём понимание должен автоматом решать такие вопросы, раз уж он кластер
И монга наиболее близкое к идеалу из доступных широкой публике решений.
Потому, несмотря на всю мою не любовь к Монге, за это я ее уважаю.
Анатолий
эту часть я понял =)
Анатолий
я не понял почему кластер у github не решил всё сам в фоне - он же по идее могЁт
Yura
Анатолий
воу.. как так. гугл показывает кучу ссылок про mysql cluster conflict resolution
Анатолий
вон какие-то active-active replication, mysql ndb cluster conflict resolution
Анатолий
если есть инструменты - то может их просто не юзали и не настроили? по крайней мере такой у меня пока вывод. не верю что кластер в mysql не умеет решать конфликты вообще
Yura
NDB Cluster - это не привычный всем MySQL, а несколько другой зверь.
Yura
Наверное, как-то умеет, но либо страдает производительность, либо консистентность.
В этом смысле, yopp правильно сказал про ролбэк в монге с сохранением "исчезнувших" изменений: это был бы такой же сценариий, как у гитхаба, но первая часть восстановления прошла бы быстрее.
Yura
Btw, postgresql тоже может откатывать с помощью сторонней тулзы pg_rewind. Костыльно, но работает.
yopp
ну или другой вывод - в github была какая-то кривая архитектура в кластере
кривизна архитектуры обусловлена архаичностью решений в mysql
yopp
вообще субд с надежным HA/FT критически мало
yopp
во-первых, распределенные системы это одна из самых сложных технических задач.
во-вторых, ещё буквально лет 15 назад, такие системы были актуальны для небольшого количества компаний в мире. По этому технологии были реализованы только во всяких MS SQL и прочих Ораклах. Сейчас и интернет стал доступным, и компании стали управлять большими объёмами данных, и данных больше стало и глобализация двигает компании сразу в разные регионы.
yopp
ну и технологии тоже не для всего есть
yopp
рафт например это недавнее изобретение
Yura
вообще субд с надежным HA/FT критически мало
Люто плюсую.
btw, кто-нибудь активно насиловал CockroachDB и TiDB?
yopp
до него был paxos, он из девяностых
Yura
рафт например это недавнее изобретение
Рафт - это понятно изложенный доведенный до ума multipaxos.
Протокол, по которому работает Zookeeper, практически идентичен рафту, с не принципиальными отличиями в алгоритме выбора примари, и восстановления после выборов.
yopp
ну а paxos это конец девяностых
Yura
Все алгоритмы строгого консенсуса так или иначе изоморфны паксосу.
Рафт - это тоже вариант паксоса.
Заслуга автора Рафта в том, что он смог понятно обьяснить multi-paxos, и в понятной форме обьяснить, что делать с его корнер-кейсами. (А именно: как восстанавливаться после перевыборов примари). (А также, как менять состав кластера. Хотя тут у него было несколько подходов, и даже ошибки. Но вроде уже все ок).
yopp
так я не спорю, я к тому что вообще консенсус в распределенных системах это новшество
yopp
а консенсус это только одна из множества проблем
Yura
btw, понимаю, что оффтоп, но кто-нибудь активно насиловал CockroachDB и TiDB?
yopp
попробуй в @bigdata_ru спросить
Alexander
Спасибо, буду знать.
Я изначально и использовал строку. Но это очень неудобно в конечном счёте, так как нужно преобразование типов. Видимо придётся таки к строкам возвращаться.
Кстати, а не подскажете можно ли пробежаться по существующим документам и сделать графы в них строками, что бы я разом всё обновил? Использую mongoose для работы с базами.
Еще раз здравствуйте. Я таки подумал, что буду хранить длинные числа как строки. А при получения данных конвертировать их в Int. Но я пока так и не решил проблему. У меня уже есть пользователи в базе данных, которые создавались по модели. И у них графы Number везде и соответственно в документах УЖЕ сохранены целые числа.
Могу ли я как-то за раз насильно сделать так, что бы во всех доках пользователей эта графа стала строкой? + в дальнейшем изменю модель, что бы нужные графы сохранялись как строки.
Потому что у меня есть вариант получить всех юзеров из базы, и циклом для каждого создать новый документ в новой коллекции, только графу числовую превращать в строку. Но это как-то оверхэд, каждого пересохранять с измененными данными.
Макс[ы]м Атыгаев
findAndModify?
yopp
Еще раз здравствуйте. Я таки подумал, что буду хранить длинные числа как строки. А при получения данных конвертировать их в Int. Но я пока так и не решил проблему. У меня уже есть пользователи в базе данных, которые создавались по модели. И у них графы Number везде и соответственно в документах УЖЕ сохранены целые числа.
Могу ли я как-то за раз насильно сделать так, что бы во всех доках пользователей эта графа стала строкой? + в дальнейшем изменю модель, что бы нужные графы сохранялись как строки.
Потому что у меня есть вариант получить всех юзеров из базы, и циклом для каждого создать новый документ в новой коллекции, только графу числовую превращать в строку. Но это как-то оверхэд, каждого пересохранять с измененными данными.
Не обязательно создавать новый документ, можно обновить существующий. Но перебирать на клиенте всё равно придётся, в монге всё ещё нет возможности преобразовывать типы внутри запроса.
yopp
Открываете курсор, читаете документ из курсора, делаете updateOne на изменённый документ
Alexander
Понял, спасибо
Anonymous
Здравствуйте, что за тематика у этого чата?
AstraSerg
Anonymous
Спасибо)
Hopf
Добрый день, подскажите куда почитать.
У меня есть поле name: string (разные имена) и поле status: string (success, failed)
Я хочу посчитать какому name какое соотношение status соответствует (success/failed)
Vova
Добрый день, подскажите куда почитать.
У меня есть поле name: string (разные имена) и поле status: string (success, failed)
Я хочу посчитать какому name какое соотношение status соответствует (success/failed)
"посчитать какому name какое соотношение status соответствует"
Так что посчитать и при чём тут соотношение?