работа с массивом ?

Здравствуйте. Столкнулся с ошибкой которая мне всё ломает. Не могу сохранить в mlab число с большим количество цифр. 1000000000000000000 19 цифр ещё могу. Но больше - нет. Это стандартное ограничение? Можно ли его снять?

вы уперлись в лимит 64 битных целочисленных значений

используйте decimal128

Здравствуйте. Столкнулся с ошибкой которая мне всё ломает. Не могу сохранить в mlab число с большим количество цифр. 1000000000000000000 19 цифр ещё могу. Но больше - нет. Это стандартное ограничение? Можно ли его снять?

Это мега стандартное ограничение - это ограничение 64битного числа. В монгодб появилась поддержка decimal128. Не помню сколько, но околл 30 цифр в него влезет. Чисел с произвольной точностью в монге нет. Но если вам только хранить их, то ни кто не мешает сериализовать в строку.

Это мега стандартное ограничение - это ограничение 64битного числа. В монгодб появилась поддержка decimal128. Не помню сколько, но околл 30 цифр в него влезет. Чисел с произвольной точностью в монге нет. Но если вам только хранить их, то ни кто не мешает сериализовать в строку.

Спасибо, буду знать. Я изначально и использовал строку. Но это очень неудобно в конечном счёте, так как нужно преобразование типов. Видимо придётся таки к строкам возвращаться. Кстати, а не подскажете можно ли пробежаться по существующим документам и сделать графы в них строками, что бы я разом всё обновил? Использую mongoose для работы с базами.

Если хочется хранить бесконечно большие значения, то смотрите на BER integer encoding. Это стандартный способ сериализации чисел с произвольной длинной. Но поддержки со стороны монги не будет.

Строки не очень хороший вариант. Если я правильно помню, то с binary полем в котором BER будут работать операторы сравнения

Строки не очень хороший вариант. Если я правильно помню, то с binary полем в котором BER будут работать операторы сравнения

не совсем. 127*128=16256 будет больше, чем 126*128*128=2064384 будет хорошо сравниваться, если сделать псевдо-флоатинг-поинт: нормализовать мантису, вначале записать фиксированную экспоненту, а потом ber мантису. Но нужно ли сравнивать?

не совсем. 127*128=16256 будет больше, чем 126*128*128=2064384 будет хорошо сравниваться, если сделать псевдо-флоатинг-поинт: нормализовать мантису, вначале записать фиксированную экспоненту, а потом ber мантису. Но нужно ли сравнивать?

> db.ber.find().sort({_id: 1}) { "_id" : BinData(0,"zhA=") } { "_id" : BinData(0,"/wA=") } { "_id" : BinData(0,"/oAA") } { "_id" : BinData(0,"paCvyAA=") }

eq 10000 16256 2064384 10000000000

со строками так не прокатит :)

а кейс очень простой, мы по этому полю решили что-то отсортировать

и второй момент: db.ber.find({_id: { $gt: BinData(0,"zhA="), $lt: BinData(0,"paCvyAA=")}}) { "_id" : BinData(0,"/wA=") } { "_id" : BinData(0,"/oAA") }

А, я не знал/забыл, что bindata монга сравнивает сперва по длинне. Дибильное поведение совершенно, но в этом конкретном случае сыграло на руку.

https://blog.github.com/2018-10-30-oct21-post-incident-analysis/ The database servers in the US East Coast data center contained a brief period of writes that had not been replicated to the US West Coast facility Because the database clusters in both data centers now contained writes that were not present in the other data center, we were unable to fail the primary back over to the US East Coast data center safely.

к вопросу зачем в монге роллбэк нужен

The time required to restore multiple terabytes of backup data caused the process to take hours.

For example, one of our busiest clusters had 954 writes in the affected window.

к вопросу о размере роллбэка

т.е. если бы у их самопального HA велосипеда была бы стратегия отката, они бы не упали на сутки из-за тысячи событий. которые бы потом руками восстановились за пару часов

ну и вот это: However, applications running in the East Coast that depend on writing information to a West Coast MySQL cluster are currently unable to cope with the additional latency introduced by a cross-country round trip for the majority of their database calls

60мс латенси хватило чтоб положить приложения

как-то всё муторно

43 секунды отсутствия соединения, а не 60мс latency стало причиной

43 секунды отсутствия соединения, а не 60мс latency стало причиной

However, applications running in the East Coast that depend on writing information to a West Coast MySQL cluster are currently unable to cope with the additional latency introduced by a cross-country round trip for the majority of their database calls

are currently unable to cope with the additional latency introduced by a cross-country round trip

из-за падений линка, у них произошел фейловер на праймари, но в другом регионе в предыдущем праймари остался нереплицированный кусок и сделал обратный фейловер невозможным из-за переезда праймари, увеличилось latency и приложения работающие в другом регионе похоже перестали укладываться во внутренние таймауты

60мс latency у них же всегда была и не увеличивалась

у них в другом регионе только pages и notifications же

на картинке

теперь я понял

т.е. если бы не этот факт, они могли бы обслуживать трафик клиентов

удивительно конечно, что для такого масштаба они всё ещё завязаны на один регион

к вопросу зачем в монге роллбэк нужен

Если быть точнее, то мажорити врайт + ролбэк.

majority тут бы не спасло

majority тут бы не спасло

???? Поясни. Если только один ролбэк, без мажорити, то получится, что откатываются транзакции, про которые сообщено, что они закоммитились. Вообще-то, ролбэк - это недостаток, т.к. соседние транзакции видят еще не закомиченные данные. По хорошему, соседние транзакции тоже должны были видеть только после мажорити врайт, и тогда ролбэк не нужен был бы . (Вообще-то, не совсем правда: ролбэк был бы нужен, но он был бы не видимый, в отличии от вполне видимого текущего).

ролбэк это механизм разрешения конфликта при мерже оплогов

путём отбрасывания меньшей ветки событий

majority никак не гарантирует что в момент времени на majority будет одинаковая точка в оплоге

т.е. что в кластере возможны выборы нового праймари без ролбэка

>т.к. соседние транзакции видят еще не закомиченные данные Это как? Уровень изоляции Read uncommited?

для такого вот локаута хватит лага в одну запись

Ролбэк - это откат до общей точки. Если используется мажорити врай, то любая транзакция, про которую сообщено клиенту, что она закомиченна, будет до момента общей точки. Если мажорити врайт не используется, то клиенту будет сказано, что чейнж закомичен, а на самом деле, он может быть откачен при ролбэке.

так причём тут клиенты

видимость транзакций и ролбэк это разные проблемы

>т.к. соседние транзакции видят еще не закомиченные данные Это как? Уровень изоляции Read uncommited?

Ты не знал?

видимость транзакций и ролбэк это разные проблемы

Клиент очень даже при чём. Если клиенту сказали, что транзакция закомичена, она должна быть закомичена. Это durability (не путать с isolation).

я работаю с postgresql, там read commited обычно

я работаю с postgresql, там read commited обычно

В монге всё намного разнообразнее.

так у github mysql

Клиент очень даже при чём. Если клиенту сказали, что транзакция закомичена, она должна быть закомичена. Это durability (не путать с isolation).

клиенты никак на выбор нового праймари не влияют

но я понял о чём ты, ты о гарантиях записи

клиенты никак на выбор нового праймари не влияют

Но majority write влияет. Новым примари будет выбрана реплика с длинейшим логом. И это гарантирует сохранность записанного с мажорити врайтом.

Алгоритм репликации в новой монге (начиная с 3.4) - это адаптированный Raft. Но все гарантии он дает только majority.

majority write это параметр, который учитвыается при выборе нового мастера для mongo?

majority write это параметр, который учитвыается при выборе нового мастера для mongo?

Majority write гарантирует, что если тебе ответили ok, то запись есть в мажорити. Алгоритм выбора нового примари гарантирует, что новый примари будет знать о том, о чем знает мажорити.

ну и тут мы встаём перед класическими CAP стульями

(свет на всём побережье вырубили)

либо у нас везде majority, но мы платим за это latency эквивалентной максимальной latency в кластере в majority

либо у нас есть записи с меньшей гарантией и тогда у нас есть на выбор, или ситуация как у гитхаба

или роллбэк

ну или у нас CRDT тогда мы можем без ролбэка проехать

я вот этот момент не понял " Because the database clusters in both data centers now contained writes that were not present in the other data center, we were unable to fail the primary back over to the US East Coast data center safely" В East есть writes, которые не реплицировались в West понятно из-за чего. Наоборот может быть толлько из-за latency.

Вообще интересно почему праймари продолжил запросы обслуживать

"Querying the Orchestrator API displayed a database replication topology that only included servers from our US West Coast data center" East вообще отвалился что ли

Линк упал между дц

Это классический split

линк падал на 43 секунды, последняя цитата уже про события после восстановления линка

либо у нас есть записи с меньшей гарантией и тогда у нас есть на выбор, или ситуация как у гитхаба

Если ты - гитхаб, то ролбэк закомиченных транзакций - это не вариант. Собственно, именно по-этому они так долго и восстанавливались. Если бы rollback для них был вариантом, они бы грохнули те сорок секунд, на которые разошлись реплики, и не мурыжились бы еще полдня.

Если ты - гитхаб, то ролбэк закомиченных транзакций - это не вариант. Собственно, именно по-этому они так долго и восстанавливались. Если бы rollback для них был вариантом, они бы грохнули те сорок секунд, на которые разошлись реплики, и не мурыжились бы еще полдня.

Так в монге у тебя откаченные транзакции остались. Ты их потом руками разруливаешь и все

Так в монге у тебя откаченные транзакции остались. Ты их потом руками разруливаешь и все

Чего? Монга все делает сама, за то ее и любят. И если ты используешь majority write, то ты уверен, что ничего лишнего не откатится.

Чего? Монга все делает сама, за то ее и любят. И если ты используешь majority write, то ты уверен, что ничего лишнего не откатится.

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

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

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

100% Durability невозможно. Физика запрещает.

Роллбэк как он сделан в монге, это отличное решение проблемы как у гитхаба

И потом, где-то нужен высокий уровень гарантий, а где-то нет

Монга даёт широкий выбор сейчас, под конкретную задачу

ну и majority в географических кластерах, это долго. был бы у них дц в китае ещё, например :)

или в сиднее